After DeepSeek Harness, Revisiting the People Who First Defined Open Source

On August 19, OpenAI fully open-sourced Codex Harness. A week earlier, DeepSeek Harness had also raced past 100,000 GitHub Stars.

By embracing open source, they have voluntarily placed themselves inside a larger "bazaar."

Eric S. Raymond was one of the earliest evangelists of the open-source movement. In 1997, in his essay The Cathedral and the Bazaar, he proposed two models of software development: the cathedral, built by a small group working in isolation, refined repeatedly, then released to the world; and the bazaar, which allows anyone to participate, evolving through continuous release, feedback, and correction.

After Moonshot AI's K2 went open source, Silicon Valley legend Bill Gurley compared China's open-source ecosystem to a farmers market where best practices are shared.

Raymond was trying to explain why the Linux community — noisy, even chaotic as it appeared — never fell apart, but instead grew stronger, changing the world through open source. He discovered that innovation doesn't have to be designed by a fixed organization; it can also emerge from the local contributions of a vast number of participants.

Nearly three decades later, AI has expanded the bazaar's boundaries once again. In 2025, GitHub added more than 121 million repos — the highest number ever created in a single year. Of these, over 4.3 million were AI-related.

In the past, the participants in the bazaar were human. Today, more and more agents are entering it as well.

OpenAI once ran an experiment with Codex: over five months, three engineers alongside Codex completed roughly one million lines of code across 1,500 pull requests — not a single line written by hand.

This also makes many of the insights from The Cathedral and the Bazaar newly relevant. The most famous is Linus's Law: given enough eyeballs, all bugs are shallow. The more frequent the releases and testing, the more participants involved, the more easily problems are found. An open-source community can mobilize several orders of magnitude more technical manpower around a problem than the closed-source world.

We are stepping into a larger bazaar.

The Cathedral and the Bazaar

Linux was disruptive.

In 1991, who could have imagined that a world-class operating system would somehow coalesce, as if by magic, from the hobbyist hacking of thousands of developers around the globe?

They were scattered across the world, connected to one another only by a few thin threads of the internet.

At least I didn't see it coming.

What we now call the "Linux system" began as nothing more than a free kernel built by a Finnish university student, Linus Torvalds. With the growth of the internet, it evolved into an open-source community with global developer participation. Today, the videos you watch, the AI you use, the websites you visit — there's a very good chance they're all running on Linux.

By then, I had already spent ten years working on Unix. I was among the earliest GNU contributors and had developed several programs still in wide use.

I thought I knew how open-source software should be done, but Linux overturned much of what I thought I understood.

For years, I had followed the Unix creed: use tools to solve problems, ship demos quickly, let programs evolve through continuous iteration. But I also believed that once complexity crossed a certain threshold, more centralized planning became necessary.

I believed that the most important systems had to be built like cathedrals: a few saintly hermits working in isolation, polishing and refining; never releasing a new version before its time.

So this college student's approach took me by surprise.

Linux had none of the quiet, solemn cathedral engineering. It resembled instead a noisy great bazaar, crowded with people of differing goals and methods. Anyone could submit something.

And yet from this bazaar, a coherent, stable system emerged as if by a series of miracles.

As I gradually figured out how the Linux world operated, I wanted to do more than participate in individual projects — I wanted to understand something larger: why hadn't the Linux world disintegrated into chaos? Instead, it had grown stronger at a pace cathedral-builders could scarcely imagine.

By 1996, I was beginning to understand.

I had a perfect opportunity to test my theory. An open-source project landed in my lap, and I could consciously try to run it in bazaar style. I did, and the results were wildly successful.

Here is that project's story.

The Importance of Users

Having users is a very good thing.

Not merely because they prove you're meeting a need, that you've done something right. If managed well, they can also become co-developers.

The Unix tradition had an advantage, and Linux pushed this advantage to a delightful extreme: many of the users were hackers themselves.

The code was open. With a little encouragement, users would help you diagnose problems, suggest fixes, and improve the code far faster than you could working alone.

Before Linus Torvalds showed us another way, almost everyone in the open-source world had severely underestimated how much this approach could scale as the user base grew and system complexity rose.

I would even argue that Linus's smartest and most far-reaching achievement wasn't the Linux kernel itself, but the Linux development model he invented.

I once told him this to his face. He smiled and repeated something he often says: "I'm a very lazy person who likes to take credit for what other people actually do."

Lazy like a fox.

In retrospect, Linux's approach and its success can find precedents in the development of the GNU Emacs Lisp library and Lisp code archives.

In fact, before fetchmail, my own most successful experience was with Emacs VC. It was a very Linux-like email collaboration among four people, three of whom I have never met to this day.

