# Linus's law

> "Given enough eyeballs, all bugs are shallow" — the open-source claim about review, and why the evidence for it is thin.

Concept · Laws of software engineering · https://levelcode.org/concepts/linus-law

**Linus's law** says: given enough eyeballs, all bugs are shallow. Eric S. Raymond coined it in *The Cathedral and the Bazaar* (1997) and named it after Linus Torvalds, whose way of running Linux development inspired the essay. Torvalds didn't say it himself. Raymond's longer version is more careful: with a large enough base of testers and co-developers, almost every problem will be characterized quickly and the fix will be obvious to someone.

## How it works

The idea is that bugs hard for one person are easy for another. If enough people with different backgrounds run and read the code, someone has already seen this kind of failure, knows that corner of the system, or has the exact machine where it reproduces. Open source makes the code visible to everyone, so in principle it gets more of those people.

The part that holds up well is **diagnosis**. Once a bug is reported and reproducible, a large community really does pin it down fast. A public issue tracker with a stack trace and a reproduction often gets a fix within hours.

> [!NOTE]
> **Why it's disputed.** The law assumes the eyeballs exist and are looking. Usually they aren't. Heartbleed sat in OpenSSL, one of the most widely deployed libraries on the internet, for about two years before it was found in 2014. Shellshock had been in Bash since 1989 and was found in 2014. The xz-utils backdoor of 2024 was not caught by code review at all; an engineer noticed SSH logins getting half a second slower and went digging. Most open-source projects have one or two maintainers, and "anyone *can* read the code" is very different from "someone *did*". Visibility is necessary for review, not sufficient.

## What to take from it

- **Many users find bugs; few readers find vulnerabilities.** Use the law for diagnosis, not as a security argument.
- **Review is a practice, not a property.** Code is reviewed when someone is assigned to review it. Make that explicit in [pull requests](https://levelcode.org/roadmaps/git/pull-requests).
- **Know who maintains what you depend on.** Popular is not the same as well-watched. [SBOMs and provenance](https://levelcode.org/concepts/sbom-and-provenance) help you see what you ship, and the [supply chain security](https://levelcode.org/roadmaps/devsecops/supply-chain-security) lesson covers what to do about it.
- **Fund the eyeballs.** Paid audits, fuzzing and maintainer funding are what actually put people on the code.