From my experience, the bazaar model is generally superior to the cathedral model for software development.

The bazaar is far superior when it comes to bugs: in terms of reporting bugs, fixing bugs, and releasing bug fixes. The tenth lesson for good software development is “If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource”. A lot of the benefits of beta-testers are in finding and reporting bugs. For a bazaar-style hacker, bugs are a fun challenge, and a user who uses the software frequently will be highly motivated to submit a bug report for something that is annoying them (provided, of course, that the software is not so buggy that it drives them away), since it directly impacts them. (This “selfishness” is also the reason many developers contribute to projects in any fashion, or even start or maintain their own.)

Fixing bugs is also more effective when it is so distributed. The cathedral model forces a few developers who are highly familiar with the code to search for a fix when they would rather be working on other, more glamorous tasks. This works for bugs where you know the culprit as soon as you see the report, but many are trickier than that—and having many fresh eyes on the problem is effective because chances are one of those people will find the issue. Once a bug is fixed in the source code, the last problem is to distribute this version to end user, and once again the bazaar is superior. Raymond says to “Release early, release often”, which is clearly helpful to the end user, who does not have to wait weeks or months between releases, working with a buggy piece of software. There is also a psychological benefit for contributors to see their work implemented and released quickly; in a cathedral project the payoff will be delayed by infrequent releases, and in some cases the project leadership will reject outside contributions or make the outsider jump through a bunch of hoops.

However, the bazaar model is far from perfect, nor is it a silver bullet that will propel any project to instant success. It has limitations that require extra care and attention. For example, people are free to start contributing to the project whenever they want—and many do—but this also means they can leave whenever they want. This allows for fresh ideas, but too much churn wastes time on familiarizing new joiners with the standards and the codebase, and valuable experience is lost if it isn’t passed down. Furthermore, a multitude of contributors means a multitude of coding styles and skill. Experienced members will have to take time away from writing code to guide these people, particular new members. Of course, it is worth it if they turn into experienced members themselves who can help improve the process with their knowledge.

By definition, the cathedral and the bazaar are mutually exclusive (a project can’t be developed both in the public eye by a multitude of people and by a small, restricted group), but there can be a hybrid of both, which I believe is the future of software development. Many of the largest, most popular open-source projects are run by commercial companies (such as Facebook’s React and Microsoft’s VSCode) who pay full-time developers/managers, drive development, and make major decisions about project direction. However, these projects also incorporate many aspects of the bazaar model, like encouraging volunteer bug reports, feature requests, and contributions through a thorough contributing guideline.