Raymond's Metaphor
In his 1997 essay (later expanded into a book), Eric S. Raymond compared two radically different development philosophies using architectural metaphors:
The Cathedral Model
Software is built like a medieval cathedral:
- Centralized Design: A master architect (or small team) plans everything
- Controlled Access: Only authorized builders work on the structure
- Secretive Development: Work happens behind closed doors until the grand unveiling
- Long Release Cycles: Years between versions, each a complete "finished" work
- Top-Down Authority: Users receive what the architects decree
Examples: Microsoft Windows, Adobe Photoshop, Apple macOS (traditional commercial software)
The Bazaar Model
Software is built like a bustling Middle Eastern bazaar:
- Decentralized Collaboration: Anyone can propose changes, improvements, or features
- Radical Openness: All code is visible; development happens in public
- Rapid Iteration: "Release early, release often"—weekly or daily updates
- Peer Review: Multiple eyes catch bugs ("Given enough eyeballs, all bugs are shallow")
- Bottom-Up Emergence: Features evolve from user needs, not corporate roadmaps
Examples: Linux kernel, Apache web server, Mozilla Firefox, most open-source projects
The Revolutionary Claim
Raymond's essay challenged conventional wisdom in the 1990s. The prevailing belief was:
- Complex software requires centralized planning (Cathedral model)
- Letting "amateurs" contribute would create chaos
- Keeping source code secret protected intellectual property and quality
Raymond's counter-argument:
- Linux (Bazaar model) rivaled or exceeded commercial OSes in quality
- Open collaboration produced more innovation, not less
- Transparency led to faster bug fixes and better security
Archaeological Implications
The Cathedral/Bazaar distinction directly predicts digital resilience:
Bazaar → Vivibyte Path
Open-source projects (Bazaar model) create artifacts that tend to survive:
- Public Documentation: Standards are openly published, enabling third-party implementation
- No Single Point of Failure: If the original maintainer disappears, someone else can fork the project
- Community Ownership: Users feel invested; they'll preserve what they helped build
- Format Accessibility: File formats are documented and reproducible
Example: The .ogg audio format (open standard, bazaar-developed) can be implemented by anyone. If the original organization vanishes, the format lives on.
Cathedral → Petribyte Risk
Proprietary software (Cathedral model) creates vulnerability:
- Vendor Lock-In: Only the creator knows how it works
- Orphaned Software: If the company goes bankrupt, the software dies
- Format Secrecy: Proprietary file formats become unreadable without original software
- License Expiration: Users can't maintain or extend abandoned projects
Example: Adobe Flash (Cathedral model) died when Adobe decided to kill it. No user could fork Flash and keep it alive—the source code was closed.
Linus's Law
Raymond's most famous observation, named after Linus Torvalds (creator of Linux):
"Given enough eyeballs, all bugs are shallow."
Meaning: With enough people reviewing code (the Bazaar model), bugs are found and fixed quickly. Cathedral models, with limited reviewers, let bugs hide longer.
Archaeological corollary: Bazaar artifacts are more likely to be understood by future archaeologists because many people have studied them. Cathedral artifacts may be black boxes—no one outside the company knows how they work.
The Hybrid Reality
Many modern projects blend both models:
Corporate Open Source
Companies like Google, Microsoft, and Meta release open-source projects (Bazaar transparency) but retain control over direction (Cathedral authority):
- Google's Android: Open source, but Google controls core features
- Microsoft's VS Code: Open repository, but Microsoft decides what gets merged
Benevolent Dictator for Life (BDFL)
Some Bazaar projects have a single leader who makes final calls (Python's Guido van Rossum, Linux's Linus Torvalds). It's collaborative (Bazaar) but with centralized decision-making (Cathedral).
Dual Licensing
Software released under both open-source and commercial licenses. The code is visible (Bazaar), but commercial users pay for support (Cathedral revenue model).
The Archaeologist's Preference
From a preservation standpoint, Bazaar artifacts are preferable:
- Self-Documenting: Open development discussions serve as historical record
- Forkable: If abandoned, anyone can revive the project
- Transparent Failures: When Bazaar projects fail, we can study why (all decisions are public)
- Community Memory: Multiple contributors remember the project's history
Cathedral artifacts, when abandoned, become mysteries. No public record of decisions, no community to ask, no source code to examine.
Field Notes
The Firefox Miracle: When Netscape (Cathedral model) was losing the browser wars to Internet Explorer, they made a radical move: open-sourced their browser as Mozilla (Bazaar model). This spawned Firefox, which survived when Netscape died. Cathedral → Bazaar transition saved the artifact.
The SCO vs. Linux War: In 2003, SCO Group claimed ownership of Linux code and sued IBM. The Bazaar model was Linux's defense—every line of code had a public history showing who wrote it and when. Transparency proved innocence. A Cathedral project couldn't have defended itself this way.
Wikipedia as Bazaar: Wikipedia applies the Bazaar model to knowledge, not code. Anyone can edit, all changes are visible, and collaboration produces something no Cathedral (Encyclopedia Britannica) could match. The result: Wikipedia is more comprehensive and more resilient.
Raymond's Lessons for Builders
From the original essay, principles for creating resilient software:
- Release early, release often: Get feedback fast; iterate publicly
- Treat users as co-developers: They'll find bugs and suggest features
- Don't be precious: If someone else's solution is better, adopt it
- Recognize good ideas: The best features often come from unexpected sources
- Lose gracefully: When a project should end, open-source it so others can continue
Modern Echoes
The Cathedral/Bazaar debate continues in new forms:
- Web3 vs. Web2: Decentralized (Bazaar) vs. platform-controlled (Cathedral)
- AI Models: Open weights (Bazaar: Meta's LLaMA) vs. closed APIs (Cathedral: OpenAI's GPT)
- Data Portability: Exportable formats (Bazaar) vs. platform lock-in (Cathedral)
The fundamental question remains: Who controls the thing you built? You, the community, or a corporation?