3 ms·

Some context for those who are unaware: fetchmail was written by the same person (Eric S Raymond/ESR) as the "Cathedral and the Bazaar" essay.

freedomben 6y ago
If you have any interest in open source development (which these days we all should given that 95% of the lower parts of our stack are open source projects) it's well worth reading the essay/book. If you don't want to do that, at least read the wikipedia page: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
- segfaultbuserr 6y ago
  I found this interesting post while reading some historical documents, so I submitted it to HN. It seems that most people have missed the point. I think the point is: while The Cathedral and the Bazaar was a good campaign pamphlet and a general overview of FOSS development, but ESR's attempt of using his fetchmail as an example was arguably the greatest flaw of the book ("to such an extent that it could damage the Open Source movement"). From a technical perspective, fetchmail had numerous problems and security vulnerabilities. ESR was also criticized for mismanaging the project by putting it in "maintenance mode" early and refusing to accept patches that could address those issues. After a group of new maintainers had taken over the project, one of the first things they did was to systematically eliminate countless buffer and integer overflows from the program.
- tptacek 6y ago
  Not really. I read it when it came out and remembered liking it (we were all on kind of a buzz about open source and Linux at the time) and then again much more recently for a thread on HN, and I found it to be mostly a rehash of other, better material --- Brooks and Kernighan, in particular. That, plus the modern context that what he was writing about was Fetchmail, and Fetchmail as it turns out is hot garbage, to me makes the whole thing very skippable. It's also responsible for hatching one of the great canards of open source, "Linus's Law" (I'm sure Linus is thrilled with having his name attached to that), "many eyes make all bugs shallow", which has in the last 10 years become one of the great jokes of computer science.
  - dvfjsdhgfv 6y ago
    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.

freedomben 6y ago

If you have any interest in open source development (which these days we all should given that 95% of the lower parts of our stack are open source projects) it's well worth reading the essay/book. If you don't want to do that, at least read the wikipedia page: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

segfaultbuserr 6y ago
I found this interesting post while reading some historical documents, so I submitted it to HN. It seems that most people have missed the point. I think the point is: while The Cathedral and the Bazaar was a good campaign pamphlet and a general overview of FOSS development, but ESR's attempt of using his fetchmail as an example was arguably the greatest flaw of the book ("to such an extent that it could damage the Open Source movement"). From a technical perspective, fetchmail had numerous problems and security vulnerabilities. ESR was also criticized for mismanaging the project by putting it in "maintenance mode" early and refusing to accept patches that could address those issues. After a group of new maintainers had taken over the project, one of the first things they did was to systematically eliminate countless buffer and integer overflows from the program.
tptacek 6y ago
Not really. I read it when it came out and remembered liking it (we were all on kind of a buzz about open source and Linux at the time) and then again much more recently for a thread on HN, and I found it to be mostly a rehash of other, better material --- Brooks and Kernighan, in particular. That, plus the modern context that what he was writing about was Fetchmail, and Fetchmail as it turns out is hot garbage, to me makes the whole thing very skippable. It's also responsible for hatching one of the great canards of open source, "Linus's Law" (I'm sure Linus is thrilled with having his name attached to that), "many eyes make all bugs shallow", which has in the last 10 years become one of the great jokes of computer science.
- dvfjsdhgfv 6y ago
  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.