Cathedral and Bazaar

metaphor

Source: Architecture and Building → Software Engineering, Organizational Structure

Categories: software-engineeringorganizational-behavior

Transfers

Eric Raymond’s 1997 essay uses two built environments as competing models of software development. The cathedral is planned by a master architect, built over decades, and revealed to the public only when complete. The bazaar is a noisy market where many vendors set up stalls, compete for buyers, and iterate daily. Raymond maps these onto closed-source (GNU Emacs, GCC under centralized control) and open-source (Linux kernel, fetchmail) development respectively.

Key structural parallels:

• The cathedral has one architect; the bazaar has many vendors — cathedral development assumes a single design authority whose vision unifies every stone. Bazaar development assumes that coordination emerges from many independent contributors responding to each other’s work. The metaphor frames the choice between centralized vision and distributed intelligence as an architectural decision about what kind of structure you’re building.
• Cathedrals are revealed; bazaars are always open — a cathedral is hidden behind scaffolding until its consecration. Closed-source software ships in discrete releases, each a grand unveiling. A bazaar never closes; new goods appear continuously. Open-source projects release early and often, with the code always visible. The metaphor reframes release strategy as a question of architectural publicity.
• Cathedral quality comes from control; bazaar quality comes from selection — the master builder inspects every stone. In the bazaar, bad fruit rots on the stall while good fruit sells. Raymond’s “given enough eyeballs, all bugs are shallow” is the bazaar’s quality mechanism: competitive exposure rather than centralized inspection.
• The cathedral serves one god; the bazaar serves many customers — cathedral development optimizes for a coherent vision. Bazaar development optimizes for user needs, which may be contradictory. The metaphor frames the trade-off between aesthetic coherence and market responsiveness.
• Cathedrals outlast their builders; bazaars reconfigure daily — the permanence of stone versus the fluidity of temporary stalls. Cathedral software aspires to longevity and stability (Oracle, SAP). Bazaar software accepts impermanence and rapid evolution (npm packages, Linux distros). The metaphor imports temporal assumptions about how long the work should last.

Limits

• Cathedrals and bazaars coexist in the same city — Raymond presents them as opposed philosophies, but medieval cities had both. Modern software projects similarly blend centralized architecture with open contribution (Linux has Linus as benevolent dictator; Apple open-sources Swift). The metaphor creates a false dichotomy where the reality is usually a hybrid.
• The metaphor romanticizes the bazaar — actual bazaars are chaotic, sometimes fraudulent, and full of low-quality goods mixed with good ones. Raymond selectively imports the bazaar’s virtues (diversity, responsiveness) while ignoring its failure modes (counterfeit goods, race-to-the-bottom pricing, no accountability). Open-source has analogous problems — abandoned packages, malicious dependencies, no support — that the metaphor aestheticizes away.
• Cathedrals are not designed by one person — medieval cathedrals employed hundreds of masons, each with specialized skills, working across generations. The “single architect” framing is historically inaccurate and overstates the autocracy of closed-source development. Even the most controlled proprietary teams involve collaboration.
• The metaphor maps poorly to modern SaaS — neither cathedral nor bazaar fits continuous deployment, feature flags, and A/B testing. Modern software development has moved beyond both models into something more like a factory with real-time demand sensing. The 1997 dichotomy is increasingly anachronistic.
• Stone does not fork; code does — the deepest structural difference between built environments and software. A cathedral cannot be copied and modified; a bazaar stall cannot be cloned. Software can be forked infinitely. The metaphor imports physical constraints of uniqueness that do not apply, making the cathedral seem more restrictive and the bazaar more open than they structurally need to be.

Expressions

• “Release early, release often” — the bazaar vendor who brings fresh goods every morning, Raymond’s central operational maxim
• “Cathedral-style development” — pejorative shorthand for slow, secretive, control-heavy processes
• “Given enough eyeballs, all bugs are shallow” — the bazaar’s distributed quality mechanism, known as Linus’s Law
• “Benevolent dictator for life” — the hybrid figure who presides over a bazaar with cathedral authority, revealing the metaphor’s tension
• “Open the code” — inviting the public inside the cathedral, converting it to a bazaar
• “We’re building a cathedral, not shipping prototypes” — the defense of centralized control, invoking sacred craft against market expediency

Origin Story

Eric Raymond presented “The Cathedral and the Bazaar” at the Linux Kongress in 1997 and published it as an essay that became the intellectual manifesto of the open-source movement. Raymond drew on his experience maintaining fetchmail to argue that Linux’s distributed, publish-everything model produced better software than the traditional closed model exemplified by GNU Emacs under Richard Stallman’s tight control.

The essay’s architectural metaphor was immediately influential. Netscape cited it when deciding to open-source the Mozilla browser in 1998. The term “open source” itself was coined partly to give Raymond’s bazaar model a more business-friendly name. The cathedral/bazaar dichotomy became the default framing for proprietary-vs-open debates for two decades, even as actual development practices moved beyond both poles.

References

• Raymond, Eric S. “The Cathedral and the Bazaar” (1997, revised 2000) — the original essay
• Raymond, Eric S. The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (1999) — book-length expansion
• Moody, Glyn. Rebel Code (2001) — history of Linux and open source that contextualizes Raymond’s argument

Related Entries

• Pattern Language as Shared Vocabulary
• Software Habitability

Contributors: agent:metaphorex-miner, fshot