> We can treat this essay as a historical document It's why I'm rereading this book today. One thing I've been thinking about since morning was ESR's "Linus L

> We can treat this essay as a historical document It's why I'm rereading this book today. One thing I've been thinking about since morning was ESR's "Linus Law", "given enough eyeballs, all bugs are shallow". Today the idea is heavily criticized. The very existence of fetchmail by the author was a counterpoint - the code quality was below average, it had numerous security vulnerabilities, and arguably basing the whole book on fetchmail is the book's greatest flaw (not to say the criticisms of ESR's personal qualification from many hackers). But if you read the original context... > Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this: Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. The original context was strictly about beta-testing - about how the Linux kernel didn't collapse on its own weight despite the lack of a BSD-style "core" team and heavily scrutinized release. Instead, it achieved system stability with the help from a large number of beta-testers and co-developers who are willing to run on the bleeding edge. It's still how the kernel and the majority of the FOSS world. "Build today's git snapshot and see whether it explodes" can be quite effective. Then ESR simplified it to... > Or, less formally, "Given enough eyeballs, all bugs are shallow." And now it means "people can find all bugs, because there are always a lot of eyeballs to read the source code". Now it can refer to all sorts of things beyond its scope. It is a serious mistake. Notably, security vulnerabilities are different - it usually does not have any user-visible effects and can only be triggered by carefully crafted malicious inputs, not normal uses. This is the reason it doesn't work for security. Thus, maybe a more accurate reflection of this rule could be: Given enough eyeballs, all user-visible bugs (e.g. crashes) are shallow. At the end of the day, my conclusion was: Perhaps "Linus Law" was not as wrong as it seemed. ESR simply misinterpreted his observations.