Skip to main content
Category: Laws
Type: Open-source collaboration and software quality heuristic
Origin: Eric S. Raymond, The Cathedral and the Bazaar (First Monday, 1998; O’Reilly book, 1999); named for Linus Torvalds
Also known as: “Given enough eyeballs, all bugs are shallow”
Quick Answer — Linus’s Law claims that with a large enough tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone. More eyes do not invent competence; they raise the odds that someone has the right perspective. Use it to design review and release loops—not as a guarantee that popular code is safe.

​
What is Linus’s Law?

Linus’s Law is the software-engineering claim that broad, diverse scrutiny tends to make defects shallow—easy to spot and straightforward to repair—compared with closed, cathedral-style development.
Given enough eyeballs, all bugs are shallow.
Eric S. Raymond’s fuller wording is: given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Picture a lost key in a park: one walker may miss it for days; a hundred people crossing the same path raise the chance of a quick find. In code, “shallow” does not mean trivial forever—it means exposed to enough attentive minds that characterization and repair accelerate.

​
Linus’s Law in 3 Depths

  • Beginner: Many careful readers find bugs faster than a tiny closed team.
  • Practitioner: Ship early enough for feedback, but only if reviewers can actually run, read, and report on the change.
  • Advanced: Eyeballs help when incentives, tooling, and expertise cover the risk surface; without that coverage, popularity alone leaves deep bugs untouched.

​
Origin

Eric S. Raymond coined Linus’s Law in The Cathedral and the Bazaar, first widely published in First Monday in March 1998 and later expanded as an O’Reilly book (1999). He named it for Linus Torvalds, whose Linux development style—release early and often, open to outside contributions—contrasted with “cathedral” projects built by small isolated teams. Raymond argued that cathedral builders treat bugs as deep and insidious, so they ship rarely; bazaar builders treat bugs as mostly shallow once many co-developers pound each release. Torvalds later clarified an important split Raymond adopted: the person who finds a bug is often not the person who understands and fixes it—and finding is frequently the harder step. The law therefore rests on parallel search across many minds, not on every reporter being a master debugger.

​
Key Points

Linus’s Law is a bet about search and perspective diversity, not a magic spell cast by starring a repository.
1

Scale review, not just headcount

Extra people help only if they exercise different paths, platforms, and threat models. Idle watchers are not eyeballs in Raymond’s sense.
2

Separate finding from fixing

Discovery and repair are different jobs. Community reports can surface symptoms; maintainers still need expertise to patch root causes—unlike Brooks’s Law, which warns that adding people can slow delivery when coordination dominates.
3

Release loops create exposure

Frequent releases give reviewers repeated chances to notice regressions. Without runnable artifacts and clear channels to report, openness is theater.
4

Coverage beats fame

Widely used code can still hide rarely exercised paths. Pair community review with tests, fuzzing, and focused audits—especially where incentives are weak, a lesson sharpened by Hyrum’s Law when silent dependencies mask broken edges.

​
Applications

Use Linus’s Law when you can genuinely widen who sees and stresses the work.

Open-source maintainership

Publish changelogs, invite reproducible bug reports, and route security issues to people who can review crypto and memory safety—not only feature enthusiasts.

Internal code review

Rotate reviewers across teams, require runnable demos, and treat “LGTM without running it” as a failed eyeball.

Product beta programs

Recruit users who match real edge cases (locales, devices, accessibility) so feedback covers the surfaces that will break in production.

Learning and writing

Share drafts early with peers who disagree with you; Cunningham’s Law is a cousin—wrong or incomplete claims often attract corrections faster than private polish.

​
Case Study

Heartbleed shows where “enough eyeballs” is not automatic. The OpenSSL TLS Heartbeat bug (CVE-2014-0160) was introduced into the OpenSSL source tree on 31 December 2011, shipped widely with OpenSSL 1.0.1 on 14 March 2012, and publicly disclosed with a fix in 1.0.1g on 7 April 2014—more than two years of exposure in a library underpinning much of the public web. A missing bounds check let attackers read up to about 64 KB of process memory per request, potentially including keys and credentials. OpenSSL was open source and heavily used; still, the flaw sat unnoticed by general traffic until specialist discovery (including reports associated with Google Security and Codenomicon) forced coordinated disclosure. The lesson is not that open review is worthless—it is that Linus’s Law needs relevant eyeballs on exercised code paths, plus incentives to look for silent memory bugs. Boundary note: after disclosure, the same open ecosystem shipped patches quickly; the failure was long undetected depth, not inability to respond once characterized.

​
Boundaries and Failure Modes

Linus’s Law fails when “many users” are not “many reviewers.” Downloads are not audits. Cryptographic, concurrent, and hardware-specific defects often need rare expertise and instruments that casual contributors lack. It also fails when social dynamics suppress reports: hostile maintainer culture, unclear contribution paths, or liability fears shrink the effective eyeball count. A common misuse is claiming open source is automatically more secure than closed source. Openness is an opportunity for scrutiny, not a certificate of correctness. Another misuse is flooding a project with untrained reviewers and expecting quality to rise—noise without triage recreates coordination costs familiar from Brooks’s Law.

​
Common Misconceptions

Separate the slogan from the conditions that make it true.
No. Eric S. Raymond named and popularized it after Torvalds’s Linux practices. Torvalds refined the find-versus-fix distinction; he did not publish it as a mathematical law.
No. Stars measure attention, not exercised review. Eyeballs that never run the code, never read the risky modules, or never file issues do not shallow bugs.
These pages help place Linus’s Law among collaboration limits, incentives, and failure patterns.

Brooks's Law

Adding people can raise coordination cost—eyeballs help only when communication stays workable.

Cunningham's Law

Wrong claims attract corrections; related dynamics of public exposure and response.

Hyrum's Law

Users depend on every observable behavior—including buggy ones that “enough eyeballs” never challenged.

Postel's Law

Tolerance aids interoperation but can hide protocol quirks that reviewers must still examine.

Murphy's Law

What can go wrong may still go wrong—scrutiny reduces surprise, it does not abolish failure modes.

Gall's Law

Working complex systems grow from simpler ones; early exposure can catch defects before complexity hides them.

​
One-Line Takeaway

Open the work to people who can actually run and challenge it—eyeballs without coverage are just an audience.