After DeepSeek Harness, we revisit the group of people who first defined open source.

On August 19, OpenAI fully open-sourced Codex Harness. A week earlier, DeepSeek Harness had also quickly exceeded 100,000 GitHub Stars at an astonishing pace.

By moving to open source, they have voluntarily placed themselves in a larger "bazaar".

Eric S. Raymond is one of the earliest evangelists of the open source movement. In 1997, he proposed two modes of software development in his article The Cathedral and the Bazaar: the cathedral is built behind closed doors by a small number of people, polished repeatedly, and then released to the public; the bazaar allows everyone to participate, and evolves collectively through continuous release, feedback and revision.

After Kimi K2 was open-sourced, legendary Silicon Valley investor Bill Gurley also compared China's open source ecosystem to a farmers' market where best practices are shared.

Raymond tried to use this to explain why the seemingly noisy and even chaotic Linux community did not fall apart, but instead grew stronger and changed the world through open source? He found that innovation does not necessarily have to be designed by a fixed organization, but can emerge from the local contributions of a large number of participants.

Nearly 30 years later, AI has expanded the boundary of the bazaar again. In 2025, GitHub added more than 121 million new Repos, making it the year with the highest number of creations in history. Among them, more than 4.3 million Repos are AI-related.

In the past, the participants in the bazaar were human beings. Today, more and more Agents are also beginning to enter it.

OpenAI once conducted an experiment with Codex: in five months, three engineers worked with Codex to complete about 1 million lines of code and 1500 PRs, with no line of code written manually by humans.

This also makes many insights in The Cathedral and the Bazaar regain their importance. The most famous one is Linus's Law: as long as there are enough eyes, all bugs are obvious. The more frequent releases and tests are, and the more people participate, the easier it is to find problems. The open source community can mobilize technical manpower that is several orders of magnitude larger than that in the closed source world around a single problem.

We are stepping into a larger bazaar.

01

The Cathedral and the Bazaar

Linux is subversive.

In 1991, who could have imagined that a world-class operating system would emerge like magic from the amateur hacking of thousands of developers around the world?

They are scattered all over the world, connected only by the few thin threads of the Internet.

At least I didn't expect that.

The "Linux system" we usually talk about was originally just a free kernel made by Linus Torvalds, a Finnish college student. With the development of the Internet, it has grown into an open source community with the participation of developers all over the world. The videos you watch, the AI you use, and the websites you visit today are most likely running on Linux in the background.

Before that, I had been involved in Unix development for ten years. I was one of the earliest GNU contributors, and I developed some programs that are still widely used today.

I thought I knew how to make open source software, but Linux subverted many things I thought I understood.

For many years, I have adhered to the Unix creed: solve problems with tools, launch demos quickly, and let programs evolve through continuous iteration. But I also believe that once complexity exceeds a certain critical point, more centralized planning must be adopted.

I believe that the most important systems must be completed like building a cathedral: A few independent, brilliant masters polish behind closed doors and refine repeatedly; new versions will never be released before the time is right.

So the development method of this college student surprised me a lot.

Linux does not have a quiet, solemn cathedral project. Instead, it is more like a noisy big market, crowded with people with different goals and different methods. Anyone can submit something.

It is from such a bazaar that a coherent, stable system emerged like a series of miracles.

As I gradually figured out how the Linux world works, what I wanted to do was not just to participate in individual projects, but to understand a bigger question: Why didn't the Linux world fall apart in chaos, but instead became stronger and stronger at a speed that cathedral builders could hardly imagine?

By 1996, I began to understand.

I got a perfect opportunity to test the theory. An open source project was sent to me, and I could consciously try to run it in the bazaar style. I did that, and the result was very successful.

The following is the story of this project.

02

The Importance of Users

Having users is a great thing.

This is not just because they prove that you are meeting a demand and that you have done something right. If managed properly, they can also become co-developers.

The Unix tradition has an advantage, and Linux has pushed this advantage to a delightful extreme: many users are hackers themselves.

The code is open. With a little encouragement, users will help you diagnose problems, suggest fixes, and improve the code much faster than you can do it alone.

Before Linus Torvalds showed us another possibility, almost everyone in the open source world seriously underestimated how much this approach could play a role when the user base continued to expand and the system complexity continued to rise.

I even think that Linus's smartest and most far-reaching achievement is not the Linux kernel itself, but the Linux development model he invented.

Once, I mentioned this view to him in person. He smiled and repeated a sentence he often said: "I am a very lazy person who likes to take credit for things that others actually do."

Lazy as a fox.

Looking back, the Linux 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 most successful personal experience was Emacs's VC. It was a Linux-like email collaboration with a total of four participants, three of whom I have never met in person to this day.

VC is the front end inside Emacs for SCCS, RCS, and later CVS, providing one-click version control operations. It evolved from a very small, rough sccs.el mode written by someone else. The reason why VC's development was successful is that unlike Emacs, Emacs Lisp code can go through rounds of release, testing and improvement very quickly.

Our story is not unique.

Some software also adopts this two-layer architecture: the core uses the cathedral mode, and the toolbox uses the bazaar mode. MATLAB is one of them.

People who use MATLAB and other similar products often find that where there is a large and diverse user group that can participate and deliberate, that is where the motivation, enthusiasm and innovation lie.

03

Release Early, Release Frequently

Releasing early and releasing frequently is a key step in Linux development.

In the past, most developers, including me, felt that this approach was unreliable once the project was a little more complex. Early versions usually have many problems, and users have limited patience, which cannot be consumed at the very beginning.