VC was an Emacs front end for SCCS, RCS, and later CVS, providing one-click version control operations. It evolved from a very small, very crude sccs.el mode someone else had written. VC succeeded precisely because, unlike Emacs itself, Emacs Lisp code could go through round after round of release, testing, and improvement very quickly.

Our story was not unique.

Some software has adopted this same dual-layer architecture: a cathedral-mode core with a bazaar-mode toolbox. MATLAB is one example.

People who use MATLAB and similar products often discover that the real engine of momentum, enthusiasm, and innovation lies where there is a large and diverse user base that can participate and refine.

Release Early, Release Often

Release early, release often — this was a critical step in Linux's development.

In the past, most developers, myself included, felt that once a project grew even slightly complex, this approach became unreliable. Early versions usually had many problems, and users' patience was limited — you couldn't burn through it right from the start.

This view also drove the widespread adoption of cathedral-style development. If the primary goal was to minimize the defects users encountered, you should release only every six months or longer, debugging like a dog between releases. Emacs's C core was developed this way.

But a year later, as Linux drew widespread attention, a radically different paradigm was being born.

Linus's open development policy was the exact opposite of cathedral-building. Linux's internet code archive expanded rapidly, multiple distributions emerged, and all of this was driven by an unprecedented release frequency for a core system.

Linus treated users as co-developers, releasing early and often, and listening carefully to what they had to say.

This wasn't Linus's innovation — the Unix world had long had this tradition. His innovation was scaling this approach to match the size and intensity of the system he was developing.

As early as 1991, we heard of him releasing more than one new version in a single day. Because he worked harder than anyone else at cultivating co-developers, and made fuller use of the internet to facilitate collaboration.

It worked.

But why did it work? Was this something I could emulate, or could only a genius like Linus Torvalds pull it off?

Linus was certainly a hardcore hacker. How many of us could build an industrial-grade operating system kernel from scratch? But Linux didn't represent some huge conceptual breakthrough. Linus wasn't, at least not yet, a genius of design innovation in the mold of Richard Stallman or James Gosling.

To me, Linus was a genius of engineering and execution. He had a sixth sense for avoiding dead ends, and a real talent for finding the fastest path from point A to point B.

All of Linux reflects this quality.

He believed that if the pool of beta testers and co-developers was large enough, almost every problem would surface quickly, and someone would always be able to fix it with ease.

Given enough eyeballs, all bugs are shallow.

I called this "Linus's Law."

My earliest understanding was that for every problem, someone would figure it out. But Linus didn't quite agree. He said that the person who understands and fixes a problem is usually not the first to discover it — "finding the problem is the harder step."

When thousands of developers are eagerly examining each new release, everything becomes simpler.

Sociologists had discovered years earlier that the average contribution or judgment of a large number of participants often produces better results than a single individual. This is known as the Delphi effect.

What Linus demonstrated was that even at the complexity level of an operating system, the Delphi effect could help us steer.

More users means more problems found, because there are more angles of examination. When users are also developers, this effect is amplified further. This diversity helps reduce duplicated effort.

Someone's toolkit just happens to fit this problem. For that person, the problem is simple.

Linus also kept one trick in reserve. If serious defects were possible, Linux's kernel version numbering let users choose for themselves: stick with an older "stable" version, or accept the risk of defects to get the latest features in the bleeding-edge release.

Giving users choice made both versions more appealing.

Taming Complexity with Many Eyes

Overall, the bazaar accelerates debugging. But to understand why it works, we need to observe the daily collaboration between developers and testers.

Users who don't care about source code tend to report only surface symptoms. They take their runtime environment for granted, so they often miss critical background information, and rarely provide a stable set of steps to reproduce a defect.

Testers look from the outside in; developers look from the inside out. In closed development modes, both are trapped in their roles, talking past each other, easily frustrating one another.

Open source breaks this trap.

Both sides can build a shared model on top of the source code, making communication much easier.

If you can describe the error condition at the source code level — not completely, just enough — most defects can be caught. When one of your beta testers can point out: "There's a boundary issue on line nnn," or simply say: "This variable will overflow under conditions X, Y, and Z," a glance at the relevant code is enough to pinpoint the problem.

Even with many collaborators, core developers can still save enormous amounts of time.

Another time-saver in open source is communication structure. A project has a very small core; independent developers are common, typically 1-3 people; surrounding them are potentially hundreds of beta testers and contributors.

Traditional software development faces a well-known problem: "Adding manpower to a late software project makes it later." As more developers join, a project's complexity and communication costs grow quadratically, while actual completed work only increases linearly.

This assumes that the project's communication structure is a complete network, where everyone must communicate with everyone else.

