Linus's Law¶
Given enough eyeballs, all bugs are shallow: defect discovery scales with the size and diversity of the pool of independent inspectors examining code — provided they are skilled, motivated, and actually reading it, not merely granted access.
Core Idea¶
Linus's Law, formulated by Eric Raymond (1999) and attributed to Linus Torvalds, states that given enough eyeballs, all bugs are shallow: the rate at which defects are found, and the ease of fixing them, both scale favourably with the number of independent people examining code. With enough inspectors, even deep-seeming defects go shallow because someone in the pool will have the right context to spot each one. The qualifier "enough" is critical — the law requires effective, not nominal, inspection.
Scope of Application¶
Linus's Law lives within software engineering and its adjacent technical practice — across settings where a structured code artifact is examined by a pool of independent inspectors.
- Open-source development — the foundational case: the justification for the bazaar model, with the open-codebase-plus-public-bug-tracker substrate load-bearing.
- Code review inside closed organizations — mandatory multi-reviewer review (the two-eyes principle, LGTM gates).
- Bug-bounty programs — the purchased-inspector form, raising the effective pool directly.
- Security audit and penetration testing — diverse external inspectors widening the detection surface.
- Documentation and API design — more readers surfacing inconsistencies faster than internal authors.
Clarity¶
The law separates a defect's depth as an intrinsic property from its detectability as a function of how many and how varied the inspectors are: "deep" is a relation between bug and pool, not a fixed attribute. Its qualifier does the sharpest work — the law is about effective inspection, not nominal access, which is why a widely-deployed open codebase can still harbour a long-lived flaw (Heartbleed).
Manages Complexity¶
A forbidding bug-by-bug, reviewer-by-reviewer prediction problem compresses to two population parameters: the size and diversity of the effective inspector pool. The qualitative outcome reads off them, and the decisive branch — open-but-uninspected versus wide-and-diverse-and-effective — collapses a confusing scatter of secure and insecure open projects into one reading.
Abstract Reasoning¶
The law licenses a reattribution of bug depth from the code to the inspector pool, a two-parameter coverage prediction (size for coverage, diversity for blind-spot complementarity), a nominal-versus-effective boundary that refuses to infer scrutiny from access, and an interventionist move reading remedies off those parameters.
Knowledge Transfer¶
Within software practice the law transfers as genuine shared machinery across open source, code review, bounties, and audits. Beyond it the portable skeleton — parallel independent inspection, qualified by inspector skill and coordination cost — recurs in peer review, audit, red teaming, and drug-safety surveillance, but belongs to that general pattern, not the open-source slogan. It is distinct from wisdom-of-crowds (aggregating estimates, not detecting a binary flaw).
Relationships to Other Abstractions¶
Current abstraction Linus's Law Domain-specific
Parents (1) — more general patterns this builds on
-
Linus's Law is a decomposition of Parallel Independent Inspection Prime
Linus's Law is parallel independent inspection specialized to open-source code, public defect coordination, and a heterogeneous contributor pool.
Hierarchy paths (12) — routes to 8 parentless roots
- Linus's Law → Parallel Independent Inspection → Redundancy → Reserve → Economy Of Force → Allocation → Scarcity → Constraint
- Linus's Law → Parallel Independent Inspection → Redundancy → Self Checking
- Linus's Law → Parallel Independent Inspection → Redundancy → Reserve → Mobilization → Latent Realizable Capacity
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Optimization
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Heavy-Tailed Distributions
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Recurrence
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Reserve → Mobilization → Latent Realizable Capacity
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Spatial Indexing → Search and Retrieval → Trade-offs → Constraint
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Reserve → Economy Of Force → Allocation → Scarcity → Constraint
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Spatial Indexing → Search and Retrieval → Problem Space → Representation → Abstraction
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Spatial Indexing → Search and Retrieval → Problem Space → State and State Transition → Phase Space
- Linus's Law → Parallel Independent Inspection → Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Spatial Indexing → Search and Retrieval → Problem Space → Problem Representation → Representation → Abstraction
Neighborhood in Abstraction Space¶
Linus's Law sits in a sparse region of the domain-specific corpus (83rd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Software Decay & Debugging (10 abstractions)
Nearest neighbors
- Lava flow anti-pattern — 0.83
- Comments as Deodorant — 0.83
- Spaghetti Code — 0.82
- Software Entropy — 0.82
- Bus Factor — 0.82
Computed from structural-signature embeddings · 2026-07-12