I was never a developer. But I was there.

When Eric S. Raymond published The Cathedral and the Bazaar in 1997 — first as a paper presented at the Linux Kongress, later expanded into a book by O’Reilly in 1999 — I was not reading it as a programmer evaluating methodologies. I was watching an argument unfold in real time. An argument about how things should be built, who should own them, and what freedom means when applied to something as abstract as source code.

Raymond’s central thesis was deceptively simple: given enough eyeballs, all bugs are shallow. He called this Linus’s Law, after Torvalds, and used the success of Linux and his own fetchmail project to argue that open, decentralized development produces better software than closed, hierarchical models. The paper did not just describe a methodology. It gave the methodology a name, and names have power.

But to understand why Raymond was the one to name it, you have to go further back — to a file that predates the web, predates Linux, predates the personal computer itself.

The Jargon File

In 1975, Raphael Finkel at Stanford began compiling a glossary of slang used by programmers at the MIT AI Lab, the Stanford AI Lab, and the scattered communities of the ARPANET. It was called the Jargon File — a living document, passed between machines via FTP, edited by anyone who had access, owned by no one. Richard Stallman was among the early contributors, adding MIT and ITS-related coinages. The file grew by fits and starts, reflecting the culture of the people who wrote it.

The original Jargon File was, in retrospect, the first bazaar. No editor, no publisher, no formal process. Just hackers documenting their own language, in their own voice, on their own terms. It was description and influence simultaneously — as the File’s own introduction acknowledged, “the line between description and influence can become more than a little blurred.”

In 1983, Guy Steele edited the File into print as The Hacker’s Dictionary. Then the File went dormant. The MIT AI Lab culture had been hit by funding cuts, the Stanford AI Lab had effectively ceased to exist, and the old ARPANET communities were scattering into startups and commercial ventures.

In 1990, Raymond adopted the orphaned File. He updated it, expanded it, and published it through MIT Press in 1991 as The New Hacker’s Dictionary. This was not without controversy — critics accused him of shifting the File’s focus from the older PDP-10 and LISP cultures to the Unix hacker culture he inhabited. Paul Dourish, who maintains an archived original version, said Raymond’s updates “essentially destroyed what held it together.”

Raymond’s response was characteristically pragmatic: the nature of hacking had changed, and the Jargon File should report on hacker culture as it existed, not enshrine a version that no longer reflected reality.

This instinct — document the living culture, not the idealized one — is the same instinct that produced The Cathedral and the Bazaar seven years later. Raymond was not a theorist. He was an ethnographer with commit access.

The Cathedral

Raymond’s cathedral was a model of development where software is crafted by a small priesthood of architects behind closed doors. The source is revealed only at release, polished and complete, like a Gothic nave unveiled after decades of construction. The cathedral is beautiful from the outside. It is also owned by the people who built it, and you enter on their terms.

He contrasted this with the Linux kernel’s development model — a seemingly chaotic bazaar of competing agendas and approaches, held together by Torvalds’s taste and a shared network protocol. The bazaar looked like a mess. It produced an operating system that runs the modern internet.

The paper landed like a grenade. Netscape cited it as “independent validation” in the internal white paper that led to the release of the Mozilla source code in 1998. Frank Hecker and Jamie Zawinski used Raymond’s framework to argue that opening the source was not charity — it was strategy. The most consequential corporate open-source decision of the decade was justified, in part, by a paper about a mail client.

Every CMS I have ever used is a cathedral.

WordPress began as a fork of b2/cafelog in 2003 and grew into a content management system that now powers over 40% of the web. It is the most successful cathedral ever built in open source — nominally free, practically a platform, with an ecosystem of premium themes and plugins that generates billions in annual revenue. You are welcome inside. The gift shop is to your left.

Ghost launched in 2013 as the anti-WordPress — clean, focused, built for writers. A decade later it is a SaaS platform that starts at $9 per month. A tasteful cathedral, well-lit, but the door still has a card reader.

Substack arrived in 2017 promising to liberate writers from advertising. It succeeded — by replacing advertising with a revenue share model where the platform keeps 10% and, more importantly, owns the relationship with your audience. The cathedral pays you to preach, then keeps the congregation’s contact information.

They are all beautiful from the outside. They are all controlled from the inside.

The Bazaar

Raymond identified nineteen lessons from the bazaar model. The ones that matter most, nearly three decades later:

  1. Every good work of software starts by scratching a developer’s personal itch.
  2. Treating your users as co-developers is your least-hassle route to rapid code improvement.
  3. Release early. Release often. And listen to your customers.
  4. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
  5. If you treat your beta-testers as if they’re your most valuable resource, they’ll respond by becoming your most valuable resource.

But Raymond also noted a prerequisite that is often overlooked: the bazaar model depends on the existence of a plausible promise — a running, testable system that potential contributors can evaluate and extend. “You cannot crowdsource an architecture,” he wrote. “You can only crowdsource the refinement of an architecture that already works.”

The Jargon File was a plausible promise — a document that existed, was useful, and was open to contribution. Linux was a plausible promise — a kernel that booted, ran programs, and accepted patches. Fetchmail was a plausible promise — a mail client that fetched mail.

I built note2cms as a plausible promise. Four API endpoints that accept Markdown and produce static HTML. The architecture is so minimal that the entire API contract fits in four lines of a table.

The Licensing Wars, Revisited

The most consequential argument in the history of open source was not about code. It was about a single clause.

