Over the past couple of years as a Computer Science major, I've become pretty fascinated by open source both as a social phenomenon and as an approach to programming. Stallman's talk last semester especially got me thinking about these things. Though I felt I needed to be careful to take what he said with a grain of salt, the idea that we could be working together to create software for each other rather than coding only for our own personal profit really appealed to me.
This essay seemed to encourage this same optimistic approach without the dogmatic attitude. Raymond claims that the open source approach is not the best because it is morally superior, but because it is practically more efficient. He refers to open source as "bazaar" style programming, where a large and diverse community contributes to a project voluntarily. He sets this approach in contrast to "cathedral-building" style, where a small group of dedicated programmers try to build a focused masterpiece from the ground up.
It's hard for me to say whether Raymond's characterizations are correct, mostly because of my lack of experience in either field. Even though by now I've worked on various projects, I don't think I've done anything quite on the scale that he's talking about, and I've mostly worked alone. What I can say is that I think he's generalizing a bit too much. It's understandable the he would want to have only two categories of programming to talk about in his essay, but I'm not sure that I would agree that all closed-source projects follow such a strict and inflexible process that is implied by "cathedral-building."
Raymond seems to believe that his "bazaar" approach is always the best way to go. While it definitely seems that some projects are naturally suited for this style of contribution, I don't think this applies to every project. For open source to work, and application must have a large enough user base for people to spot bugs, and enough dedicated and skillful users who will actually want to contribute. This works well for a mail client (who doesn't use email?) but may not be as efficient for a more specialized product.
For example, say you're writing software for architects like AutoCAD. The user base is very limited, and while those users may be working with the software very closely (and thus able to spot bugs) you may have the problem that Raymond mentions where they are not able to articulate those bugs very well. Also, when you have a large and diverse user base you are much more likely to have programmers in that mix, but if you're writing to a specialized group like architects, it is much less likely that your users will be architects and ALSO know how to code.
Another issue that arises with specialized software is that the programmers writing it must dedicate a lot of time to understanding the problem they are trying to solve. For example, if you are writing a program that is supposed to simulate biological phenomena, you better have a good understanding of the underlying biological systems, and most people don't. An open source approach might introduce problems with the conceptual design of the program, or it might just not generate much interest outside of the specialized field.
So, as it turns out, I think that the more specialized the problem, the more likely it is that the "cathedral" approach might actually work better as long as you avoid some of its problems by keeping groups small and communication lines open, while projects that are intended for the masses are better written by the masses using the "bazaar" style of programming.
