Myths About Open Source Development 507
jpkunst writes "A thought-provoking article by chromatic on oreillynet, listing eight "myths" that Open Source developers tell themselves. For example: Myth: Publicly releasing open source code will attract flurries of patches and new contributors. Reality: You'll be lucky to hear from people merely using your code, much less those interested in modifying it."
Headline for the article is a troll (Score:5, Interesting)
----------------
Mythical Man Month Methodology
http://fourm.info/
Installation and configuration (Score:2, Interesting)
wrong in at least one place (Score:5, Interesting)
Reality: You'll be lucky to hear from people merely using your code, much less those interested in modifying it.
In my experience, this is not the case. I wrote a little rip-encode-and-tag script called choad and listed it on Freshmeat for the hell of it. This was two years ago, and I've received over 20 patches -- for a crappy little perl script!
I wrote it to solve my problem, and I continue to be pleasantly surprised when I get emails with feature enhancements, bug fixes, or just plain thanks and encouragement from people who had the same problem as me.
On warnings (Score:3, Interesting)
Their solution is, always fix warnings.
My solution is, GCC needs some way to suppress warnings!
Yes, GCC can already suppress *classes* of warnings. But I want to be able to suppress warnings on a per-line basis. What if in function x, there is a variable that I have defined but do not use for some specific reason-- but I still want to be warned if I do the same by accident in function y?
In Codewarrior, we had something called #pragma unused which worked like this. But that was just for that one case. Something generalized would be cool, something like "#pragma gcc.sw typecast" that would suppress typecast warnings for the next block, for example...
This IS a +5 troll article... (Score:1, Interesting)
This isn't a myth because it never happens. It's a myth because it doesn't happen as often as we'd like.
Now, According to m-w.com [m-w.com]:
Main Entry: myth
Pronunciation: 'mith
Function: noun
Etymology: Greek mythos
Date: 1830
1(a): a usually traditional story of ostensibly historical events that serves to unfold part of the world view of a people or explain a practice, belief, or natural phenomenon
2(a): a popular belief or tradition that has grown up around something or someone; especially one embodying the ideals and institutions of a society or segment of society
(b): an unfounded or false notion
3 : a person or thing having only an imaginary or unverifiable existence
This is not a myth. It is something which is true for a variety of reasons, and false under some circumstances. If it doesn't happen as often as some people would like, it is not necessarily a myth. Begone, ye article of the trolls!
Good points on ease of installation (Score:5, Interesting)
- "Packaging Doesn't Matter"
- "Programs Suck; Frameworks Rule!"
- "Warnings Are OK"
- "End Users Love Tracking CVS"
I appreciate the difficulties involved for open-source developers in making their programs easy to download and play. At the end of the day, it's their choice whether they make it accessible to the masses. Many of them just want to give something to the world that they would have otherwise kept for themselves.
But it is clear from the number of ambitious projects that many developers to aspire to hit prime time. In those cases, I hope they will take the advice in Chromatic's article, and think very carefully about the experience of an end-user who just wants to have a look.
For one thing, provide some screenshots so they don't even have to download the thing to see it. Next, read your installation instructions and consider whether they might not be better represented as an actual installation script. And finally, have an automated test facility to make sure the installation procedure works correctly.
An example of a problematic open-source package is subversion, the "sequel" to CVS. Because of the decision to bootstrap version control, you have to go through some painful procedure (last time I looked), just to see if it's worth bothering about yet. I have better things to do than jump hoops to try out a bit of fresh meat. I'm sure it will be great when it hits 1.0, but I'll save my energy until then.
Remember: the risk of a crap product is high when it comes to picking one of the thousands of packages on SF. Therefore, the pain threshold for most people is very low: if it doesn't work after a few minutes, most people will give up and try one of the dozen alternatives.
True Value of open source (Score:5, Interesting)
A) I can build apon other people's code.. It's effectively stealing their ideas, BUT since I'm GPLing my code as well, there is no net loss, and they are free to resteal my ideas back (if they are so inclined). I do often refer original authors to my new code.
B) I recognize that people MIGHT secretly build apon my code, so I get a warm fuzzy.
C) I can fix problems with open source drivers (postgres jdbc driver, GNU file-utils, etc. are some of my examples). Moreover, my debugger can jump straight to the line of maliscious code.
D) When I am about to release code publicly, I feel self conscious, and thus I put a TREMENDOUS amount of effort into cleaning up the code.. Making sure various platforms work, making sure there is no embarrasing spagetti-code, etc. Thus the mere possibility of people reading my code causes me to exert effort that I wouldn't otherwise. The end positive is a lower propensity for bugs, AND more modular/reusable code (especially with anything in perl).
The end-end result is therefore that Open source facilitates greater code reuse; less re-inventing of the wheel.. And more importantly code extensibility.
Now this begs a question of the distinction between modules and out-right applications. Open source is great for producing millions of reusable modules, but we often get chastized about the availibility of abundant QUALITY applications. Well, in my view, the merging of these two is two fold:
A) Open source applications tend to be more "plugagable"
B) Commercial sites will often pay developers to use open source modules and customize them to the particular needs of the corporation.. In doing so, serious feedback is provided to the various open source projects (because it is in their mutual interest to refine the modules). I as part of such a corp, have contributed (in various small ways) to several open source projects on the corp's dime, and with full authorization. This is of course, a completely unreliable source of income for a project, of course, but it is definitely a facilitator.
Best Practices for Software Development (Score:1, Interesting)
I have made a eigenpoll [all-technology.com] for Best Practices for Software Development [all-technology.com]
You use it by ranking the Practices you have expriense with, the it does some data minning
and find the best.
Right now the list looks like:
100% Test Coverage
Onsite Customer
Continuous Integration
Layering
Scrum Project Backlog
Test Driven Development
The Planing Game
TDD & CI with Aegis
Pair Programming
Current Worst Problem
Big Visible Chart
Simple Design
Codeing Standards
Refactoring
Collectiv Code Ownership
CRC Cards
feel free to add missing options.
ps.) Eigenpoll is open source too.
Re:Fear not, corporate developers (Score:3, Interesting)
None. Why? One potential reason is because it's not needed. Ever consider that all the 'usability tests' that MS conducts are a bunch of shit? Look at the two 'major' - supposed - outcomes of such research: MS Bob and Windows XP's graphical interface. All that this illustrates is that MS found people are dumb, and that MS doesn't think most folks are capable of too terribly much, mentally. So make it simple to the point where it loses practicality for the marginal number of people that are skilled.
Consider that when an open source developer is using software, and he finds a problem, or he sees a feature he wants, he impliments it. It has happened on Windows, too, with projects like WindowBlinds and AfterStep. People want more features, so they write them themselves - and quite a few people will use them. Sure, most people don't (they just use the 'vanilla' configuration), but it's necessary to have that flexibility in the framework; otherwise there will be no innovation. The benefit to a system like linux is that flexibility is there due to the openness and availability of the source code: nothing needs to be reverse engineered.
When the developer and product consumer is the same, open-source makes much more sense to me.
Er, correct me if I'm wrong, but developers are not a higher form of life than everyone else. They are no smarter than anyone else. They, like everyone else, has a personal opinion and personal way of relating to their environment; considering that most developers are human, I'm guessing that such interfaces would generally be understandable enough for someone of similar origin to figure out. If not, that's of no fallacy of the interface itself, but of the user: there are more options. If you -need- MS Windows and can't 'adapt' to KDE's interface (which is undeniably more full-featured), then stay with MS Windows -it's what you were initially introduced to, and it's what you're more familiar with. Simple enough, quit bitching. That doesn't mean that other designs are worse. Look at the forever-going battle over the GUIs of Windows vs. MacOS - they both think their own is superior.
Not everyone is a Type A, Type C, or Type Z. Some of us are Type 1, Type 0, and Type 01010110.
Re:Another myth (Score:2, Interesting)
Re:Headline for the article is a troll (Score:5, Interesting)
It's my experience that the percentage of people who send feedback or patches is much lower than commonly expected. See, for example, Nicholas Clark explaning the volunteer pool for Perl 5 core development [mail-archive.com]:
Of course, there are hundreds of people in the CREDITS file, but a handful of people do the bulk of the work. Maybe it's an edge case, but 10% of Perl users aren't contributing back to the core. It's very much below 1%.
That's not bad. It just is. My point is that expecting a smaller, younger, and less-well-used project to attract more regular and frequent developers is usually unrealistic.
Re:myth 9: (Score:5, Interesting)
In the last couple years I have dated a teacher, nurse, legal assistant, and a graphic designer, and the only one who didn't really enjoy talking tech was the graphic designer and I think thats because she, too, worked with computers all day.
Re:Counterpoint to the Framework "Myth" (Score:5, Interesting)
You might be surprised, but I agree. It usually takes me finding three instances of similar code before I can generalize it correctly.
This article was talking about the open source world, though. There seems to be a penchant for writing frameworks without any projects that actually use them. That's the myth I was trying to address. Extracting a framework from only one project isn't spectacular, but it's much, much better than extracting a framework from zero working projects.
Re:Another myth (Score:1, Interesting)
My rule is: only use comments when you are forced to violate idealism.
The problem with that is, without a good editor like Eclipse that is smart enough to show you a reasonable abstraction of the source (like an object interface) and can show you just the body of the function you are looking at (to focus on one problem at a time), reasonably near-perfect code becomes hard to understand as well.
When I'm reading/learning/reviewing (I work as a distance learning instructor) code, I need to be able to quickly grasp interfaces and study interactions. (The implementation is the least of my concern.)
Though, I usually just assume that no one will look at the plaintext. In fact, that may be my first comment:
Re:wow (Score:3, Interesting)
Re:Why Sad? (Score:3, Interesting)
and from the Darwin FAQ [apple.com] we find the following
Q. Why did Apple decide to share all of its modifications with the BSD community?
A. Although the BSD licenses don't require companies to post their sources, divergent code bases are very hard to maintain. We believe that the open source model is the most effective form of development for certain types of software. By pooling our expertise with the open source development community, we expect to improve the quality, performance, and feature set of our software. In addition, we realize that many developers enjoy working with open source software, and we want to give them the opportunity to use that kind of environment while they're creating solutions for Apple customers.
Although many people think that the rather simple BSD license does little to protect the openness of the code, it has contributed significantly to Apple's ability to adapt the code for the benefit of Mac users. Its emphasis on sharing code has also heightened our own commitment to the open development process.
Re:Myth # 9 (Score:5, Interesting)
Myth: Thousands of users are looking at the code.
Not Myth: Thousands of users could be looking at the code.
Not Myth: It's that one out of thousands that because (s)he can when (s)he needs to and thereby does that matters. No silver bullet, but it improves the odds drastically.
Personally, mostly I wouldn't bother looking. But IF for some reason, what and how I'm doing something exposes an interesting bug, I will be looking to see "how come", code included.
You do forensic analysis on the airplanes that crash, to see "how come". You don't scrutinize the ones that are flying with the same severity. Aircraft safety would be much worse if aircraft designers could not obtain any information about crashed airplanes. (Part of the closed-source scenario. The developers do not have access to information about crashed applications. No I am not going to ship my servers, users, configurations and proprietary data to some vendor so that they can maybe get to something in a few months.)
Re:Headline for the article is a troll (Score:3, Interesting)
What the problem? Binary config files don't validate parameters either.
That's part of the problem; they're just text. Put a GUI around it, and all of a sudden you can prevent users from saying that - say - they want to log all output to a file, but they specify a file which is invalid.
Why a GUI? why not CLI, for example?
With a GUI in there, you can tell the user that they've made a mistake while they're editing that file.
That's kind of nice - then your configuration program would rival your real program in complexity. At the same time it's trivial to allow your program to log error messages in case of non-recognisable parameters or missing files/wrong paths. And sometimes your configuration program can't work properly - for example - it's downtime and files on network are nonaccessible and your config program do not allow you to enter them..
Re:Amen! (Score:3, Interesting)
And I really wish I had availed myself of open source.
A few months ago, I wrote a utility which would copy files from one directory to another, if and only if, the files in the destination directory were older than the source files. It turns out that XCOPY wasn't working the way I wanted it to, so I wrote my own utility. Then, I stumbled across rsync while Googling one night...
But I'm still rolling my own, because it would take more time for me to make sense of the documentation. Most OS authors give a very detailed, albeit useless description of their software. It usually goes something like this:
Xdoxmkr is a free implementation of the popular Winmkr software for resyncing Xdox nodes under UNIX. We have used it on our get-apt-xgs server for the past 3 years and it is quite useful. The new release 1.02.78.998_0z99s.dox-version10.2 fixes many of the bugs in the old release, 1.02.78.996_0z99x.dox-version10.1.
Version 1.01.78.999.dox.098 is ready for beta testing! This fixes the primary_resync_down_test bug in the Xdox.h header which would occasionally reindex the first x_node if the z_index and y_offset were different by more than 10 m_syncs.
Some of our users reporting conflicts with the new OpenXMod server when running Xdoxmkr on RedCoat Linux with kernel 2.3.88.01.7.69.10-smp-alpha. The recommended workaround at this time is to recompile OpenXMod with the -df, -rm, -fNoBignumsbutnotFloat_on_x86 flags. Then recompile the kernel with _scsi_super_fast_no_ide option set, flash the BIOS, and toggle the LBA_MODE jumper on the back of /dev/hda. If you're not sure which of your drives is /dev/hda, you can download Peter Friggin's Xdrive here.
Okay.... But what does it do?
I like OS, but I must admit that having English as a second language (as opposed to C++ or Java, etc..) is definitely a hindrance. We need to get our heads out of the sand and look from the perspective of our users.
Re:Headline for the article is a troll (Score:3, Interesting)
Yes, but with binary config files, you have a program which writes those binaries, and which does the validation.
The OP was claiming that plain text files are more than good enough for configuration. His mindset is "well, you can read, can't you?".
Why a GUI? why not CLI, for example?
Whichever you prefer. Radio button choices are easier to make with a GUI, and most end-users will be using a GUI such as KDE or Gnome, so I'd suggest a GUI. If you're doing all of your work from the CLI, you might well want to edit the text config by hand. *shrugs*
That's kind of nice - then your configuration program would rival your real program in complexity. At the same time it's trivial to allow your program to log error messages in case of non-recognisable parameters or missing files/wrong paths. And sometimes your configuration program can't work properly - for example - it's downtime and files on network are nonaccessible and your config program do not allow you to enter them..
Yes, but if you can't access the config file over the network, you can't edit the text-based config file either, so it's a moot point.
And as I said before, it may well be trivial to allow your program to log error messages, but that's of no use if the user only runs into a configuration error several weeks from now. Or the user isn't the person who knows how to edit the config file.
Oh, and if you're too lazy to code up a quick config editor even if it's in TCL or some other similar language, then I'm not sure I really want to use the rest of your code. Mainly because your attention to detail across the project as a whole would appear to be lacking.
some tips for opensource happyness. (Score:2, Interesting)
Some people may take your patch or bug report as a personal attack. The project is probably their baby after all. So make sure when you report a bug, or patch that you are humble about it.
Thank people for their bug reports. They are doing you a favour. If you are nice to them they will probably help you out in the future.
If you can, try and make a patch for the problem rather than make a bug report. Allthough bug reports are still quite useful
Some groups don't apply a patch. If this happens ask them why. Common problems are they can't test your patch, they don't know how to apply it, or there are 500 other patches and they just don't care. Perhaps they don't understand your patch. Maybe they are hiking in Nepal
If you respond to user problems quickly, and fix them your work will decrease. If lots of people ask the same questions on a mailing list, instead of making a FAQ try and answer their questions when they use the software. Then you don't have to get angry and tell people to rtfm.
Credit people for their work. Some projects get lots of patches yet basically claim all of the work as their own. I have make bug fixes, added features and made optimizations to projects that didn't even recognise me as doing those. Made me think twice before spending weeks working on their software.
Some bug fixes, or features take weeks to make. So try and give a little time to help people get their changes into your code base.
Have a Features list on your site. Also have a Problems list. Having the problems list/limitations list can save a lot of disapointment, and time for people. Listing that a function is buggy on such and such a platform, or is slow, etc can be really helpful for people.
One nasty person in an irc channel, or on your mailing list can ruin the reputation of your project, and send away lots of users. Try and persuade that person not to be uncool and heavy
Any other things you can do for a better open source project?
Have fun!
Re:Headline for the article is a troll (Score:3, Interesting)
I would disagree. In my experience, early versions of open source projects will attract more patches as a result of their immaturity - they are less refined and any bugs that exist are more obvious and usually easier to fix. As time goes on the project becomes more defined feature-wise and only the hard to find/fix bugs are left.