Stallman’s GNU General Public License, first published in 1989 and revised significantly in 1991 (GPLv2) and 2007 (GPLv3), contains what is known as the copyleft provision: any derivative work must be distributed under the same license. You can use GPL code, modify it, sell it — but you cannot make it proprietary. Your freedom cannot be used to remove someone else’s freedom.

The MIT License, by contrast, fits on a single page. It says, in essence: do whatever you want with this code, just keep the copyright notice. There is no copyleft. No obligation to share modifications. A company can take MIT-licensed code, fold it into a closed-source product, and sell it without releasing a line of source.

These are not two versions of the same idea. They are two fundamentally different philosophies of freedom.

Stallman’s freedom is positive liberty — freedom to access, modify, and share, guaranteed in perpetuity by legal mechanism. The GPL is a hack on copyright law: it uses the legal infrastructure of restriction to enforce the opposite of restriction. It is, as Stallman has said, “copyleft — all rights reversed.”

The MIT model is negative liberty — freedom from interference. The licensor places no obligations on the licensee. What happens next is not the licensor’s concern.

The tragedy of modern open source is that this distinction has collapsed. Developers choose MIT because it is the default on GitHub’s license picker. They choose it the way they choose a JavaScript framework — by vibes, not by conviction. And then someone forks their project without attribution, and they are furious. They chose the license that explicitly permits this. They just never expected anyone to take them at their word.

What Happened Overnight

I published note2cms under the MIT License on a Sunday morning. Four API endpoints, two build pipelines, a manifesto. The entire system deployed for free on Leapcell and GitHub Pages.

By the time I woke up on Monday, a developer I had never met — @garrul4ik on GitHub — had forked the project, built a full-featured Obsidian plugin called note2cms Publisher, tested it on four operating systems, and submitted it to the official Obsidian community plugin registry.

His plugin has features I never imagined: offline queuing, WiFi-only mode, bulk publishing by folder or tag, preview before publish, a permalink modal with copy-to-clipboard. He solved problems for his community that I did not know existed.

He did not ask my permission. He did not need it. He credited the project in his plugin settings, but not prominently in his README. A modern developer might take offense at this. I did not. I felt pride — not in his work, which is his own, but in mine, which was clear enough and sound enough that a stranger could build on it overnight without reading my source code.

Raymond’s lessons, playing out in real time, in a project younger than most pull request review cycles. The developer scratched his own itch (Lesson 1). He characterized a problem — Obsidian integration — that I had not considered, and the fix was obvious to him because he was an Obsidian user (Lesson 4). He became the most valuable kind of co-developer: the kind who builds what you did not know was needed (Lesson 5).

The Real Credit

The open source community has developed an unhealthy relationship with attribution. Developers publish under permissive licenses and then expect the social norms of academic citation. They want MIT’s freedom with GPL’s moral obligation. They want the bazaar’s energy with the cathedral’s name on the cornerstone.

This is incoherent.

If you publish under MIT, you are saying: this is a gift. Take it. Build on it. Make it yours. If you cannot accept that someone will do exactly this — without prominently displaying your name — then you do not believe in what MIT means. You chose a license from a dropdown menu, not from conviction.

Stallman, for all his eccentricities, never had this problem. The GPL is explicit: you can use this, but you must share alike. The obligation is in the license. There is no gap between the legal text and the social expectation. If you want your name on every derivative work, the GPL family provides mechanisms for that. Use them.

Or do what I did: publish under MIT and mean it. Let go. Watch what happens. The existence of a derivative work is the highest form of validation a piece of software can receive. Not a star on GitHub. Not a mention in a README. A stranger building something real on your foundation, because the foundation was worth building on.

The Lesson

The cathedral-and-bazaar debate was never resolved. It just went quiet. The cathedrals got better at marketing — they started calling themselves “platforms” and “ecosystems.” The bazaars got absorbed into centralized forges — first SourceForge, then GitHub, now a platform owned by Microsoft that can change its terms of service at any time.

The Jargon File, that first bazaar, has been effectively frozen since Raymond’s last update. The hacker culture it documented has fragmented into a thousand subcultures, each with its own jargon, its own heroes, its own arguments about licensing and attribution and credit. The File no longer describes a unified culture because the culture is no longer unified.

But the bazaar pattern persists. Not in GitHub’s social features or npm’s download counts or the rituals of corporate open source. It persists in the moments when someone publishes something honest — something small enough to understand, clear enough to extend, and free enough to take — and a stranger shows up overnight with a contribution that the original author could not have imagined.

You cannot design a bazaar. You cannot manage it into existence. You cannot create a community by building community infrastructure. You can only publish a plausible promise — a running system, a clear interface, and a license that means what it says — and wait.

The bazaar either shows up or it does not. You have no control over this. You only control whether you deserved it.

References

Finkel, R. (1975). The Jargon File, version 1. Stanford AI Lab.

Steele, G. L., ed. (1983). The Hacker’s Dictionary. Harper & Row.

Stallman, R. M. (1985). “The GNU Manifesto.” Dr. Dobb’s Journal, March 1985.

Raymond, E. S., ed. (1991). The New Hacker’s Dictionary. MIT Press. (Third edition, 1996.)

Raymond, E. S. (1997). “The Cathedral and the Bazaar.” First presented at the Linux Kongress, May 27, 1997. Revised and expanded, O’Reilly Media, 1999.

Perens, B. (1999). “The Open Source Definition.” Open Source Initiative.

Weber, S. (2004). The Success of Open Source. Harvard University Press.

Fogel, K. (2005). Producing Open Source Software: How to Run a Successful Free Software Project. O’Reilly Media.

You cannot design a bazaar. You can only deserve it.