What is Linus's law?
Engineering culture and software practice
Linus's law is the claim that given enough eyeballs, all bugs are shallow: with enough people looking at code, every problem will be obvious to someone. Eric Raymond stated and named it, in honour of Linus Torvalds, in his 1997 essay The Cathedral and the Bazaar. It is the most quoted argument for open development and one of the most over-stated, because eyeballs are not automatic and security bugs can hide in plain sight, as Heartbleed showed.
What this means
Linus's law is a short slogan about how bugs get found. The idea is that if many people can see the source code, a problem that baffles one person will be obvious to another, so faults surface and get fixed quickly. It is the classic case made for open development: put the code where lots of people can look at it, and the looking itself becomes a form of quality control.
The phrase most people quote, given enough eyeballs, all bugs are shallow, is the informal version. The more careful statement is that with a large enough base of testers and co-developers, almost every problem will be spotted quickly and its fix will be obvious to someone. The naming honours Linus Torvalds, the creator of Linux, whose project seemed to prove the point.
It has a name because it captures a real and useful effect, the value of more people reviewing work, in a memorable line. The trouble is that the memorable line has been stretched far beyond what the evidence supports, into a comforting belief that open code is automatically safe. That gap between the slogan and the reality is what a careful reader needs to understand.
Why it matters
For anyone buying or depending on software, Linus's law shows up as a procurement argument, usually unspoken: it is open source, so it has been checked. That sentence does a lot of quiet work in decisions to adopt a component, and it is often false comfort. Openly available code has not necessarily been reviewed by anyone competent, motivated and available to look for the specific problems that matter to you. Visibility is a precondition for scrutiny, not a substitute for it.
The law matters because it points at something true and something false at the same time. The true part is that review works: having more people examine changes genuinely improves quality, and breadth of participation is linked to fewer defects. The false part is the assumption that the eyeballs simply show up. Attention is scarce, expert attention scarcer, and much widely used open code is maintained by a tiny number of people, sometimes unpaid, with no queue of reviewers behind them.
The AI era inverts the eyeballs problem in a way leaders should notice. AI tools can generate large volumes of code quickly, which means there is more code to review and, relatively, fewer people reading each line. The many-eyes assumption gets weaker precisely as the volume of code grows, which is the opposite of what Linus's law would have you expect.
Understanding the law properly changes what due diligence looks like. Instead of taking open as a synonym for safe, a careful organisation asks who actually reviews this code, how it is funded, whether it has been audited and how quickly problems get fixed. Those questions are the practical residue of a slogan that, taken at face value, gives more reassurance than it has earned.
How it works
Where the term came from
Eric Raymond stated and named Linus's law in his 1997 essay The Cathedral and the Bazaar, first presented at a Linux conference that year and later published as a book in 1999. Raymond wrote the informal version, given enough eyeballs, all bugs are shallow, and the more formal one about a large enough base of testers and co-developers, and dubbed it Linus's law in honour of Linus Torvalds, whose Linux project was the evidence for it. Raymond was careful to record Torvalds's own refinement: the person who finds a problem is often not the one who understands and fixes it, and, in Torvalds's words, finding it is the bigger challenge. The essay contrasts a closed cathedral style of development with an open bazaar style, and the law is the heart of the case for the bazaar.
There is a second, unrelated Linus's law that causes occasional confusion. In his prologue to Pekka Himanen's 2001 book The Hacker Ethic, Torvalds set out his own law about human motivation, that everything people do can be classified under survival, social life and entertainment, with progress meaning a move up that hierarchy. That is a claim about why hackers work, not about how bugs are found, and it should not be mixed up with Raymond's law about eyeballs.
The mechanism Raymond proposed
Raymond's argument was not simply that more people means fewer bugs by magic. He proposed a mechanism: parallel debugging by a wide community, combined with treating users as co-developers. In the bazaar model, code is released early and often, so that many people run it in many different conditions. Because each user has a slightly different setup, someone somewhere is likely to have exactly the configuration that reproduces a given fault, which turns a mysterious intermittent problem into an obvious one. The finding and the understanding may come from different people, but both, Raymond argued, tend to happen quickly when the crowd is large and the code is open.
The deeper claim underneath is about the nature of bugs. In the cathedral view, bugs are deep, insidious phenomena that take a dedicated few months to root out. In the bazaar view, bugs turn shallow quickly once enough co-developers are pounding on every release. The law is really a statement that scale and openness change what kind of problem debugging is.
What the evidence supports and what it does not
The evidence broadly supports the value of review and of broad participation. A 2016 study by Shane McIntosh, Yasutaka Kamei, Bram Adams and Ahmed Hassan in the journal Empirical Software Engineering found that code review coverage, participation and reviewer expertise all share a significant link with software quality, and that poorly reviewed code has a measurable negative effect. So the core intuition, that more and better review helps, holds up.
What the evidence does not support is the strong form of the slogan. Robert Glass listed Linus's law among the fallacies in his 2003 book Facts and Fallacies of Software Engineering, calling it a mantra of the open source movement while noting that research finds the number of useful reviewers is small, that the rate of new bugs found does not scale linearly with the number of reviewers, and that no research supports the law as stated. Eyeballs are not automatic; attention is scarce; and some bugs, particularly subtle security flaws, hide in plain sight even when the code is fully public. Closed-source practitioners tacitly agree, because they rely on stringent review by a few experts rather than on the sheer number of viewers.
Heartbleed and the funding story
The standard counterexample is Heartbleed, a serious flaw disclosed in April 2014 in OpenSSL, a cryptographic library used across a large share of the internet. The bug, catalogued as CVE-2014-0160 and flagged by the US authorities, let attackers read chunks of a server's private memory, exposing keys and passwords. Crucially, it had been introduced into OpenSSL in December 2011 and shipped in a release in March 2012, so it sat in widely used, openly available code for around two years before being found independently by a Google security researcher and a Finnish security firm in 2014. Raymond himself reportedly conceded that in this case there weren't any eyeballs.
The reason was money and manpower. OpenSSL, despite underpinning much of the web's encryption, was maintained on a shoestring; the OpenSSL Software Foundation typically received only about two thousand US dollars a year in outright donations, and the project was staffed by a handful of people, only a few of them full-time. Heartbleed made the point that openness without funding, tooling and incentives does not conjure reviewers into being. In response, on 24 April 2014 a group of thirteen technology companies, including Amazon, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Qualcomm, Rackspace and VMware, formed the Core Infrastructure Initiative under the Linux Foundation, each pledging at least one hundred thousand dollars a year for three years, which funded full-time developers for critical projects including OpenSSL. The episode is the clearest evidence that eyeballs need to be paid for and organised, not merely permitted.
The AI-era reading
Linus's law reads differently now that machines write code. When an AI tool can produce large volumes of code quickly, the ratio of code to competent reviewers gets worse, not better. The many-eyes assumption depended on there being enough motivated, qualified people to look; generating more code faster stretches that thin. The eyeballs problem runs in reverse: more to read, relatively fewer reading it, and a temptation to trust the output because it compiles and passes a few tests.
The sensible modern reading keeps the true kernel and drops the false comfort. Review works, and breadth of participation helps, so investing in review, whether by people or by adversarial testing of a system, is worthwhile. But the presence of a crowd, or of an AI assistant, is not a guarantee that anyone has actually looked with the right expertise at the parts that matter. That is a judgement to verify, not an assumption to rest on.
Examples
A mid-sized accountancy firm is choosing an open-source library to handle sensitive client data. A partner argues that because it is open source, it must have been thoroughly checked. A more careful colleague applies the lesson of Linus's law and looks at who actually maintains the project. It turns out to be one unpaid volunteer with a backlog of unreviewed changes. The firm does not reject the library outright, but it commissions a review and factors the maintenance risk into the decision, rather than treating open as a synonym for safe.
A charity relies on a widely used encryption component and had assumed, after reading about Heartbleed years ago, that such things are always caught quickly. When the trustees revisit the question, they ask how the component is funded and how fast security fixes are issued. Finding that it depends on a small, under-resourced team, they choose to contribute modestly to its upkeep and to subscribe to its security advisories, recognising that eyeballs need funding and organisation to exist at all.
A software team of eight has started using an AI assistant that generates large amounts of code. An engineer notices that review has not kept pace: there is far more code than anyone is actually reading closely. The team treats this as the eyeballs problem in reverse, reinstates mandatory human review for anything touching security or payments, and adds adversarial testing so that many deliberate attempts to break the system stand in for the many eyes the slogan assumes.
Common misunderstandings
People take the slogan to mean open source is automatically secure. It does not. The law says that if enough qualified people look, problems surface; it does not promise that anyone competent has looked at all. Openness makes scrutiny possible; it does not perform it.
People assume the two Linus's laws are the same idea. They are not. Raymond's law, about eyeballs and bugs, is unlike Torvalds's own Linus's law in The Hacker Ethic, which is about human motivation, survival, social life and entertainment. They share a name and nothing else, and conflating them muddles the discussion.
People believe more reviewers always means proportionally fewer bugs. Research suggests otherwise: the number of genuinely useful reviewers is small, often just a few, and adding more beyond that finds additional bugs at a much lower rate. The benefit of extra eyeballs flattens out quickly.
People think Heartbleed proves the law is worthless. That overshoots. Heartbleed disproves the strong, automatic version of the law, but the underlying value of review and broad participation still holds. The correct conclusion is that eyeballs must be funded and organised, not that review is pointless.
People assume an AI assistant reviewing code counts as extra eyeballs. It is not a substitute for competent human scrutiny of the parts that matter, and because AI generates more code than it reliably reviews, leaning on it can weaken the very many-eyes effect the law describes.
Risks and boundaries
The main risk with Linus's law is using it as a reason not to think. As a piece of folklore it is memorable and partly true, which is exactly why it is dangerous when quoted as a guarantee. It describes a tendency under favourable conditions, a large, motivated, competent community actively reading the code, and says nothing useful when those conditions are absent, which is often.
The folklore outruns the evidence most clearly on security. Subtle vulnerabilities can persist for years in public code, because finding them requires specific expertise and deliberate effort rather than casual reading, and because many viewers wrongly assume someone else has checked. This is a documented pattern, not a one-off; Heartbleed is the famous case but not the only one. The honest position, which Glass reached decades ago, is that the strong form of the law is a fallacy, even though the weak form, review helps, is sound.
There is also a boundary around what the law was ever about. Raymond's essay is a broad argument about development styles; the law is one line within it. This explainer is about that claim alone, its wording, its evidence and its limits, not a summary of the whole essay, and not the same thing as a general account of open-source software. Keeping that scope tight is part of using the term responsibly rather than as a slogan.
What to do next
Stop treating open as a synonym for checked. When someone justifies a component by saying it is open source, so it has been reviewed, ask who actually reviews it and when they last did. Visibility is not scrutiny, and the difference is where the risk lives.
Ask about funding and maintenance for anything you depend on. A critical component maintained by one or two unpaid people is a risk regardless of how many users it has. Where a dependency matters, consider contributing to its upkeep, because eyeballs need funding, tooling and incentives to exist.
Do real due diligence rather than relying on reputation. For anything sensitive, look for evidence of audits, a security advisory process, and a track record of fixing problems quickly, rather than assuming the crowd has it covered.
Invest in review deliberately, because that part of the law is true. Fund code review, keep the number of skilled reviewers on important changes adequate rather than nominal, and for AI systems use adversarial testing so that many deliberate attempts to break the system stand in for the many eyes the slogan assumes.
Watch the ratio of code to reviewers as AI generation grows. If your team is producing far more code than it can read carefully, reinstate mandatory human review for the parts that matter most, so that speed of generation does not quietly hollow out your scrutiny.
FAQs
What does Linus's law actually say?
That given enough eyeballs, all bugs are shallow: with a large enough base of testers and co-developers, almost every problem will be spotted quickly and its fix obvious to someone.
Who named it, and after whom?
Eric Raymond stated and named it in his 1997 essay The Cathedral and the Bazaar, naming it in honour of Linus Torvalds, the creator of Linux.
Is there another Linus's law?
Yes. In the 2001 book The Hacker Ethic, Torvalds set out his own law about motivation, that human activity falls under survival, social life and entertainment. It is unrelated to the one about bugs.
Does open source being visible mean it is safe?
No. Openness makes review possible but does not perform it. Code can be public and still unreviewed by anyone with the right expertise, which is where the false comfort creeps in.
What does Heartbleed show about the law?
That the automatic version is wrong. A serious flaw sat in hugely popular open code for around two years because the project was under-funded and barely staffed, so the eyeballs the law assumes were not there.
Is the law simply false, then?
Not entirely. Review and broad participation genuinely improve quality, which research supports. What fails is the strong claim that enough viewers appear automatically and that bugs cannot hide.
How does AI change the picture?
It weakens the assumption. AI can generate far more code than people can carefully review, so the ratio of code to competent eyeballs gets worse, not better.
What should we ask before trusting an open component?
Who reviews and maintains it, how it is funded, whether it has been audited, and how fast security problems are fixed. Those questions replace the slogan with real due diligence.