This view also prompted people to generally adopt cathedral-style development. If the primary goal is to minimize the number of defects encountered by users, you should release a version every six months or longer, and debug like a dog between two releases. The C core of Emacs was developed in this way.

But a year later, as Linux attracted widespread attention, a completely different paradigm was being born.

Linus's open development policy is exactly the opposite of building a cathedral. Linux's Internet code archive expanded rapidly, and multiple distributions appeared one after another. All of this is driven by the unprecedented release frequency of the core system.

Linus regards users as co-developers, releases early and frequently, and listens carefully to user feedback.

This is not Linus's innovation. The Unix world has had this tradition for a long time. His innovation is to upgrade this method to the scale and intensity that matches the complexity of the system he developed.

As early as 1991, we heard that he released more than one new version a day. Because he worked harder than anyone else to cultivate co-developers, and made full use of the Internet to promote collaboration.

This method worked.

But why did it work? Is this something I can imitate, or can only a genius like Linus Torvalds do it?

Linus is certainly a top-tier hacker. How many of us can build an industrial-grade operating system kernel from scratch? But Linux did not bring any huge conceptual breakthrough. Linus is at least not a design innovation genius like Richard Stallman or James Gosling.

In my opinion, Linus is a genius of engineering and execution. He has a sixth sense to avoid dead ends, and the real ability to find the fastest path from point A to point B.

The whole Linux reveals this trait.

He believes that if the group of beta testers and co-developers is large enough, almost every problem will surface quickly, and there will always be someone who can solve it easily.

As long as there are enough eyes, all bugs are obvious.

I call it "Linus's Law".

My earliest understanding was that every problem will have someone who figures it out. But Linus did not quite agree. He said that the person who understands and solves the problem is usually not the first person to discover it, and "discovering the problem is the more difficult step."

When thousands of developers are enthusiastically thinking about every new version, everything becomes simple.

Sociologists discovered many years ago that the average contribution or judgment of a large number of participants often produces better results than a single individual. This is called the "Delphi Method".

What Linus showed is that even with the complexity of an operating system, the "Delphi Method" can still help us manage it.

The more users there are, the more problems are discovered, because there are more perspectives for inspection. When users are also developers, this effect will be further amplified. This diversity helps to reduce duplicate work.

Someone's toolbox is just right for solving this problem. For him, this problem is simple.

Linus also left a trick for himself. If there may be serious defects, the version number of the Linux kernel will allow users to choose by themselves: use the older "stable" version, or take the risk of defects to use the latest features in the cutting-edge version.

Giving users choices makes both versions more attractive.

04

Taming Complexity with Multiple Pairs of Eyes

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

Users who do not care about the source code tend to only report superficial symptoms. They take the operating environment for granted, so they often miss key background information and rarely provide a set of steps that can stably reproduce the defect.

Testers look in from the outside, while developers look out from the inside. In the closed development mode, they are trapped in their respective roles, talking past each other, and it is easy to get annoyed with each other.

Open source breaks this bondage.

Both sides can build a shared model on the basis of source code, which makes communication much easier.

If the error conditions can be described at the source code level, even if it is not complete, most defects can be caught. When one of your beta testers can point out: "There is a boundary problem on line nnn", or just say: "Under conditions X, Y, Z, this variable will overflow", a glance at the relevant code is enough to locate the problem.

Even with many collaborators, core developers can still save a lot of time.

Another time-saving aspect of open source is the communication structure. The project has a very small core, independent developers are very common, 1-3 people are the most typical; the periphery is beta testers and contributors whose number can reach hundreds.

A common problem in traditional software development is: "Adding more programmers to a project that is already delayed will only make it delayed longer." As the number of developers increases, the complexity of the project and communication costs will increase exponentially, while the actual amount of work completed will only increase linearly.

This implicitly assumes that the communication structure of the project is a complete network, and everyone must communicate with everyone else.

But in open source projects, developers are actually dealing with separate, parallel sub-tasks, and they rarely need to communicate directly with each other. Only the small core team bears these communication costs.

05

Necessary Prerequisites for the Bazaar Mode

What prerequisites are needed for the bazaar to succeed?

First of all, you can't expect the project to start from scratch and rely solely on the birth of the bazaar. The community can participate in testing, debugging and improvement, but it is difficult for the initiator to create the project from nothing.

Linus didn't do that, neither did I. A newly formed developer community first needs to get something that can run, test, and is worth exploring.

When building a community, what you need to show is a "credible commitment".

The program does not have to run particularly well, it can be rough, but it must hold two bottom lines: first, it can run; second, it can convince potential contributors that as long as they continue to invest, it will generate value in the foreseeable future.

Both Linux and fetchmail had very attractive basic designs when they were developed. Many people who think about the bazaar mode therefore believe that the project leader must have a high degree of design intuition and be smart enough.

But Linus's design came from Unix, and my original design also came from the earlier popclient. Must a bazaar project leader have outstanding design talent, or can he be competent by leveraging others?

I don't think being able to come up with original designs is the most critical thing. What is important is that you have the insight to recognize other people's excellent design ideas.

I may have underestimated the importance of original design in bazaar projects, because I have no shortage of such abilities, so I took it for granted.

But in software design, being too smart and too creative can also form a bad habit. When you should keep things stable and simple, you can't help but make them delicate and complex.

Suppose Linus Torvalds had been trying to make fundamental innovations in operating system design during the development of Linux, would it be as stable as it is now?

The reputation mechanism within the open source community also puts a subtle pressure on people. If you don't have enough skills, don't start a project that you can't stick to.

For bazaar projects, there is another skill that is not usually regarded as a software development capability, but may be more important than design: leaders must have good interpersonal skills.

This is not difficult to understand. To build a developer community, you have to attract