The Reading List That Made Me: The Cathedral and the Bazaar

The Reading List That Made Me: The Cathedral and the Bazaar

Part 4 of 4 in a series on the books that shaped “Well… How Did We Get Here?”

It is February 1998. Netscape — at the time one of the most valuable technology companies in the world, the company whose browser had effectively made the World Wide Web accessible to ordinary people — announces that it is releasing the source code for its flagship product and making it free. Not free to use. Free to inspect, to modify, to improve, to redistribute. Free in the way that a recipe is free when you share it with a neighbour: anyone who wants to cook from it can.

The reason Netscape gave for this decision, in their public announcement, was a single essay. An essay that had been circulating online for less than a year, written by a programmer almost nobody outside the Linux community had heard of, about an email utility called fetchmail and what building it had taught him about how software should be made.

The essay was The Cathedral and the Bazaar. The programmer was Eric S. Raymond. And the essay — later expanded into the book of the same name, published in 1999 — changed the software industry more directly and more measurably than almost any other piece of writing in the history of computing.

The Two Models

Raymond’s central argument is built around a metaphor so clean it became immediately canonical. There are, he argues, two ways to build software.

The first is the cathedral model. A small team of expert architects, working in relative secrecy, producing a finished artefact that is released to the public fully formed and carefully controlled. Microsoft Windows. Apple’s operating system. The enterprise software of the 1980s and 1990s. Cathedrals took decades to build, required centralised authority and coordinated expertise, and were not open to improvisation by passing strangers. The finished product was impressive, and deliberately so.

The second is the bazaar model. A large, distributed community of developers, working in public, releasing early and often, treating every user as a potential contributor, welcoming patches and fixes from anyone who wanted to send them. Linux, developed by Linus Torvalds from a hobby project into the operating system that now runs most of the world’s servers, smartphones, and supercomputers. A bazaar has no single architect. It has a thousand simultaneous contributors, each improving a small piece, the whole emerging from the aggregate of their contributions rather than from any central plan.

Raymond’s claim — and this was the genuinely radical part in 1997 — was that the bazaar model produced better software. Not just more collaborative software. Better software. More reliable, more secure, faster to fix bugs, more responsive to the needs of actual users. The cathedral was not just more expensive. It was inferior.

Linus’s Law

The evidence Raymond marshalled for this claim centred on a principle he named Linus’s Law, after Torvalds: “Given enough eyeballs, all bugs are shallow.”

The logic is elegant. In closed-source, cathedral development, bugs are found by the small team of developers who wrote the code. In open-source, bazaar development, bugs are potentially findable by every person who uses the software and can read the code — which in the case of Linux was tens of thousands of people. The more people looking at a piece of code, the more likely it is that someone will spot an error, and the more likely it is that someone who spots it will know how to fix it.

This is not merely a theoretical argument. Raymond demonstrated it empirically through the history of his own fetchmail project, tracing how the software improved with each wave of contributors, how bugs he had stared at for weeks were spotted and fixed by fresh eyes within hours of a new release, how the collective intelligence of a distributed community consistently outperformed the concentrated intelligence of a single expert.

The implication was significant. The cathedral model rested on an assumption: that complexity required centralised control, that only a small team of coordinated experts could produce something of quality. Raymond’s argument — backed by the extraordinary evidence of Linux — was that this assumption was wrong. Under the right conditions, distributed peer production could outperform centralised expert production, and the right conditions were surprisingly easy to achieve: a project people cared about, code that was genuinely open, and a maintainer willing to release early and often rather than hoarding improvements until they were perfect.

The Gift Economy of Hackers

One of the less-discussed but more interesting sections of The Cathedral and the Bazaar concerns the economic incentives that lead skilled programmers to contribute code without payment. This is not an obvious thing. Writing good software is skilled, time-consuming work. Why would anyone do it for free, for a project they don’t own, for users they will never meet?

Raymond’s answer draws on anthropology — specifically on the concept of a gift economy, in which status is conferred not by what you accumulate but by what you give away. In hacker culture, the programmer who contributes the most useful code, who fixes the most important bugs, who improves the tools everyone else depends on, earns reputation precisely through that contribution. The gift is the currency. Sharing the code is not altruism, exactly. It is a rational strategy in a community where reputation is the thing that matters, and reputation is built by giving rather than keeping.

