While I agree with all nineteen lessons that Eric Raymond presents in his paper, The Cathedral and the Bazaar, I believe there is more to the story. Specifically, there are several other issues that can cause the bazaar model to fail, or at least not to succeed spectacularly the way it did with Linux and fetchmail. To illustrate these issues, I draw on the development of Linux and fetchmail and my own experiences as a developer of both Macintosh® shareware, which is effectively closed source but can still generate massive amounts of user feedback, and Linux software (JX, Code Crusader, etc.), which has not yet become a bazaar but whose license has evolved towards open source.
The cathedral and bazaar models are only two regions of a spectrum that ranges from fondling ones code in the dark and never even releasing binaries to making it public domain. While the developer can set limits on how open the source is, many types of projects have built in limits that keep them from becoming a full blown bazaar, even if the license allows it. Note that I consider a project to be a bazaar only if it has a large number of active developers, not just fan mail and suggestions, because this is what speeds development the most and truly sets it apart from the cathedral model.
The primary limitation is the technical sophistication of the intended audience. If the software is intended for hackers, and it catches on, the bazaar will thrive. Above and beyond the reasons that Raymond gives in his paper, I believe this is the real reason why Linux provides the ultimate example of the bazaar model. Hackers love the idea of having a powerful operating system that runs on their home computer and full access to the source so they can either tinker with it or write stuff on top of it. There are unlimited opportunities for every type of hacker to contribute, from writing hardware drivers to porting existing programs from other UNIX variants. Raymond's fetchmail was successful for the same reason. At this stage in the evolution of desktop computing, the people who run Linux at home and access the Internet via an ISP are computer savvy. Those who aren't computer savvy are using Windows® and visual software provided by companies like AOL.
In contrast to projects like Linux and fetchmail, a program that hackers consider either useless or "only for wimps" is much less likely to generate a lively bazaar. As passionate as I am about designing good visual interfaces, I would never bother with a program like Quicken that balances ones checkbook. I can pay a bill by scribbling on a check in less time than it takes a computer to boot up, and since math is one of my strong points, balancing my checkbook is trivial. My college German teacher, however, hated math and once joked that balancing a checkbook belonged to the realms of higher mathematics. He might well enjoy using a program like Quicken, but he wouldn't even be interested until it was stable and polished, after development had given way to maintenance and the programmers had moved on to other, more exciting projects.
A less serious limitation, which may cause a bazaar to merely smoulder instead of blaze, is that most people have a job to do and just want tools to make it easier. I have heard from many people who would like to help develop one of my tools but can't because their boss doesn't want them "wasting" time at work, and their spouse and kids are more important when they are at home. Of course, the truly dedicated hackers make time in spite of such issues, but this is nevertheless probably the single largest drain on the manpower and talent available for bazaar projects.
The programming language used for the project also reduces the pool of people who might contribute. As an example, my IDE, Code Crusader, is written in C++, but most of the people who have requested Java support only know Java.
Yet another drain results from the fact that reading and understanding other people's code is a skill which not everybody has. Like many hackers, I initially learned by rewriting other's code (on my Apple II+, in BASIC!), but I know at least one highly talented programmer who will do almost anything to avoid working on any code other than his own.
None of these issues are meant to discourage anybody from using the open source model and trying to encourage the formation of a bazaar, however. They are only reasons why one shouldn't be discouraged if one doesn't get the same level of response that Linus Torvalds or Eric Raymond did. There are plenty of other reasons not to limit the availability of the source, many of which are explained at OpenSource.Org.
The reason that I find most compelling is that openness towards ones users will encourage feedback. This is very important because most users will silently either accept the program or switch to something else. Anything that encourages them to contact the developer is therefore a Good Thing.
Feedback is invaluable, even if it doesn't include contributions of code, because it provides the developer with encouragement to keep going, ideas for new features, and even ideas for new projects. One must be careful, however, because suggestions and submissions of code each provide ways to derail a project.
Suggestions require very little effort from the user. Any off-the-wall, spur-of-the-moment idea can be emailed to the developer in a matter of seconds. This requires that the developers have strong enough design abilities to read between the lines and understand what the user really wants because experience shows that most users, when given what they asked for, very quickly decide that they really wanted something at least slightly different. The adage, which should be famous if it isn't already, is "Listen to your users, but ignore what they say." [3] While the time required to iterate to the final solution is dramatically reduced by releasing "early and often", it helps a lot to be able to get it right the first time if one is doing most of the coding oneself. This is especially important to me on the Macintosh® where very few of my users even have access to a compiler. Endless redesigning of existing features will cause any project to grind to a halt.
Submissions have the advantage that they have usually been tested, so they will do what the submitter really wanted, as opposed to merely what the submitter initially envisioned. In addition, the effort required to write and test the code acts as a filter to dramatically improve the average quality of submissions. If it is something that would be only marginally useful or merely cute, nobody is likely to do it.
However, in spite of this advantage, submitted code can actually be more dangerous than suggestions. The trap arises from the possibility that the code may not be the most general solution to the problem because the submitter had a specific case in mind and didn't have the time and/or the imagination to look beyond it. As a result, it will often be tested only on the specific cases for which it was developed. This means that it may fail in other situations. If nobody has the expertise to fix it or if the project only has a few active developers all of whom are busy with other issues, it may take a relatively long time before the problem gets fixed, so one will either accumulate grumpy users or simply lose them. To avoid this, somebody needs to be responsible for checking submissions before merging them into the master source and for ripping out buggy submissions that are accidentally released.
Thus it appears that a strong leader who is also a good designer is necessary for a successful bazaar. As an example, everybody respects Linus Torvalds as the leader of the Linux project, so when he makes a firm decision after carefully considering the issues, the decision sticks, regardless of how heated the argument becomes. The facts that these decisions have consistently been proven right and that he is otherwise very easy going and likeable keep the effort from exploding into a flamewar. In addition, by enforcing a careful separation between stable and development releases of Linux, he has made it accessible to the widest audience: those who want a stable operating system for running applications and those who want to work on the kernel.
My experience with the egcs project at Cygnus also supports the necessity of a strong leader, though in the opposite way. After adjusting some of my C++ code to compile on egcs 1.0.3, users began to report that the resulting binary crashed when a particular feature was invoked. Since I had never heard of these crashes when compiling with g++ 2.7.x, I suspected a bug in the compiler. After laboriously verifying this with a debugger and then whittling the code down from 9MB to 60 lines to demonstrate the simplest possible case that still crashed, I submitted a bug report. The response I got was nothing less than astounding, to the effect that "That bug is caused by code submitted by so-and-so. When he submitted it, I told him that it would cause this problem, but he didn't care." In other words, nobody had the authority to veto submissions, even when they knew it wouldn't work.
At the time, I refused to rewrite my code to get around their bug, and Linus Torvalds, who later found a problem in the egcs C compiler that prevented him from compiling the Linux kernel, announced the same attitude. This is precisely the "disgruntled user" problem discussed earlier. With the egcs attitude, any project will eventually fail due to an accumulation of bugs that never get fixed. Even Microsoft projects have died from this, and they have historically been able to ram almost anything down their customers' throats. Every project needs somebody who has the authority to say no and is willing to use it.
Unfortunately, picking the leader can be a problem. When one person initiates a project and does all the development leading up to the beginning of the bazaar, then picking that person as the leader is obvious. If several people are involved from the start, it helps to remember a statement by the British politician Lloyd George about the army: "It is not a question of one general being better than another, but of one general being better than two." [2] The reasons for this are simple. Bickering between leaders can easily lead to chaos, and accountability is lost because each can easily blame the other. [4]
More specific advice is hard to provide because the optimal arrangement depends on the personalities involved. One possibility, which is used by the developers of the Apache web server, is for each person to have a vote and to simply let the majority win. Unfortunately, this only works as long as everybody is well informed about all the relevant issues and is willing to accept the result of the voting. My preferred method, which I evolved independently, is the hierarchical organization used by Linux, where each person is responsible for the modules that they designed and know the most about, and one system architect coordinates everything. This appears to be the only method that scales well to very large projects. [1] Suggestions and submissions are sent to the person responsible for the component, and the fact of their existence is propagated to the system architect for incorporation into stability and release decisions.
In summary, for a bazaar to be truly successful, the project's audience must include enthusiastic programmers who have spare time, are skilled with the programming language being used, and are willing to dig into others' code. In addition, the project must have a strong leader who can manage suggestions and submissions to both keep the project moving and prevent it from deteriorating into chaos.
[1] Brooks Jr., Frederick P. The Mythical Man Month, 20th Ann. Ed. Reading, MA: Addison-Wesley.
[2] Quoted in Churchill, Winston S. The Gathering Storm, p. 123. New York: Bantam Books, 1974.
[3] Cooper, Alan. About Face, The Essentials of User Interface Design, p. 549. Foster City, CA: Programmers Press, 1995.
[4] Hamilton, Alexander, John Jay, and James Madison. The Federalist, No. 70. New York, NY: Random House.
[5] Raymond, Eric. The Cathedral and the Bazaar