The Cathedral and the Bazaar, 25 Years Later

How ESR's famous essay predicted — and missed — the future of open source

An Essay That Moved Markets

In 1997, Eric S. Raymond presented a paper at the Linux Kongress in Würzburg, Germany. Titled The Cathedral and the Bazaar, it compared two models of software development: the cathedral model, where code is crafted by a small group of experts behind closed doors, and the bazaar model, where code is developed in the open, with a large and shifting community of contributors.

The essay was not purely theoretical. Raymond used his experience managing fetchmail, an open-source email utility, to argue that the bazaar model — epitomized by Linux — was not just viable but superior. The essay's influence was immediate and enormous. It directly inspired Netscape to release the source code for its browser in January 1998, an event that led to the creation of Mozilla and, eventually, Firefox.

The Core Arguments

Raymond's essay contained several memorable claims, formulated as "lessons." The most famous:

"Given enough eyeballs, all bugs are shallow." — Linus's Law (as named by Raymond)

The idea was that open-source development, by exposing code to thousands of developers, dramatically increased the probability that bugs would be found and fixed quickly. In the cathedral model, only a few people review the code. In the bazaar, everyone can.

Other key lessons included:

These ideas seem obvious now. In 1997, they were radical. Most commercial software was developed in secret, tested internally, and released on the company's schedule. The idea that a loose community of volunteers could produce better software than a well-funded corporation was, to many executives, absurd.

What Raymond Got Right

Raymond's central prediction — that open source would come to dominate software — has been spectacularly confirmed. As of the mid-2020s:

The bazaar model won so completely that it's hard to remember how controversial it once was.

Raymond was also right about release cadence. "Release early, release often" became the foundation of agile development, continuous integration, and continuous deployment. Companies like Facebook and Google deploy code hundreds or thousands of times per day. This is the bazaar philosophy taken to its logical extreme.

What Raymond Got Wrong

But the essay's predictions were not uniformly accurate, and some of its assumptions look naive in hindsight.

Linus's Law has limits. The Heartbleed vulnerability in OpenSSL (disclosed in 2014) sat in widely-used, open-source code for two years before being discovered. The "many eyeballs" were not looking. OpenSSL was maintained by a tiny, underfunded team, and despite its critical importance to internet security, almost nobody was auditing the code. The lesson: open source is a necessary but not sufficient condition for security. Eyeballs only help if they're actually looking, and if the people looking have the expertise to spot subtle bugs.

The bazaar model has scaling problems. Raymond's essay focused on relatively small projects. Modern open-source projects like Linux, Kubernetes, and Chromium are so large and complex that they function more like cathedrals than bazaars — with core maintainer teams, formal review processes, and governance structures. The pure bazaar, where anyone can contribute anything, doesn't work at scale.

Maintainer burnout is real and severe. Raymond didn't anticipate the human cost of the bazaar model. Open-source maintainers are often unpaid volunteers who face an endless stream of issues, pull requests, and demands from corporate users who contribute nothing back. The core-js maintainer pleading for financial support while millions of projects depended on his work became a symbol of this problem. The bazaar produces free software, but someone pays — usually with their time and mental health.

The Business Model Question

The essay's biggest blind spot was economics. Raymond argued that open source was a better development model. He spent much less time on how open-source developers would get paid.

The answer that emerged was complex and imperfect. Several models arose:

The cloud hosting model created significant tension. When AWS launched managed Elasticsearch without contributing to the project, Elastic changed its license to prevent this. MongoDB and Redis made similar moves. The bazaar had produced the code, but a different cathedral was capturing the value.

The Culture Wars

Raymond himself became a controversial figure in the years after the essay. His political views, his stewardship of the Jargon File, and various public statements alienated many in the open-source community. The Open Source Initiative, which he co-founded, distanced itself from him. This is a reminder that movements often outgrow their founders.

The broader open-source community also grappled with questions Raymond hadn't considered: diversity and inclusion, codes of conduct, and the relationship between technical merit and social dynamics. The bazaar turned out to have gatekeepers, hierarchies, and cultural norms that could be just as exclusionary as any cathedral.

