Myths About Open Source Development

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."

Comments

Headline for the article is a troll

[Aron S-T]

Nearly all of the article's "myths" are relevant for all software development, not just FOSS. As for the first myth, and the one cited in the posting, that's just a troll. I don't think anyone believes that just releasing code makes it useful or desirable. In other words, this article should have titled: 7 Myths about Software Development. As such, it's not bad, although I didn't find any deep insights in it.

----------------
Mythical Man Month Methodology
http://fourm.info/

Re:Headline for the article is a troll

[chromatic]

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:

You may not be counting, but there are about a dozen active perl 5 developers on p5p, about half with commit rights. Similarly parrot has about 5 active committers.

This is the number of competent volunteers that a well established 16-year old programming language used by many individuals and many organisations can muster. From the entire world.

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.

Good points on ease of installation

[Anonymous Coward]

Congrats to chromatic for offering several points about ease of use, especially regarding installation, which are often missed. In particular:

- "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

[maraist]

I find that open source is not so valueable in that people inspect my code and provide feedback. Instead I find the following realizable benifits:

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.

Re:myth 9:

[aoteoroa]

The surprising fact is that many girls seem genuinely interested to hear about life in the tech world. I used to try to avoid all talk of software programming because I thought that girls would find in a turn off. But I've found that when a person is interested in you she will want to know everything about you and that includes what you do at work. The problems you face, and how you solve them.

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"

[chromatic]

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.