Have you ever found a strange error in a phone app you just bought, reported it to the developer, and been told a few days later that hundreds of people with the same problem had already reported it and a fix was on its way? Problems whose cause you could barely guess at on your own often get solved surprisingly quickly once many people look at them together. The saying that captures this idea, that bugs come to light more easily the more eyes are gathered on them, is Linus’s Law.
Put simply, Linus’s Law is the rule of thumb that “given enough eyeballs, all bugs are shallow.” It has long been quoted as the classic explanation of why open source development, in which source code is made public for anyone to examine, is so powerful.
In this piece we will look in turn at where the law came from and what it means exactly, at why many eyes make a difference, and at cases that exposed the law’s limits along with ways to put it to work in practice.
How Many Eyes Protect Software, and Where That Falls Short
What Is Linus’s Law?
The law was set out by the American programmer Eric S. Raymond in his essay The Cathedral and the Bazaar, which he first presented in 1997 and published as a book in 1999. It is named after Linus Torvalds, the Finnish-born developer who created the Linux kernel in 1991.
Raymond spelled the law out more precisely as “given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone.”
(1) The cathedral model
A small group of experts designs carefully behind closed doors and releases the result only once it has reached a high level of polish. This view holds that bugs hide deep and can only be found through long testing.
(2) The bazaar model
Software is released early and often, and anyone is free to offer opinions and fixes. Linux was developed this way, and Raymond believed that thanks to its many participants, bugs surfaced quickly.
Why Many Eyes Find Bugs
The heart of Linus’s Law is that finding a bug and fixing it can be handled by different people. Even if the person who first runs into a problem has no idea what causes it, someone else who sees the symptoms may think of the fix right away.
- Diverse Environments: because everyone uses different devices in different ways, problems show up in situations the developers never got around to testing.
- Peer Review: other developers read the code and point out mistakes the author missed.
- Parallel Debugging: several people trace the cause at the same time and find a lead faster than one person working alone.
(1) The people who report symptoms
When a user who hit a bug leaves detailed steps to reproduce it, the time needed to narrow down the cause drops dramatically.
(2) The people who recognize the cause
To a developer who has dealt with a similar problem before, a bug that looks deep to others looks like a shallow one. That is exactly what the word “shallow” in the law refers to. The more participants there are, the greater the chance of finding someone like this.
Cases That Showed the Law’s Limits
[Case 1] Heartbleed, hidden for more than two years
OpenSSL is open source software widely used for encrypted communication on the internet, and code that went into it after review at the end of 2011 contained a flaw. The flaw spread starting with the release of March 2012, but it was not made public, under the name Heartbleed, until April 2014. At the time of disclosure, about 17% of web servers using trusted security certificates, roughly 500,000 sites, were estimated to be at risk. In September of the same year, Shellshock was also discovered: a flaw that had been hiding for about 25 years, since 1989, in Bash, a command-processing program widely used on Linux and other systems.
[Case 2] Critical software left to a handful of people
When Heartbleed came to light, OpenSSL was maintained by just a few volunteers, only one of whom worked on it full time. It showed that even when code is open for anyone to see, bugs can stay hidden for a long time if nobody actually examines it carefully. Right after the incident, the Linux Foundation joined with major companies to create a fund supporting critical open source projects.
Making Linus’s Law Work in Practice
The software engineer Robert Glass criticized the law, citing research showing that adding reviewers does not increase the number of bugs found in proportion, and that the number of useful reviewers is around two or three to four. On the other hand, some analyses have found that the more popular an open source project is, the higher its rate of bug fixes, so the debate continues to this day. In the end, what matters is not the number of eyes but how many of them are actually looking at the code.
(1) Make code review part of the process
If every change is read and approved by at least one colleague before it goes in, you can get the benefit of many eyes whether or not the code is public.
(2) Gather people and resources around critical code
The more services depend on a core component, the more it needs dedicated maintainers and regular security audits.
(3) Make bug reporting easy
When users can report problems easily and check on their progress, outside eyes gather naturally.
(4) Fill the gaps with automated tools
Boundary-value errors that people easily overlook are best checked again and again with automated testing tools.
Linus’s Law sums up in a single sentence the belief that open collaboration can raise the quality of software. But as Heartbleed reminded us, simply making code public is not enough: the law only shows its full strength when there are people who actually read and test that code.
Gathering eyes that truly look at the code in plain view: that is the first step toward safe software.
