Eric Raymond gave open source one of its most quoted slogans: given enough eyeballs, all bugs are shallow. The idea is that if enough people can see the code, someone will spot every bug. It's half right, and the half that's wrong got a brutal demonstration when a critical security bug hid in some of the world's most-viewed code for two years.
Key Takeaways
- Linus's Law: given enough eyeballs, all bugs are shallow, coined by Eric Raymond in The Cathedral and the Bazaar (Linus's Law).
- The real claim: with a large enough co-developer base, problems get found and fixed quickly (Linus's Law).
- Heartbleed refuted the naive version: a critical bug in ubiquitous open code went unnoticed for ~2 years (the critique).
- Eyeballs help only when they're expert, motivated, and actually looking.
The Law
Raymond formulated it in his 1999 book The Cathedral and the Bazaar, naming it for Linus Torvalds (Linus's Law). The fuller statement: given a large enough base of beta-testers and co-developers, almost every problem gets characterized quickly and the fix is obvious to someone. The implied conclusion, which became gospel in open-source advocacy, is that open code is inherently less buggy than closed code, because anyone can inspect it.
There's real truth in it. Broad exposure to real users and other developers genuinely does surface problems faster than a small closed team can, which is a large part of why code review and open collaboration work at all.
Why Heartbleed Broke the Spell
Then came Heartbleed in 2014, a catastrophic vulnerability in OpenSSL, a library that secures a huge share of the internet's HTTPS traffic. The flaw affected roughly 17% of the internet's trusted HTTPS sites and let attackers read supposedly-encrypted traffic (Netcraft), and it sat in the open, in some of the most widely deployed code on earth, for about two years before anyone caught it (the Heartbleed refutation).
The lesson is that "many eyeballs" is doing a lot of unexamined work in the slogan. Being able to see code is not the same as actually reviewing it, and reviewing it is not the same as having the security expertise to spot a subtle memory bug. Most people who "could" look at OpenSSL never did, and most who glanced at it lacked the specialized skill the bug demanded. As one rejoinder put it, given enough money (for real audits), all bugs are shallow, the eyeballs have to be paid, expert, and pointed at the problem (given enough money).
| The slogan implies | Reality requires |
|---|---|
| Anyone can see it | Someone actually reviews it |
| Many viewers | Expert viewers |
| Exposure finds bugs | Motivated, funded scrutiny finds bugs |
| Open = safe | Open + real audits = safer |
A Concrete Version
A startup open-sources a library and assumes the community will now help keep it secure, "many eyeballs." In reality almost no external developer reads their code closely; the few who use it are looking at how to call it, not at whether its input parsing is safe. A latent vulnerability lives there untouched, exactly as it would in a closed repo, until a paid security review, the funded, expert eyeballs, finds it in an afternoon. Open-sourcing changed who could look; it didn't make anyone actually look.
The Honest Counterpoint
None of this means open review is worthless, and swinging to "many eyeballs is a myth" overshoots. Broad review genuinely does catch a lot: the whole reason code review works is that a second set of eyes sees what the author can't. Open source has a strong overall security track record, and the effect is real when the eyeballs are real. The correction is narrow: visibility alone is not a security strategy. Bugs get found by specific people who are expert, motivated, and actually looking, so you have to ensure those people exist, through funded audits, dedicated reviewers, and reviewers with the right expertise, rather than assuming a crowd will materialize.
What This Means for Teams
Linus's Law is a useful stress-test of how a team thinks about quality. "Someone will catch it in review" is the small-scale version of the same fallacy, review only works if the reviewer is competent, has time, and actually engages, which is why review culture matters more than review policy. Ensuring the eyeballs are expert and motivated is a staffing and culture question: it means having senior engineers who can spot the subtle bug and a review process that gives them the time to. That is precisely the capability our vetting is built to surface. See available engineers.
Frequently Asked Questions
What is Linus's Law?
Eric Raymond's assertion, from The Cathedral and the Bazaar, that "given enough eyeballs, all bugs are shallow", meaning a large enough base of testers and co-developers will find and fix almost any problem quickly.
Did Heartbleed disprove it?
It refuted the naive version. Heartbleed was a critical bug in OpenSSL, viewable by everyone, that went unnoticed for about two years, showing that code being visible is not the same as it being competently reviewed.
So is open source less secure?
Not inherently. Broad review genuinely helps, and open source has a strong track record. The correction is that visibility alone isn't a security strategy; bugs are found by expert, motivated people actually looking, whether the code is open or closed.
What's the practical takeaway?
Ensure real eyeballs exist: funded security audits, dedicated reviewers, and reviewers with the right expertise. "Someone will catch it" only works if a competent someone actually engages with the code.
The Bottom Line
"Given enough eyeballs, all bugs are shallow" is true only when the eyeballs are expert, motivated, and actually looking, and Heartbleed showed what happens when they aren't. Visibility is not a security strategy. Whether your code is open or closed, quality comes from specific competent people reviewing it with enough time, so invest in the reviewers rather than trusting the crowd.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