But in open-source projects, developers are actually working on separate, parallel subtasks, rarely needing to communicate directly with one another. Only the small core team bears these communication costs.

Prerequisites for the Bazaar Model

What does the bazaar need to succeed?

First, you can't expect a project to start from a blank slate and rely solely on the bazaar for its birth. A community can participate in testing, debugging, and improvement, but it's hard for them to create a project from nothing on the founder's behalf.

Linus didn't do this, and neither did I. A newly formed developer community first needs something that runs, that can be tested, that's worth exploring.

To build a community, you need to present a "credible promise."

The program doesn't have to run particularly well; it can be rough. But it must hold to two bottom lines: first, it must run; second, it must convince potential contributors that if they keep investing, it will produce value in the foreseeable future.

Both Linux and fetchmail had appealing basic designs when they started. Many who have thought about the bazaar model have therefore concluded that the project leader must have strong design intuition, must be smart enough.

But Linus's design came from Unix; my initial design also came from the earlier popclient. Does a bazaar project leader need outstanding design talent, or can they succeed by leveraging others?

I don't think the ability to come up with original designs is the most critical factor. What matters is having the discernment to recognize good design ideas from others.

I may have underestimated the importance of original design in bazaar projects because I don't lack this ability myself, so I took it for granted.

But in software design, being too clever, too creative, can become a bad habit. When you should be keeping things solid and simple, you can't resist making them clever and complex.

Suppose Linus Torvalds had spent the Linux development process constantly trying to make fundamental innovations in operating system design — would it have ended up as stable as it is now?

The prestige mechanism within open-source communities also exerts subtle pressure. If you don't have real skills, don't start a project you aren't capable of seeing through.

For bazaar projects, there's another skill not usually considered a software development ability that may be more important than design: the leader must have good interpersonal skills.

This isn't hard to understand. To build a developer community, you first have to attract people, get them interested in what you're doing; at the same time, you have to make them feel that their invested time and work is worthwhile.

Technical appeal certainly helps, but technology alone is far from enough. The kind of person you are matters too.

Linus comes across as approachable, likable, someone people want to help. I'm extroverted, enjoy working with people, and have a bit of the improvisational comedian's instinct for working a room. Neither is accidental.

To make the bazaar truly run, you need the ability to make others want to come near and collaborate.

Good Open-Source Projects Require Common Will

The best programs usually start from a problem the author personally encountered in daily life. And they spread because many others face the same predicament.

But once a project already has a large and active community of users and collaborators, how does the software continue to evolve?

Programming is largely an individual activity. But outstanding software often comes from mobilizing the attention and intelligence of an entire community.

A person who relies solely on their own brainpower and develops in closed mode will eventually fall behind another who understands how to create openness.

But several factors prevented the traditional Unix world from taking this method to its extreme. One was legal restrictions from various licenses, trade secrets, and commercial interests; another was that the internet of that time wasn't good enough.

Before low-cost internet existed, there were indeed some regional technical communities, such as Bell Labs, MIT's AI and Computer Laboratory, and UC Berkeley. They later became birthplaces of many legendary innovations whose influence continues to this day.

In such environments, it was easy to attract capable collaborators.

Linux was the first project to consciously and successfully use the entire world as its talent pool. I don't think it's coincidence that Linux's gestation period happened to overlap with the rise of the internet.

Linux is like a free market.

Members each pursue their own gain, yet in their interactions form a self-correcting spontaneous order. It is more complex and more effective than any central planning.

This collaboration is not built on power relations. What it requires is the common will and effort of many people.

What creators want to maximize is not money, but something harder to quantify — personal satisfaction and prestige among fellow hackers.

As everyone knows, programmers typically hate writing documentation. So why have Linux hackers produced so much of it?

One possible answer is that the prestige Linus created motivates higher-quality, other-oriented contributions more effectively than the budget-and-management-driven production of commercial companies.

Many instinctively assume that a culture of self-driven individual heroes must necessarily fragment into factions, inefficiency, secrecy, even mutual hostility.

Yet Linux's coverage, quality, and depth are astonishing.

If a project coordinator has a communication medium at least as efficient as the internet, and knows how to lead without relying on coercion, the minds of many will almost inevitably outperform the mind of one.

An open-source community can throw several orders of magnitude more technical manpower at a problem than the closed-source world.

This doesn't mean individual talent no longer matters. On the contrary, cutting-edge exploration still begins with individual vision; but the very best people go further by building volunteer communities that amplify everyone's capabilities.

I believe the future of open source will increasingly belong to those who know how to play the "Linus game" — those willing to leave the cathedral and embrace the bazaar.

Translated by Yanyang

Edited by Cindy