> ## Documentation Index > Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt > Use this file to discover all available pages before exploring further. # Linus's Law > Linus's Law says that with enough reviewers, almost every bug becomes easy to find and fix. Learn origin, tactics, and where open scrutiny fails. **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. Extra people help only if they exercise different paths, platforms, and threat models. Idle watchers are not eyeballs in Raymond's sense. Discovery and repair are different jobs. Community reports can surface symptoms; maintainers still need expertise to patch root causes—unlike [Brooks's Law](/laws/brookss-law), which warns that adding people can slow delivery when coordination dominates. Frequent releases give reviewers repeated chances to notice regressions. Without runnable artifacts and clear channels to report, openness is theater. 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](/laws/hyrums-law) when silent dependencies mask broken edges. ## Applications Use Linus's Law when you can genuinely widen who sees and stresses the work. Publish changelogs, invite reproducible bug reports, and route security issues to people who can review crypto and memory safety—not only feature enthusiasts. Rotate reviewers across teams, require runnable demos, and treat “LGTM without running it” as a failed eyeball. Recruit users who match real edge cases (locales, devices, accessibility) so feedback covers the surfaces that will break in production. Share drafts early with peers who disagree with you; [Cunningham's Law](/laws/cunninghams-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. It predicts faster characterization *when* enough capable reviewers look. Popularity without review coverage can leave deep bugs untouched for years. 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. ## Related Concepts These pages help place Linus's Law among collaboration limits, incentives, and failure patterns. Adding people can raise coordination cost—eyeballs help only when communication stays workable. Wrong claims attract corrections; related dynamics of public exposure and response. Users depend on every observable behavior—including buggy ones that “enough eyeballs” never challenged. Tolerance aids interoperation but can hide protocol quirks that reviewers must still examine. What can go wrong may still go wrong—scrutiny reduces surprise, it does not abolish failure modes. 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.