VicC > interesting link. I'm going to post some of the myths they bring up here:

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.


Myth: New developers interested in the project will best learn the project by fixing bugs and reading the source code.

Reality: Reading code is difficult. Fixing bugs is difficult and probably something you don't want to do anyway. While giving someone unglamorous work is a good way to test his dedication, it relies on unstructured learning by osmosis.


Myth: Installation and configuration aren't as important as making the source available.

Reality: If it takes too much work just to get the software working, many people will silently quit.


Myth: Even though your previous code was buggy, undocumented, hard to maintain, or slow, your next attempt will be perfect.

Reality: If you weren't disciplined then, why would you be disciplined now?


Myth: Users don't mind upgrading to the latest version from CVS for a bugfix or a long-awaited feature.

Reality: If it's difficult for you to provide important bugfixes for previous releases, your CVS tree probably isn't very stable.


These are only a few of the points brought up in the article VicC posted (for those of you who didn't read it) and are all valid arguments. I'd say anyone who hasn't taken a peek at it already probably should.


qod > I agree. Waiting for a fix from a closed source vendor is a pain. Open source projects are indeed nice since you can get fixes from multiple sources, or even do it yourself. I would throw the quality of the code being pushed into question however. If you are getting fixes from others I would make doubly sure that the code you're getting is safe to run, and verify that it fixes the problem and doesn't compromise the functionality of the system elsewhere. Depending on the scope of the problem it is possible for educated users to fix something themselves. Also depending on the issue this could open other holes due to a less than thorough understanding of what is being done or the system as a hole. If these projects had a thorough set of automated test scripts (and some do) to run for regression testing purposes I think I'd feel a bit better.