What open source learned from the bazaar

Eric S. Raymond gave “The Cathedral and the Bazaar” as a talk in 1997 and published it as an essay soon after. Its central contrast was memorable: the cathedral was software built by a small closed group, while the bazaar was software developed in public by many contributors. Raymond was not describing all programming for all time. He was trying to explain why Linux, begun by Linus Torvalds in 1991, had become a working operating-system kernel through open, rapid collaboration.

The practical case in the essay was fetchmail, Raymond’s own mail-retrieval program. He released early versions, listened to users, accepted patches and treated bug reports as part of development rather than as embarrassment. The famous line, “given enough eyeballs, all bugs are shallow,” later called Linus’s Law, captured the mechanism: many independent testers see different machines, habits and failures, so defects surface faster than one team could reproduce them.

 *The Cathedral and the Bazaar gives the article a concrete visual reference. Credit: Wikimedia Commons.*

That mechanism depends on more than generosity. Open projects need readable code, public repositories, maintainers who can reject bad patches, norms for reporting security flaws and a licence that lets people use and modify the work. The bazaar is not an absence of structure; it is a different structure, where review, reputation and shared tools replace some of the control of a closed vendor. Git, GitHub and continuous-integration systems later made that pattern easier to see, but the social problem remained human.

The essay mattered outside programming because Netscape cited it when it announced in 1998 that it would release browser code, a step that led toward Mozilla. It also gave managers a language for something programmers already knew: users can be co-discoverers of problems, not merely customers waiting for a finished cathedral. Today Linux runs phones, servers, cloud systems and embedded devices, while open libraries support much of the web.

 *Open-source software shows the wider setting behind the story. Credit: Wikimedia Commons.*

The limits are clearer now. open collaboration can suffer from underfunded maintainers, abandoned packages, licence confusion and security attacks, as the 2024 xz Utils backdoor attempt reminded the industry. Visibility does not automatically mean safety, and volunteers are not infinite infrastructure. The durable lesson is therefore not that the bazaar always wins. It is that shared inspection, fast feedback and responsible maintainership can make software stronger than secrecy alone.

The limits became clearer as open collaboration grew. A public repository does not automatically produce secure or humane software. The Heartbleed bug in OpenSSL, disclosed in 2014, showed that widely used infrastructure can be maintained by very small teams. The Log4Shell vulnerability in 2021 showed how one Java logging library could affect companies and governments around the world. The bazaar works best when review, funding, documentation and governance keep pace with adoption.

That is why institutions now matter alongside volunteers. The Linux Foundation, Apache Software Foundation, Python Software Foundation, GitHub Security Lab and OpenSSF all represent attempts to give shared code maintenance, audits and money. The mechanism is still distributed contribution, but the constraint is stewardship: someone has to triage issues, sign releases, rotate keys, review dependencies and decide what happens when a maintainer burns out.