What Raymond Got Right

Raymond's core insight, that peer review at scale produces better software than closed development, has been vindicated by decades of experience. The Linux kernel, Apache, Firefox, Python, and thousands of other projects demonstrate that distributed development works. The "many eyes" principle, while not a silver bullet, has been supported by research showing that open source projects often fix security vulnerabilities faster than their proprietary counterparts.

The essay also correctly predicted the rise of open source as a business strategy. Raymond argued that companies should open-source code that was not their core competitive advantage. This prediction came true in spectacular fashion. Google, Facebook, Microsoft, Amazon, and virtually every major technology company now maintain large open source portfolios. The "cathedral" companies of the 1990s have become "bazaar" participants, not because they converted to Raymond's philosophy, but because the economics favor it.

The gift economy model that Raymond described, where hackers contribute code in exchange for reputation and the satisfaction of solving problems, accurately describes the motivation of many open source contributors. Studies of open source participation consistently find that intrinsic motivation (learning, enjoyment, solving problems) ranks higher than extrinsic motivation (money, career advancement) for the majority of contributors, though the two are not mutually exclusive.

What Raymond Got Wrong

The essay's weaknesses have become clearer with time. The "many eyes" principle has significant limitations. The Heartbleed vulnerability in OpenSSL, one of the most critical open source libraries in existence, went undetected for two years despite the code being publicly available. The problem was not that the code was hidden but that nobody was looking. Open source code is theoretically visible to everyone but practically reviewed by far fewer people than the "many eyeballs" metaphor suggests.

Raymond's comparison to academic peer review was also flawed. Academic peer review is structured: papers are assigned to qualified reviewers who have agreed to evaluate them. Open source review is unstructured: code is available for review, but there is no mechanism to ensure that qualified people actually review it. The most critical code (cryptographic libraries, kernel security modules, protocol implementations) often receives less review than flashy user-facing features because it is harder to understand and less rewarding to examine.

The essay also underestimated the sustainability challenges of the bazaar model. Open source projects require ongoing maintenance, security patches, compatibility updates, and documentation. The bazaar's volunteers are motivated by interesting problems, and maintenance is rarely interesting. Many important open source projects are maintained by one or two burned-out individuals, not by a thriving bazaar of enthusiastic contributors.

The Cathedral's Revenge

Interestingly, some of the most successful open source projects have adopted hybrid models that incorporate cathedral elements. The Linux kernel has a hierarchical maintainer structure with Torvalds at the top, resembling a cathedral more than a bazaar. Python has a Steering Council (previously Guido van Rossum as BDFL). Rust has formal governance teams. These projects accept contributions from the community (bazaar-style) but review and integrate them through a structured process (cathedral-style).

The purely bazaar model, where contributions flow freely without structured review, produces projects like early Wikipedia: impressive in scope but variable in quality. The most successful projects combine the bazaar's ability to attract contributions with the cathedral's quality control mechanisms. The binary framing of Raymond's essay, while rhetorically effective, obscured this middle ground.

The Essay in Context

"The Cathedral and the Bazaar" must be understood as a product of its time. Written in 1997, at the height of Microsoft's dominance and the beginning of the open source movement's bid for legitimacy, it was as much a political document as a technical analysis. Raymond was making a case that open source development could compete with commercial software at a time when this was not obvious. The essay succeeded brilliantly in this goal: it directly influenced Netscape's decision to release its browser source code (which became Mozilla/Firefox), and it shaped the rhetorical framework that the open source movement used for the next two decades.

The essay's enduring influence lies not in its specific claims (some of which have been refuted by experience) but in its framing. By comparing two models of development using vivid metaphors, Raymond gave people a vocabulary for discussing software development processes. The cathedral/bazaar dichotomy, even when oversimplified, provides a useful framework for thinking about the trade-offs between structured and organic development approaches.

Key Takeaways

