The Cathedral and the Bazaar and IRC

I'm going to start this by extracting all the rules of open-source development from the essay and making a list.

1. Every good work of software starts by scratching a developer's personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. "Plan to throw one away; you will, anyhow." (Fred Brooks, The Mythical Man-Month, Chapter 11)
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9.  Smart data structures and dumb code works a lot better than the other way around.
10.  If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

This list of rules outlines the sound strategies Raymond implemented during a successful attempt at starting an open-source project.  He then documented his thoughts and motivations during the execution of that project.  He modeled his attempt after what he perceived as Linus Torvalds' successes with the Linux OS.

Another list worthy of note ... the closed-source program manager's five functions:

1. To define goals and keep everybody pointed in the same direction
2. To monitor and make sure crucial details don't get skipped
3. To motivate people to do boring but necessary drudgework
4. To organize the deployment of people for best productivity
5. To marshal resources needed to sustain the project

Raymond tries to explain why these functions are necessary, but instead explains why open-source makes them unnecessary.  They don't need to marshal (defend) resources because everybody brings his own toys.  They don't need to organize for best productivity because only the best of the best get any attention in the elitist open-source culture.  There's no need to motivate or monitor people who are volunteering to do the work in the first place.  The goals of open-source projects are elicited by the leaders of the project and elaborated upon by the beta-users and co-developers, rather than a committee that gets the goals wrong 60 - 75% of the time anyway.

This essay has pretty much sold me on the effectiveness of open-source software development.  Toward the end of the essay he says, "Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment predicts efficiency."


IRC was remarkably easy to set up.  I'm currently using the windows version of Gnome Empathy, which supports IRC as a chat method.  A quick search of the Pidgin website detailed how to set up an IRC room.  Joining the mailing list was also quite easy.