Linus's Law

Linus’s Law states: “Given enough eyeballs, all bugs are shallow.” It was coined by Eric Raymond in his 1999 essay The Cathedral and the Bazaar, named after Linus Torvalds, and has since become the founding catechism of the open-source movement — a single sentence that transformed “many people might look at this code” into “many people will look at this code, and they will find the bugs, and the bugs will be fixed, and the software will be better.” It is a beautiful sentence. It is a comforting sentence. It is, upon close inspection, almost entirely wrong.

“THE FIELD THAT IS WATCHED BY A THOUSAND EYES
IS NOT BETTER GUARDED
THAN THE FIELD WATCHED BY ONE

A THOUSAND EYES ASSUME
THAT SOMEONE ELSE IS WATCHING”
— The Lizard, contemplating the bystander effect in version control

The Claim

Raymond’s formulation is elegant. In the “bazaar” model of open-source development, code is released early and often, exposed to a vast community of developers, and therefore subjected to massive parallel review. Any bug, no matter how subtle, will eventually fall before the sheer statistical weight of eyeballs directed at it. The more people who look, the shallower the bugs become.

This contains three assumptions:

1. The eyeballs will look. They will download the source, open the relevant files, read the code with comprehension, and identify defects.
2. The eyeballs will look at the right thing. They will examine the dark corners where bugs live, not the well-lit entrance hall where the README is.
3. The eyeballs will coordinate. They will not duplicate each other’s effort, will not argue about irrelevant style preferences, and will not create more chaos than they resolve.

All three assumptions are false. Not occasionally false. Not edge-case false. Structurally, fundamentally, demonstrably false.

The First Problem: Nobody Is Looking

The median number of eyeballs examining any given open-source project is zero. Not metaphorically zero. Literally zero.

The vast majority of open-source code is never read by anyone other than its author. The packages that are read are read by users looking for API documentation, not by reviewers looking for bugs. The pull requests that are reviewed are reviewed for style, naming conventions, and whether the contributor signed the CLA — not for subtle concurrency defects or off-by-one errors in boundary conditions.

The 2014 Heartbleed vulnerability in OpenSSL demonstrated this with surgical precision. OpenSSL was one of the most critical pieces of open-source infrastructure on the internet, used by approximately two-thirds of all HTTPS servers. It had been open source for years. The eyeballs were theoretically available. The eyeballs, it turned out, had not looked at the TLS heartbeat extension code. Not because the code was hidden. Not because the code was obfuscated. Because the code was boring, and eyeballs — being attached to humans — prefer interesting code.

“The eyeballs were available. They were looking at JavaScript frameworks.”
— The Caffeinated Squirrel, missing the point about which eyeballs were the problem

The Second Problem: The Wrong Thing

When eyeballs do look, they look at what is visible, not at what is important. This is not a character flaw. It is optics.

A GitHub repository with ten thousand stars attracts contributors who look at the API surface, the configuration options, the documentation, and the parts of the code that are referenced in tutorials. They do not look at the memory allocator. They do not look at the certificate validation logic. They do not look at the function that has not been modified since 2011 and has a comment reading // TODO: handle edge case above a code path that handles no edge cases.

The eyeballs cluster. They cluster around the familiar, the accessible, the recently changed. The bugs that matter — the security vulnerabilities, the data corruption paths, the race conditions that manifest only under load — live in the code that nobody finds interesting enough to read.

This is not a failure of open source. It is a failure of the premise that quantity of attention substitutes for quality of attention. One security researcher reading the heartbeat extension code for thirty minutes would have found Heartbleed. Ten thousand developers reading the README would not have found it in ten thousand years.

The Third Problem: The Thundering Herd of Debuggers

And now we arrive at the delicious part.

Suppose, against all odds, the eyeballs do look. Suppose they look at the right thing. Suppose a bug is found and a hundred developers converge on it simultaneously.

What happens next is not parallel debugging. What happens next is a Thundering Herd.

A hundred developers discover the same bug. They each open their editor. They each begin to understand the code. They each form a theory. They each write a fix. They each submit a pull request. Now there are a hundred pull requests for the same bug, each slightly different, each reflecting a different understanding of the codebase, each requiring review by a maintainer who is now spending their time evaluating a hundred fixes instead of writing one.

This is Brooks’s Law wearing a trench coat and fake moustache. Adding people to a debugging effort does not make the bug shallower — it makes the coordination deeper. The bug has not changed. It is the same bug it was when one person was looking at it. But now a hundred people are arguing about the fix in a GitHub issue thread that has grown to 847 comments, of which approximately twelve contain useful information, forty contain “me too,” and the rest are a debate about whether the variable should be called count or total.

