Linus's Law
Learn it → Apply it → Save as Skill
Making something visible is not the same as making it scrutinized. Linus's Law says that with enough independent, well-matched reviewers looking at a piece of work, its flaws become easy to spot. That's a genuinely useful idea — and also one of the most casually misapplied in software, writing, and decision-making. The question worth asking isn't just "could more people see this?" but "are the right people, with different blind spots, actually looking closely?"
Learn it. Apply it. Save as Skill.
The Dr. Wallace’s Favorite Mental Models is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
Software writer Eric S. Raymond coined Linus's Law in his 1997 essay (later a 1999 book) The Cathedral and the Bazaar, summarized as: "given enough eyeballs, all bugs are shallow." He named it for Linus Torvalds, whose open, distributed style of developing the Linux kernel let thousands of outside contributors find and fix problems no single team would have caught. The deeper mechanism isn't headcount — it's that reviewers with different backgrounds notice different things. A flaw invisible to one specialist can be obvious to someone with a different vantage point. Stack ten similar reviewers and you mostly get ten similar blind spots.
More reviewers helps — until it doesn't
Research on code review and usability testing both point the same way: value peaks early with a small group of well-matched reviewers, then flattens. A codebase that is merely public, with no one actually assigned to look, can sit unexamined for years — which is exactly what happened with Heartbleed.
Use it before you trust visibility as a substitute for review.
The model is most useful right before you assume that open-sourcing code, publishing a draft, or copying a long list of people on an email counts as real scrutiny — and before you design an actual review process meant to catch specific kinds of mistakes.
Make it visible → Recruit different vantage points → Assign real ownership → Watch for diminishing returns.
Linus's Law is often repeated as a slogan — "open it up and bugs will surface." Applied carefully, it's a four-part check for whether visibility is actually converting into scrutiny.
Something has to be inspectable at all before anyone can find a flaw in it — a closed, single-author process guarantees a smaller set of eyes no matter what.
The benefit comes from reviewers with different training and blind spots, not from the raw count of people who technically could look.
"Anyone could review this" without anyone actually responsible for reviewing it tends to mean, in practice, that no one does.
Value peaks with a handful of well-matched reviewers; stacking more of the same kind of reviewer adds delay more than coverage.
Six things worth understanding before you apply it.
Expand each to see where the idea came from, why it resonated, and the well-documented ways it gets applied wrong.
The Core Claim
What Raymond actually argued
In his 1997 essay (expanded into the 1999 book) The Cathedral and the Bazaar, Eric S. Raymond contrasted two software development styles: the "cathedral," built by a small closed team working in isolation, and the "bazaar," Linus Torvalds's open, distributed style for the Linux kernel, where source code and in-progress work were visible to anyone who wanted to contribute. Raymond's summary line for why the bazaar model found bugs so fast was: "given enough eyeballs, all bugs are shallow."
Why It's Named for Torvalds
Linux as the proof of concept
The law is named in Linus Torvalds's honor because the Linux kernel demonstrated the effect at a scale few had seen before: thousands of outside contributors, with wildly different hardware, use cases, and expertise, submitted bug reports and patches that a small internal team alone would have taken far longer to find.
The Real Mechanism
It's diversity of reviewers, not headcount
Each reviewer brings different training and different blind spots. A flaw one person misses may be obvious to someone approaching the same code or document from a different angle — a security specialist, a first-time user, a domain expert in a different field. Reviewers with very similar backgrounds tend to share blind spots, so adding more of them adds comparatively little.
Where the Evidence Is Thin
Critics call it a "mantra," not a proven law
Software engineering researcher Robert Glass described Linus's Law as a mantra of the open-source movement and argued it functions more as a fallacy than a demonstrated finding, citing a lack of rigorous supporting evidence. No large-scale, peer-reviewed experiment has directly tested how reliably the effect holds across different kinds of projects.
The Famous Counterexample
Heartbleed
The Heartbleed vulnerability sat undiscovered in OpenSSL — widely used, fully open-source code — for about two years before it was found in 2014, even though in principle "enough eyeballs" had access to look. Jim Zemlin, then head of the Linux Foundation, put it bluntly about that era's high-profile open-source vulnerabilities: "In these cases, the eyeballs weren't really looking." Being open to inspection is not the same as being inspected.
Where It Does Hold Up
Partial, indirect supporting evidence
A comparative study of popular versus unpopular open-source projects within the same organizations found that the most popular projects — the kind that draw genuinely large numbers of outside contributors — had meaningfully higher bug-fix commit rates (one dataset showed a 27% higher rate for Google's most-starred projects). That's consistent with the law, though it measures fixing activity rather than directly proving broader scrutiny caused it.
A startup ships a payments feature on a deadline.
This is an illustrative example designed to teach the method.
The same visibility-versus-scrutiny pattern shows up well outside the Linux kernel.
Raymond was writing about open-source software in the 1990s, but the underlying pattern — the gap between "many people could see this" and "qualified people actually examined it" — shows up across very different kinds of work.
Paying for scrutiny, not hoping for it
Companies running bug bounty programs don't just publish code and wait — they pay specifically for the kind of deep, motivated scrutiny that casual visibility rarely produces on its own, which is itself an acknowledgment that "being public" and "being examined" are different things.
Crowd visibility with real limits
Wikipedia's open-editing model catches and corrects errors remarkably fast on high-traffic pages, where many genuinely different editors are actively watching — but far more slowly, or not at all, on obscure pages that are technically open to anyone but practically reviewed by almost no one.
Diminishing returns, formally measured
Usability research associated with Jakob Nielsen's "discount usability" work found that a single test participant reveals roughly a third of findable problems, with returns dropping quickly after a small number of additional testers — a close cousin of Linus's Law, measured directly.
Few reviewers, chosen for fit
Academic peer review deliberately uses a small number of reviewers rather than a crowd — but selects them specifically for domain expertise relevant to the paper, illustrating that matched expertise, not raw numbers, is doing the real work of catching flaws.
Real scrutiny, or just visibility mistaken for it?
Each scenario below applies — or misapplies — Linus's Law as a lens. Pick which one it is, then check yourself.
1. Before merging a change to payment code, a team assigns it to two reviewers with different specialties — one for business logic, one for security — instead of assuming the public repository will catch any problems on its own.
2. A manager argues a critical system is secure mainly because "it's open-source, so thousands of people have looked at it," without pointing to any specific audit, reviewer, or test that actually happened.
3. A team concludes that since two reviewers caught useful issues, adding fifteen more reviewers from the same team with the same background will surely catch proportionally more — and delays the release to collect all fifteen sign-offs.
4. A nonprofit publishes its decision-making process publicly and also specifically invites a financial auditor and an affected community member to review it, recognizing that visibility alone wouldn't guarantee either kind of scrutiny.
A 1997 essay about Linux that became a general-purpose shorthand — and a cautionary tale.
Expand for the origin of the phrase, the man who wrote it, and a wrinkle most popular sources skip.
Who coined Linus's Law, and who is it named for?
Eric S. Raymond, a programmer and open-source advocate, formulated the law in his 1997 essay "The Cathedral and the Bazaar," later expanded into the 1999 book of the same name. He named it in honor of Linus Torvalds, the creator of the Linux kernel, whose open development style demonstrated the effect at unusual scale — Torvalds himself did not coin the phrase.
Is it a tested scientific law?
No. It functions as an influential, widely cited heuristic rather than a rigorously proven finding. Robert Glass and others have challenged it directly for lacking strong supporting evidence, and no large-scale peer-reviewed study has definitively settled how reliably it holds across different kinds of software and organizations.
Does Heartbleed disprove it?
Heartbleed is the law's most commonly cited counterexample: a serious flaw sat in widely used, fully open OpenSSL code for roughly two years before discovery in 2014. It doesn't disprove that scrutiny works when it happens — it demonstrates that mere eligibility to look is not the same as anyone actually looking closely, which is the core qualifier the law's popular retellings often drop.
The slogan is simple; applying it responsibly is not.
Treating visibility as proof of scrutiny
Code, a document, or a decision being technically viewable by many people is not the same as those people having actually examined it closely — confirm real review happened, don't assume it.
Assuming more reviewers is always better
Research on both code review and usability testing shows value concentrates in the first few well-matched reviewers; stacking on more of the same kind mostly adds delay, not coverage.
Ignoring reviewer diversity
Ten reviewers with near-identical backgrounds tend to share blind spots. The benefit comes from different vantage points, not from a bigger headcount of similar ones.
Using it to skip dedicated security testing
"It's open-source, so someone would have found it" is exactly the reasoning Heartbleed exposed as unreliable for high-stakes security work — pair openness with a deliberate audit, not a substitute for one.
Citing it as settled science
It's a widely repeated heuristic from a 1997 essay, challenged by researchers for lacking rigorous evidence — treat it as a useful lens, not a proven law, especially in a formal risk assessment.
Applying it to closed, unassigned review
"Anyone on the team could review this" without anyone actually assigned tends, in practice, to mean no one does — assign real ownership rather than hoping for volunteers.
Some situations need a different default.
Use a dedicated security audit when...
the stakes are high enough that you need guaranteed, expert scrutiny — a penetration test or formal audit, not passive hope that a crowd will notice.
Use assigned, accountable reviewers when...
you need guaranteed coverage on a specific change — name the people responsible rather than leaving review open to whoever happens to volunteer.
Use deep expert review when...
the work is highly specialized or niche — a small number of the right experts will catch more than a larger number of generalists ever could.
One model rarely does the whole job.
Build a Linus's-Law review-design prompt.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Your AI-ready prompt
Turn this mental model into a reusable AI skill.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Linus's Law, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.
Build your own Mental Models Skills Library
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
For readers who want the nuance.
Does Linus's Law mean open-source software is always safer?
No. It means openness makes outside scrutiny possible, not automatic. Whether that scrutiny actually happens depends on how much genuine attention the project draws — a popular, actively watched project behaves very differently from an obscure one that is open in principle but unexamined in practice.
Why do diminishing returns show up so consistently?
Because the first few reviewers with different backgrounds cover most of the distinct blind spots that exist; once those perspectives are represented, additional reviewers increasingly duplicate ground already covered rather than adding new coverage.
What should replace "more eyeballs" as the goal?
Matching review structure to risk: a small number of well-chosen, accountable reviewers for most work, dedicated expert or security review for high-stakes work, and genuine openness kept as a longer-term safety net rather than the primary line of defense.