<- Back to laws

Open-source review heuristic

Linus's Law

Given enough appropriately motivated and capable reviewers, many defects become easier to identify and characterize--but visibility alone does not supply review.

Scientific statusEngineering aphorism
Predictive formReview-discovery hypothesis
DomainSoftware quality and security
EvidenceMixed empirical evidence
Key limitationAttention and expertise are scarce
Common misusePublic code is automatically secure
INTERACTIVE MODEL

defect discovery depends on reviewer diversity, attention, expertise, and coordination

Eric Raymond summarized the idea as "given enough eyeballs, all bugs are shallow." The claim is a conditional heuristic, not a guarantee about open-source software.

Reviewer beams illuminate different modules; duplicated attention and blind spots remain visible instead of counting every pair of eyes as independent.

71.8Illustrative discovery coverage
(%)
0 reviewers60 reviewers
REVIEWER COVERAGE FIELDParallel review helps only when attention is relevant and findings are integrated.
Interactive visual model for Linus's Law.
VISIBLE PHASESTARTINGTAKEAWAYWATCH ONE FULL CYCLE

The animation runs automatically, pauses on the conclusion, and then repeats. The main control changes the scenario rather than scrubbing the timeline.

CHANGE
Active qualified reviewers
WATCH
detection probability
MEANING
Reviewer beams illuminate different modules; duplicated attention and blind spots remain visible instead of counting every pair of eyes as independent.
VISUAL MODEL

More visible code helps only when different people actually inspect the right places.

A module map receives overlapping review paths while a defect ledger separates discovered, duplicated, and untouched findings.

public codequalified attentionactionable discovery
01 / MEANING

What it actually says

The heuristic links openness to parallel debugging: source availability lets distributed reviewers inspect, reproduce, and fix defects. Diversity can make a bug obvious to someone with the right context.

In practice, participation is highly unequal. Critical dependencies may have few maintainers, security review requires expertise, and disclosure needs a response process.

Compact formdefect discovery depends on reviewer diversity, attention, expertise, and coordination
Best interpretationSoftware quality and security evidence in software engineering.
Important cautionAttention and expertise are scarce.
"A useful law compresses a pattern. It does not erase the conditions that make the pattern true."
02 / ORIGIN

How the idea developed

The modern form emerged through observation, argument, and later refinement. The timeline separates the first insight from the version now used in textbooks and practice.[1]

19971997

Eric Raymond presents The Cathedral and the Bazaar.

19991999

The published essay popularizes Linus's Law.

TodayToday

Supply-chain security measures maintainer capacity and review provenance.

Historical cautionEponymous laws often change after their first publication. Popular wording may be broader and cleaner than the original evidence.
03 / MECHANISM

How the pattern works

The relation becomes useful only when its mechanism, measurement process, and operating range are visible.

01Parallel search

Multiple reviewers can explore different code paths.

02Cognitive diversity

A defect shallow to one expert may be deep to others.

03Feedback loop

Rapid reproduction and patching turn reports into improvement.

MODELdefect discovery depends on reviewer diversity, attention, expertise, and coordination

Eric Raymond summarized the idea as "given enough eyeballs, all bugs are shallow." The claim is a conditional heuristic, not a guarantee about open-source software.

04 / APPLICATIONS

Where it earns its keep

Applications are strongest when the law changes a decision, measurement, model, or experiment rather than merely providing an analogy.

OPEN SOURCE

Measure active review

Application

Count maintainers, review depth, and response time--not repository views.

PROFESSIONAL NOTE

Fund critical dependencies.

SECURITY

Combine openness with process

Application

Use audits, fuzzing, code ownership, and coordinated disclosure.

PROFESSIONAL NOTE

Track remediation.

05 / LIMITS & MISUSE

Where it stops working

Reviewers are correlated, incentives vary, subtle vulnerabilities resist casual inspection, and popular projects can still contain long-lived defects.

Misuse

"Open source is inherently secure"

Better: Openness enables review but does not guarantee it.
Misuse

"Reviewer count equals coverage"

Better: Skill, independence, module ownership, and time matter.
07 / REFERENCES

Sources and further reading

Original publications and serious secondary scholarship are prioritized over summaries.

  1. Raymond - The Cathedral and the BazaarPrimary essay that states the aphorism.http://www.catb.org/~esr/writings/cathedral-bazaar/
  2. Schryen - Is Open Source Security a Myth?Review of theory and empirical evidence.https://doi.org/10.1145/1941487.1941501
  3. Linux Foundation - Census II of Free and Open Source SoftwareDependency and maintainer-risk evidence.https://www.linuxfoundation.org/research/census-ii-of-free-and-open-source-software-application-libraries
CONTINUE EXPLORING

Related laws, with the relationship made explicit.

These are editorial connections, not claims that the laws are mathematically equivalent.

CONTINUE READING

Place this law inside the collection.

LAW 095 / 100 PUBLISHED