3 ms·

I remember reading his essays (there were several more) and thinking, "He is seems so sure of everything, let's see how it plays out". He wasn't completely wro

I remember reading his essays (there were several more) and thinking, "He is seems so sure of everything, let's see how it plays out". He wasn't completely wrong about everything, but the main premise - that careful planning and development yields worse results than guerilla ("bazaar") way of working - didn't pass the test of time. His main argument was the Linux kernel. But when you look at this project now, it seems quite far from the bazaar style. There are many bazaar-style projects that failed and many cathedral-style projects that do very well. So his main argument is moot. We can treat this essay as a historical document, not something anyone should refer to as to how the open source development should be done (even though he has some good points about leadership style for example).

segfaultbuserr 6y ago
> 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.
- tptacek 6y ago
  The "law" isn't that "all crashers are shallow". That would be a silly law, because you don't need many eyes at all to notice crashers.
  - db48x 6y ago
    Actually, you do, especially in the kernel. No one person could ever replicate all the crazy combinations of hardware, software, and usage that people need.

segfaultbuserr 6y ago

> 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.

tptacek 6y ago
The "law" isn't that "all crashers are shallow". That would be a silly law, because you don't need many eyes at all to notice crashers.
- db48x 6y ago
  Actually, you do, especially in the kernel. No one person could ever replicate all the crazy combinations of hardware, software, and usage that people need.