Modern Relevance

Twenty-five years after publication, the cathedral/bazaar framework remains useful but needs updating. The modern open source landscape includes patterns that Raymond did not anticipate:

Corporate open source: Companies like Google, Facebook, and Microsoft now open-source projects not to build communities but to establish standards and ecosystems. These projects are developed internally (cathedral-style), open-sourced, and then accept external contributions (bazaar-style) while retaining tight control over the roadmap. This "open core" model is neither cathedral nor bazaar but something new.

Platform-mediated contribution: GitHub, GitLab, and similar platforms have lowered the barrier to contribution dramatically. Pull requests, issues, and CI/CD pipelines create a structured contribution process that is more organized than Raymond's bazaar but more open than his cathedral. The platform itself provides the quality control infrastructure that Raymond assumed would emerge organically from the community.

AI-assisted development: Code generation tools like GitHub Copilot raise new questions about the bazaar model. If AI generates code, who reviews it? If AI fixes bugs, does that count as "many eyes"? The assumption that human reviewers provide quality control may need updating as AI becomes a significant contributor to codebases.

The sustainability question: Raymond assumed that the bazaar would attract enough volunteers to maintain projects indefinitely. This assumption has proven wrong for many important projects. The "tragedy of the commons" in open source, where everyone benefits but few contribute, was not anticipated by the essay's optimistic framing.

Revisiting Linus's Law

"Given enough eyeballs, all bugs are shallow." This claim, which Raymond named Linus's Law, is perhaps the essay's most quoted and most contested assertion. Research has produced mixed results. A 2014 study by Coverity found that open source code quality was comparable to proprietary code, with neither showing a clear advantage. A 2017 analysis of vulnerability disclosure timelines found that open source projects patched known vulnerabilities faster on average, supporting the "many eyes" thesis. But the Log4Shell vulnerability (2021), which existed in widely-used open source code for years without detection, demonstrated that availability for review does not guarantee review actually occurs.

The modern interpretation of Linus's Law is more nuanced: many eyes help, but only if those eyes are skilled, motivated, and actually looking at the relevant code. Security-critical code in obscure corners of important libraries often receives less review than feature code in popular frameworks. The "many eyes" effect is strongest for code that developers actively use and read, and weakest for code that works silently in the background. The lesson is not that open source review is unreliable, but that it must be supplemented with deliberate security audits, automated analysis tools, and structured review processes.

The Economics of Open Source Development

Raymond's essay focused on the development model but largely ignored the economics. Who pays for the bazaar? In 1997, the answer was enthusiastic volunteers. In 2025, the answer is mostly corporations. The economics have shifted fundamentally: open source development is now a strategic corporate investment, not a volunteer hobby.

Companies contribute to open source projects for several reasons. Contributing upstream is cheaper than maintaining private forks. Open source projects become industry standards, and companies that shape those standards gain competitive advantages. Open source contributions attract talented developers who want to work on high-profile projects. And open source reduces the cost of non-differentiating technology: why build your own web framework when you can use one that thousands of developers are improving for free?

The economic shift has consequences for the bazaar model. Corporate contributors are paid to work on specific features that serve their employer's interests, not to wander the bazaar looking for interesting problems. The volunteer ethos that Raymond celebrated still exists but is increasingly supplemented by professional open source development. This is neither good nor bad, but it is different from what the essay described.

The Essay's Legacy

Despite its limitations, The Cathedral and the Bazaar remains one of the most important texts in software history. It gave the open-source movement its intellectual framework. It provided the arguments that convinced corporations to take open source seriously. It articulated principles — release early, treat users as co-developers, embrace transparency — that are now so deeply embedded in software culture that we forget they were once controversial.

The cathedral and the bazaar are not really opposites. The best modern software projects combine elements of both: open contribution with strong governance, transparency with quality control, community with leadership. The essay's greatest contribution was not to declare the bazaar the winner but to make the case that openness was a legitimate engineering strategy, not a naive idealism.

Twenty-five years later, that case is closed.