The Cathedral and the Bazaar is an essay/book about how Linus Torvalds threw all the normal rules of software out the window when he wrote the operating system Linux. 

Back in the day, people “knew” that the way to write good software was to assemble an elite team of expert coders and plan things out carefully from the very beginning. But instead of doing that, Linus just started working, put his code out on the internet, and took part-time help from whoever decided to drop by. Everyone was very surprised when this approach ended up putting out a solid operating system. The success has pretty much continued without stopping — Android is based on Linux, and over 90% of servers today run a Linux OS.

Before Linux, most people thought software had to be meticulously designed and implemented by a team of specialists, who could make sure all the parts came together properly, like a cathedral. But Linus showed that software could be created by inviting everyone to show up at roughly the same time and place and just letting them do their own thing, like an open-air market, a bazaar.

Let’s consider in particular Chapter 4, Release Early, Release Often. One really weird thing Linus did was he kept putting out new versions of the software all the time, sometimes more than once a day. New versions would go out with the paint still wet, no matter how much of a mess they were.

People found this confusing. They thought putting out early versions was bad policy, “because early versions are almost by definition buggy versions and you don’t want to wear out the patience of your users.” Why the hell would you put out software if it were still crawling with bugs? Well,

Linus was behaving as though he believed something like this:

> Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this: “Linus’s Law”.

This bottom-up method benefits from two key advantages: the Delphi Effect and self-selection.

More users find more bugs because adding more users adds more different ways of stressing the program. This effect is amplified when the users are co-developers. Each one approaches the task of bug characterization with a slightly different perceptual set and analytical toolkit, a different angle on the problem. The “Delphi effect” seems to work precisely because of this variation. In the specific context of debugging, the variation also tends to reduce duplication of effort.

So adding more beta-testers may not reduce the complexity of the current “deepest” bug from the developer’s point of view, but it increases the probability that someone’s toolkit will be matched to the problem in such a way that the bug is shallow to that person.

…

One special feature of the Linux situation that clearly helps along the Delphi effect is the fact that the contributors for any given project are self-selected. An early respondent pointed out that contributions are received not from a random sample, but from people who are interested enough to use the software, learn about how it works, attempt to find solutions to problems they encounter, and actually produce an apparently reasonable fix. Anyone who passes all these filters is highly likely to have something useful to contribute.

Linus’s Law can be rephrased as “D