This is a genuinely important insight, and one that has aged better than almost anything else in the book. It is, in essence, the model on which GitHub, Stack Overflow, Wikipedia, and much of the collaborative infrastructure of the modern internet are built. The gift economy Raymond described in 1997 turned out to be not just a curiosity of hacker culture but a generalisable model for distributed knowledge production — one that, in various forms, now underpins how humanity collectively manages an enormous amount of its shared knowledge.

Why I Read It — and Why It Sits Next to Rebel Code

I came to The Cathedral and the Bazaar through Rebel Code — Glyn Moody’s history of the Linux movement which is the first book in this reading list series. Moody gave me the history. Raymond gave me the theory. Where Moody traced who built the open source movement and what their choices meant, Raymond explained why the movement worked — what structural conditions made the bazaar model not just ideologically appealing but empirically superior.

Reading them together, in the mid-2000s, what struck me most was the gap between the argument Raymond was making and the trajectory the industry was actually taking. By the time I read the book, the bazaar model had already conquered the infrastructure layer of the internet. Linux ran the servers. Apache ran the web. The open source movement had won, in the narrow technical sense that its software had become indispensable.

But the application layer — the part of the internet ordinary users actually experienced — was going in a completely different direction. The companies building the services that ran on top of the open source infrastructure were building cathedrals: closed, proprietary, controlled. Google’s search algorithm. Facebook’s social graph. Apple’s App Store. These were not bazaars. They were the most elaborately designed cathedrals in human history, running on open source foundations, producing closed source products, and accumulating power at a speed that made Microsoft’s cathedral-era dominance look modest by comparison.

This tension — between the open foundations and the closed superstructure built on top of them — is one of the central puzzles that Well… How Did We Get Here? tries to examine. Raymond’s book is where I first felt the puzzle sharply.

Raymond and What the Industry Did With It

Raymond was right about the bazaar model’s technical superiority. He was right about the gift economy’s sustainability. He was right that distributed peer production could outperform centralised expert production under the right conditions, and he was right that those conditions were more widely applicable than most people imagined. GitHub’s billion-plus repositories are the empirical proof.

What even Raymond perhaps didn’t fully anticipate was how efficiently the cathedral would learn to build on top of the bazaar. The corporate capture of open source that began in the late 1990s — with IBM, Intel, Oracle, and others embracing Linux not out of ideological conversion but commercial calculation — turned out to be a more subtle form of enclosure than anyone expected. The code remained open. The infrastructure remained freely available. But the value generated by the code increasingly accumulated in closed proprietary layers built on top of it.

Amazon Web Services runs on Linux. Google runs on Linux. Android is built on Linux. Every major cloud computing platform is built on open source foundations. But the services those platforms provide — and the data they collect, and the market power they exercise — are as cathedral as anything Microsoft ever built. The bazaar won at the infrastructure layer and lost at the application layer, and the loss at the application layer is where most ordinary users actually live.

Lawrence Lessig, whose The Future of Ideas is the third book in this series, saw this coming in 2001. He described it as the enclosure of the commons. Raymond, writing four years earlier, was still in the moment of genuine optimism — describing a model that worked, celebrating a community that had built something remarkable, arguing for its extension. He was not wrong. He was simply earlier than the closing.

The Accidental Revolutionary

Raymond subtitled his book Musings on Linux and Open Source by an Accidental Revolutionary, and the subtitle is honest. He did not set out to change the software industry. He set out to understand why his fetchmail project worked the way it did, and the understanding turned out to be more consequential than he expected.

This is, in miniature, the pattern Well… How Did We Get Here? traces across the larger history of the internet: people making specific choices for specific reasons, understanding arriving later than the choice, consequences accumulating beyond anyone’s plan or prediction. Raymond’s essay became the manifesto of a movement he was documenting rather than leading. Linux became the infrastructure of a digital world its creator never imagined. The internet became the attention economy that none of its architects intended or would have chosen.

The accidental revolutionary is perhaps the most characteristic figure of the digital age. The bazaar, it turned out, was full of them.