Linus's Law
Given enough eyeballs, all bugs are shallow.
Tiny Summary
Linus's Law: "Given enough eyeballs, all bugs are shallow." With many reviewers, bugs become easy to find and fix. The foundation of open-source success.
The Law
Eric S. Raymond: "Given enough eyeballs, all bugs are shallow." Named after Linus Torvalds (Linux creator), who demonstrated this with open-source development.
The Logic
More reviewers → More bug discoveries: 1 reviewer misses bugs. 10 reviewers: someone spots it. 1000 reviewers: bugs found quickly.
Bugs hard for one person are obvious to another: Different perspectives, different expertise, someone has seen it before.
In Practice
Open source: Linux kernel with thousands of contributors. Bugs found and fixed rapidly. Code review at scale.
Code reviews: 2 reviewers better than 1. 4 reviewers better than 2. Diminishing returns after ~4.
Security: Public code gets more scrutiny. "Security through obscurity" fails. Open protocols more secure.
Limitations
Not all bugs are shallow: Concurrency bugs, race conditions hard even with eyeballs. Some need domain expertise.
Eyeballs must be engaged: Passive reviewers don't help. Need active, qualified reviewers. Quality > quantity.
Research: Best results with 2-4 reviewers. Beyond 4: diminishing returns. 100 passive viewers < 2 active reviewers.
Why It Works
Cognitive diversity (different backgrounds spot different issues). Parallel processing (multiple people simultaneously). Knowledge sharing (someone has seen this bug before).
Key Insights
Code review is valuable (2-4 reviewers optimal). Open source leverages Linus's Law. Transparency helps security. But bugs still need active, qualified reviewers. "All bugs are shallow" is aspirational, not guaranteed. Anti-pattern: Too many reviewers → bikeshedding and process paralysis.