In 1997 Eric S. Raymond presented an essay called "The Cathedral and the Bazaar" at a Linux conference in Germany. It compared two ways of building software.
- The cathedral: a small group of experts builds the thing carefully, behind closed doors, and releases it when it's finished. Raymond put most commercial software here, and also GNU's own development style at the time.
- The bazaar: release early, release often, let anyone look at the code and contribute, and treat your users as co-developers. Linux was his example, along with his own project, fetchmail.
His argument was that the bazaar, which looks like chaos, produces better software faster. He summed up its secret in a line he named after Linus Torvalds: "Given enough eyeballs, all bugs are shallow."
It's hard to overstate the essay's influence. Netscape's leaders cited it when they decided to release their browser's source code in early 1998, the event that led to the term "open source" a few weeks later. Twenty-seven years on, it's worth asking how well it holds up. This year has given us an unusually clear test.
What it got right
- Release early, release often. Continuous integration, frequent releases and public development are now how almost all software is built, open or closed. That was a radical idea in 1997.
- Users as co-developers. Bug reports with stack traces, pull requests from strangers, users fixing the docs: the feedback loop Raymond described now runs through GitHub at a scale he couldn't have imagined.
- The bazaar won. Linux, Kubernetes, PostgreSQL, Python and the web stack are all built in the open. Even Microsoft, which once called Linux a cancer, develops much of its software on GitHub. As a prediction about which model would dominate infrastructure, the essay was right.
The xz test
Here's the problem. On March 29 this year, Andres Freund, a Microsoft engineer who works on PostgreSQL, noticed that SSH logins on his test machine were using a bit more CPU than they should, about half a second slower. He followed the thread and found a backdoor in xz, a compression library present on almost every Linux system. It was built to let an attacker with the right key run code on any affected server through OpenSSH.
The story behind it is the important part. xz had been maintained for years by one volunteer, Lasse Collin, who had been open about his limited time and his mental health. Starting in 2021, someone using the name "Jia Tan" became a helpful contributor. Around the same time, other accounts showed up on the mailing list complaining that the project was too slow and pressing for a new maintainer. Over two years, Jia Tan earned trust, became a co-maintainer, and eventually slipped the backdoor in through test files and the release tarballs, not the visible source code.
It reached the development branches of Debian and Fedora before Freund caught it, more or less by accident, and before it shipped in a stable release.
So were the bugs shallow? The backdoor was public, in a public repository, for weeks, and almost nobody looked. That isn't really a refutation of Linus's Law. Plenty of eyeballs existed in theory. The trouble is that eyeballs aren't evenly distributed. Popular, interesting code gets reviewed. Boring, critical infrastructure maintained by one tired person does not.
Who really runs the bazaar
That's the bigger lesson of the past decade, and it's the part the essay missed. The romantic picture is a crowd of contributors. The reality, documented by Nadia Eghbal and others, is that most open source projects are maintained by one or two people, with a large audience and very few contributors. More of a stage than a bazaar.
We've seen what happens when those people are overloaded:
- Heartbleed, 2014. OpenSSL, which secured a large share of the web, was maintained by a handful of people on a tiny budget.
- Log4Shell, 2021. A critical flaw in Log4j, maintained by volunteers in their spare time, sent every company on earth scrambling.
- xz, 2024. A lone maintainer, socially engineered over years.
The bazaar runs on a small number of unpaid people holding up a very large amount of commercial value. That isn't a stable arrangement.
And the cathedral moved in
The other development Raymond didn't anticipate is that the cathedrals learned to look like bazaars. A lot of important "open source" software is now built by one company, which owns all the copyright, runs the roadmap and accepts outside contributions only on its terms. It works fine until the company changes the license, as HashiCorp did with Terraform last year and Redis did this March. The bazaar's openness turns out to depend on who holds the keys.
What I take from it
The essay was right about method. Open development, frequent releases and treating users as partners produce better software, and almost everyone works that way now. Where it was too optimistic is in assuming the crowd would show up on its own. It doesn't, not for the dull, essential parts.
If your business runs on open source, and it does, the practical conclusion is simple. Find the small projects your systems depend on, and pay for them, with money or with engineering time. The eyeballs that make bugs shallow belong to people, and people need to eat.
Since then
Added October 2026. I came back to this with a much darker view a year later in When the Cathedral Ate the Bazaar, about how corporate consolidation turned much of open source into a cathedral after all, and again in a lighter mood in Iron Maiden: Cathedral, Bazaar, and the Unintentional University of Metal.