What is the cathedral and the bazaar?
Engineering culture and software practice
"The cathedral and the bazaar" is Eric S. Raymond's 1997 comparison of two software-development styles. The cathedral is built by a small group that develops largely out of public view and releases carefully prepared versions. The bazaar develops in the open, releases frequently and invites a broad community of users and contributors into the process. Raymond used the contrast to explain the success of Linux-style open development, and the essay became a foundational text of the open-source movement.
What this means
Raymond's metaphor contrasts two pictures of how software gets made. A cathedral suggests a small number of architects working to a coherent plan, revealing the work when it is ready. A bazaar suggests many people arriving with different needs, trying things, exchanging ideas and improving what they can see.
The essay argued that software could be developed surprisingly effectively through the second model. Instead of treating users as passive recipients, a project could turn some of them into testers, bug reporters and co-developers. Instead of saving changes for infrequent grand releases, maintainers could "release early, release often" and learn from rapid feedback.
The metaphor was powerful, but reality is less binary. Successful open-source projects usually have gatekeepers, maintainers and architectural judgement. Closed teams can release frequently and gather excellent user feedback. The enduring value of the essay is therefore not a rule that bazaars always win. It is a set of questions about openness, feedback, contribution and who gets to inspect and improve the work.
Why it matters
A small organisation may buy relatively little software in the traditional sense while depending on enormous amounts of open-source code. Frameworks, libraries, operating components and transitive dependencies can reach the business indirectly through products it uses. The bazaar is therefore not an ideological curiosity. It is part of the supply chain.
Open development can bring substantial advantages. Bugs can be reported by users with different environments. Skilled contributors outside the original team can propose fixes. A project can continue beyond one firm's immediate commercial priorities. Public code and discussion can make technical choices inspectable.
None of that guarantees quality. Somebody still has to review contributions, make releases, respond to vulnerabilities, maintain infrastructure, resolve disputes and decide which changes belong. A project with thousands of users may rely on a handful of maintainers doing work few users see. Openness expands the possible pool of reviewers and contributors; it does not force enough qualified people to show up.
That makes the essay useful from a buyer's chair. The right question is not simply "Is this open source?" It is "How is this particular project governed, maintained, funded and secured, and what happens if its key maintainers stop?"
How it works
Where the term came from
Eric S. Raymond first presented "The Cathedral and the Bazaar" in 1997 while reflecting on Linux and his own experience developing Fetchmail. The essay circulated online, evolved through revisions and became the centrepiece of an O'Reilly book published in 1999. It arrived at an important moment in the movement from the older "free software" vocabulary towards the business-friendly language of "open source".
Raymond described the cathedral as software carefully built by individual experts or small groups, with releases made when the developers considered the work ready. The bazaar represented the Linux model as he saw it: development exposed to a large community, frequent releases and users recruited into debugging and development.
The essay became enormously influential, but "foundational" should not be confused with "final word". It was an argument from observed projects and experience, not a controlled experiment establishing a universal engineering law.
The bazaar depends on fast feedback
Several of Raymond's famous rules are really feedback rules. Start with a problem that matters to somebody. Recognise when existing work can be reused. Treat good users as a development resource. Release early enough that real use can reveal mistaken assumptions. Release often enough that contributors see their work move.
That model changes the economics of information. A cathedral team has to discover many problems itself or through a bounded testing programme. A bazaar project can expose unfinished work to more environments and more specialised users. A strange hardware combination, obscure locale or uncommon workload may be tested by the person who actually has it.
Raymond's observation later known as Linus's law says, in essence, that enough suitable eyes can make bugs easier to find and understand. The qualifier "suitable" matters. Code sitting publicly on a server does not inspect itself.
The best bazaars are therefore not leaderless crowds. Maintainers filter reports, review changes, preserve coherence and decide when to release. Openness can distribute discovery and contribution while authority over the accepted code remains quite concentrated.
The critique is about idealising the crowd
Nikolai Bezroukov's 1999 First Monday critique argued that Raymond overgeneralised from particular open-source successes and understated similarities between open projects and other forms of organised research and development. Among other things, the critique challenged a romantic reading of the bazaar as spontaneous decentralised production.
That criticism has aged well in one respect: many celebrated open projects depend on strong central maintainers, established architecture and social rules governing who can merge changes. A thousand people may report bugs while three people decide what enters the release. Calling the project a bazaar does not eliminate hierarchy.
Heartbleed supplied a memorable security warning in 2014. The serious OpenSSL flaw existed in publicly available code despite the theoretical possibility of widespread inspection. It did not prove that open review is useless. It showed the gap between code being available for inspection and enough skilled, resourced people actually inspecting the right code. The many-eyes claim is a possibility created by openness, not a quality guarantee.
Someone still has to maintain the roads
Nadia Eghbal's 2016 Ford Foundation report Roads and Bridges reframed open-source software as digital infrastructure. Widely used components can resemble public infrastructure in their economic importance while being maintained by individuals or small groups with little stable funding.
This creates a structural mismatch. A library can sit deep inside thousands of commercial products while its maintainer receives no direct signal about the value generated downstream. Popularity can increase work rather than resources: more issues, support requests, security reports and compatibility expectations arrive.
The sustainability question is therefore not an argument against open source. It is part of understanding it. Organisations that depend on community infrastructure should care about maintainer concentration, governance, funding and whether the project can sustain routine maintenance rather than merely attract occasional new features.
What a buyer should inspect
Start with governance. Who can approve releases? Is the project controlled by one person, a company, a foundation or a broader maintainer group? Look at maintainer activity and concentration, not just contributor counts. Ten thousand historical contributors do not help if nobody currently has time to review a security fix.
Then examine release and security practice, dependency depth, the licence, project funding and how users obtain support. Open code can make technical due diligence easier because evidence is visible, but visibility does not perform the assessment for you.
There is also a corporate version of the bazaar, usually called inner source: organisations apply open contribution practices to software shared internally, even though the code is not public.
The same metaphor applies only partly to community-built AI models. Open participation, visible issues and frequent releases can resemble the bazaar. But a model is not simply source code. Weights, training data, data rights, evaluation methods and the compute required to reproduce training may be unavailable. A model repository can therefore look socially open while remaining difficult for outsiders to reproduce or materially modify. That is why the separate question of open-source AI needs its own definition.
Examples
An illustrative 40-person retailer uses an ecommerce application that depends on dozens of open-source packages. Procurement initially records the commercial application vendor as the only technology dependency. A technical review reveals that one critical library is maintained by a very small group. The business does not abandon open source; it adds maintainer health, security response and dependency exposure to its supplier and architecture reviews.
A charity chooses between two libraries for a new public-facing service. One has far more stars and historical contributors, while the other has a smaller community but regular releases, several active maintainers, clear security reporting and documented governance. The cathedral-and-bazaar lesson is not "pick the biggest bazaar". It is to inspect how the community actually converts attention into maintained software.
A software company opens an internal component to contributions from every engineering team. Contributions increase, but so does review work for the two original maintainers. The firm has created an inner bazaar without funding its gatekeepers. It responds by allocating maintainer time and publishing contribution boundaries, preserving openness while making the review load explicit.
Common misunderstandings
Misunderstanding: Cathedral means proprietary and bazaar means open source. Correction: the categories describe development styles more than legal ownership. Source can be public while development remains tightly controlled, and private organisations can adopt bazaar-like collaboration internally.
Misunderstanding: Open code is automatically better code. Correction: openness creates opportunities for inspection, testing and contribution. Quality still depends on maintainers, reviewers, users, architecture, security practice and sustained attention.
Misunderstanding: The bazaar has no leaders. Correction: successful open projects often have strong maintainers who review changes and preserve coherence. Distributed contribution and concentrated decision authority can coexist.
Misunderstanding: The cathedral and the bazaar is the same idea as worse is better. Correction: it is not. Raymond's essay is mainly about development organisation, participation and feedback. "Worse is better" is an argument about design and implementation characteristics that can help software spread.
Misunderstanding: The essay settles whether an AI model is open source. Correction: it does not. Modern AI raises separate questions about model weights, training information, licensing, reproducibility and compute that the 1997 software metaphor was not designed to answer.
Risks and boundaries
The cathedral and bazaar are ideal types, not a complete taxonomy of software development. Most mature projects mix them. Maintainers may develop a major feature privately, then expose it for community testing. An open project may have a highly centralised release process. A commercial team may release publicly every day while accepting no outside code.
Raymond's strongest claims should also be read historically. Linux demonstrated that distributed open development could produce infrastructure of extraordinary importance, but it did not establish that crowd size mechanically determines quality. Heartbleed and later sustainability debates show why reviewer attention and maintainer capacity matter.
From a business perspective, the opposite mistake is treating open source as inherently unsupported. Many projects have mature governance, professional maintenance and diverse institutional backing. Risk depends on the particular component and the organisation's dependence on it, not on whether its development resembles a bazaar in the abstract.
What to do next
Know what open-source software the organisation materially depends on, including important transitive dependencies where practical. Prioritise components whose failure or abandonment would disrupt critical services.
For important projects, inspect maintainers as carefully as features. Look at who can release, how concentrated responsibility is, whether security reports receive attention and whether routine maintenance continues.
Treat licence, governance and support as separate questions. An open licence does not tell you who will answer an urgent operational problem, and a healthy contributor community does not remove the need to understand licence obligations.
Where the organisation receives substantial value from a community-maintained component, consider how that maintenance is sustained. Funding, paid maintainer time, foundation membership or contributing useful engineering work are different mechanisms, but the underlying principle is the same: critical infrastructure needs somebody with time to maintain it.
For community AI models, do not use "bazaar" as shorthand for openness. Check what is actually available and modifiable, including weights, code, documentation and relevant licence terms, and keep that assessment distinct from the vibrancy of the surrounding contributor community.
FAQs
Who wrote The Cathedral and the Bazaar?
Eric S. Raymond wrote the essay, first presenting it in 1997 and later publishing it as part of an O'Reilly book in 1999.
What is the cathedral model?
It is Raymond's metaphor for software developed mainly by a small, controlled group and released when that group considers it ready.
What is the bazaar model?
It is a more open development model involving frequent releases, broad user feedback and contributions from a larger community.
What does "release early, release often" mean?
It means exposing useful versions to users frequently so that feedback, testing and contribution can happen throughout development rather than only near the end.
Does open source guarantee more secure software?
No. Openness permits broader inspection, but security depends on whether capable people actually review, maintain and respond to problems in the code.
What did Heartbleed show?
It showed that a serious vulnerability can persist in widely used open code. Public visibility creates the possibility of review, not a guarantee that adequate review occurs.
Why does maintainer funding matter?
Popular open-source components can create substantial review, support and security work while having only a few maintainers. Sustainable attention matters as much as contributor numbers.
Does the bazaar model describe open-source AI?
Only partly. Community contribution can resemble a software bazaar, but AI openness also depends on what model artefacts, training information and rights are actually available.