“A stampede of people debugging the same program only makes it harder. You don’t get a fix. You get a coordination problem.”
— riclib, who has seen enough GitHub threads to know

The thundering herd of debuggers exhibits all three properties of the classical Thundering Herd: a trigger event (the bug report), a shared resource (the maintainer’s attention), and individual innocence (each contributor, examined alone, is being helpful). Together, they are a siege.

The Bystander Effect, Compiled

There is a well-documented phenomenon in social psychology called the bystander effect: the more people who witness an emergency, the less likely any individual is to help, because each person assumes someone else will act.

Open source has the bystander effect at scale. The more popular a project, the more each potential reviewer assumes that someone else is reviewing the security-critical code. Someone with more experience. Someone with more context. Someone whose job it is.

Nobody’s job it is. That is the point of open source. The code is available to everyone, which means it is the responsibility of no one, which means it is reviewed by whoever gets around to it, which means the TLS heartbeat extension goes unreviewed for two years while a thousand developers contribute syntax highlighting themes.

“I assumed someone had reviewed it. Everyone assumed someone had reviewed it. The bug assumed no one had reviewed it. The bug was correct.”
— A Passing AI, reflecting on the epistemology of shared responsibility

The Dunning-Kruger Corollary

Linus’s Law has a further complication that Raymond did not address: the eyeballs are not equally calibrated.

A junior developer reading cryptographic code will not find cryptographic bugs. They will find that the code is confusing, which it is, because cryptographic code is always confusing, and they will file an issue asking why the function doesn’t use a more “intuitive” approach, and the maintainer will spend forty-five minutes explaining constant-time comparison, and the actual timing side-channel vulnerability three functions down will remain undiscovered.

The Dunning-Kruger Effect predicts this with precision: the people most confident they have found a bug are the people least qualified to identify one. The people qualified to identify one are busy, few in number, and not reading your project’s source code because they are maintaining their own.

The eyeballs are not a homogeneous resource. They are a power-law distribution in which 99% of the reviewers find 1% of the bugs, and 1% of the reviewers — the ones who would actually find the critical defects — are the ones who never show up because they are debugging their own critical defects.

What Actually Finds Bugs

If eyeballs do not find bugs, what does?

Fuzzing. Automated tools that throw garbage at code until something breaks. A fuzzer has no ego, no preference for interesting code, no tendency to read the README instead of the memory allocator. It simply tries every input until the program crashes. OSS-Fuzz has found over ten thousand bugs in open-source software. The eyeballs did not find these bugs. The machines did.

Paid audits. Security researchers who are compensated to read the boring code. They read the heartbeat extension. They read the certificate validation. They read the function with the TODO comment. They read it because they are being paid to read it, and payment, unlike open-source enthusiasm, does not preferentially flow toward interesting code.

One developer with a debugger. The Solo Developer, sitting alone in a quiet room, stepping through the code line by line, with no GitHub notifications, no Slack messages, no pull request reviews, no coordination overhead. One mind, one bug, one debugger. This is not scalable. It is, however, effective.

“THE THOUSAND-EYED BEAST SEES EVERYTHING
AND NOTICES NOTHING

THE ONE-EYED BEAST SEES LITTLE
AND MISSES LESS”
— The Lizard

Measured Characteristics

Eyeballs claimed to be reviewing open-source code:    millions
Eyeballs actually reviewing security-critical paths:  single digits
Time Heartbleed existed before discovery:              2 years
Stars on the OpenSSL repository:                       not the problem
GitHub issues with more than 100 comments:             many
GitHub issues with more than 100 comments that
  contain a working fix:                               fewer
Bugs found by fuzzers vs. eyeballs (2015-2025):        fuzzers win
Developers who read the README:                        most
Developers who read the heartbeat extension:            eventually one
Average number of duplicate PRs per popular bug:        too many
Coordination overhead per additional debugger:          O(n²)
Optimal number of people debugging a single bug:        1

See Also

• Thundering Herd — What happens when the eyeballs all converge on the same bug at the same time. Each debugger is helpful. Together they are a stampede.
• Brooks’s Law — Adding manpower to a late software project makes it later. Adding debuggers to a known bug makes it harder. The arithmetic is the same.
• Dunning-Kruger Effect — The eyeballs most confident they have found the bug are the eyeballs least likely to have found the bug.
• The Mythical Man-Month — The book that proved developer-time is not fungible, twenty-four years before Raymond claimed it was.
• Linux — The operating system that succeeded not because of Linus’s Law, but despite it — through the efforts of a small number of highly skilled maintainers who reviewed the code that mattered, not a crowd that reviewed the code that was interesting.
• Solo Developer — One mind, one debugger, zero coordination overhead. The empirically optimal debugging team.