5 ms·

I don't think "bugs are shallow", or the "many eyeballs" section of this essay, are particularly talking about _discovering_ bugs. The author seems to have had

I don't think "bugs are shallow", or the "many eyeballs" section of this essay, are particularly talking about _discovering_ bugs. The author seems to have had a worldview in which bugs don't really matter if people aren't coming across them, and in which the difficult part of dealing with a bug is either reproducing it or getting from a symptom to a cause. If you were in a world where those two things are true then I think he's probably right that "many eyeballs" would help a great deal.

tptacek 3y ago
It's not interesting to say that lots of interesting eyeballs are helpful. Anybody would have said that prior to this article's publication. Raymond makes a much stronger claim (which is why it has the force of "law"), and it hasn't borne out.
- mjw1007 3y ago
  Again: the purported law says "shallow", not "soon discovered".
  - tptacek 3y ago
    No, you can't get away with this semantic dodge, because Raymond numbered what he believed were the most important lessons he was imparting, and the one corresponding to Linus' Law is: 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. He even attempted an axiomatic explanation: Maybe it shouldn't have been such a surprise, at that. Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect. It appears that what Linus has shown is that this applies even to debugging an operating system—that the Delphi effect can tame development complexity even at the complexity level of an OS kernel.
    - mjw1007 3y ago
      Well, I'm baffled then. From where I'm sitting that point 8 is clearly talking about what happens after a bug is discovered, and not about discovering bugs. The longer paragraph doesn't seem to contradict the notion either. My impression (based on the "How Many Eyeballs Tame Complexity" chapter) is that Raymond thought that "debugging" means "fixing bugs". If I were criticising this part of essay, I'd say the main weakness is that the things Raymond thought of as "taming complexity" weren't really addressing the hard problem of reducing the number of bugs.
      - anamexis 3y ago
        "Characterizing problems" reads to me like "discovering bugs," particularly given that he specifically mentions having lots of beta users.
      - doctor_eval 3y ago
        As I mention upthread, a lot of the talk at the time was about overall quality of the software. So an interpretation that the total number of bugs (known and unknown) would be reduced is well aligned with this outlook. If the objective is just to fix bugs that have been found, well, that doesn't really feed into this narrative. Also, ESR was making many claims about the efficacy of OSS, and limiting the scope to bugs already discovered would not really align with the rest of the goings-on at the time.
    - phkahler 3y ago
      >> Given a large enough beta-tester and co-developer base... That's a qualifier for what follows it. Seems true enough to me. If there are enough developers to notice bugs, they will probably be found and fixed quickly.
      - emodendroket 3y ago
        The argument here is that the pool of "developers" is essentially unlimited for open-source software. In principle I suppose that's indisputable, but in practice is it true?
  - coldtea 3y ago
    If they're not "soon discovered" then the use of the term "shallow" means absolutely nothing...
  - DonHopkins 3y ago
    Wow, what an impressive display of rhetorical gymnastics! It shows such fanatical dedication to the cause of carrying ESR's water. If you're up to it, I'd love to see you also have a go at rationalizing how his own words that I quoted aren't at all racist. https://news.ycombinator.com/item?id=35943008 https://news.ycombinator.com/item?id=35943008
- jasmer 3y ago
  It's interesting to say 'a lot of eyeballs will do something' in a world where nobody believed it. I think this thread overstates the reality of the very, very crude metaphor that illustrates 'why open source can work' - even if it is very flawed. I think by now we all kind of know 'it depends' aka there's context to everything.
- colinsane 3y ago
  if your process is “release often, but preserve quality by a staged release process (betas) in which power users can fix bugs before they reach the masses” then you’re pretty explicitly allowing bugs to be in the codebase transiently. combine that with projects of this era shipping with files like BUGS or ISSUES alongside their README or NEWS/release notes, and you have strong evidence that “transient” means “can knowingly be included in a release”. at that point it just feels false to read ESR as claiming anything strong like “with enough eyes the software will contain no latent bugs” (which i think is how one side of this thread is interpreting the essay?)
  - deleted 3y ago
    [deleted]
pwdisswordfishc 3y ago
> The author seems to have had a worldview in which bugs don't really matter That would explain so much… https://gitlab.com/esr/gif2png/-/commit/a8a761561b2a071e7452a00868efd5bdf795c443 https://gitlab.com/esr/gif2png/-/commit/a8a761561b2a071e7452...
- DonHopkins 3y ago
  I don't think ESR would appreciate the irony of you directing many eyeballs to his carelessly bug-ridden code.

tptacek 3y ago

It's not interesting to say that lots of interesting eyeballs are helpful. Anybody would have said that prior to this article's publication. Raymond makes a much stronger claim (which is why it has the force of "law"), and it hasn't borne out.

mjw1007 3y ago
Again: the purported law says "shallow", not "soon discovered".
- tptacek 3y ago
  No, you can't get away with this semantic dodge, because Raymond numbered what he believed were the most important lessons he was imparting, and the one corresponding to Linus' Law is: 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. He even attempted an axiomatic explanation: Maybe it shouldn't have been such a surprise, at that. Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect. It appears that what Linus has shown is that this applies even to debugging an operating system—that the Delphi effect can tame development complexity even at the complexity level of an OS kernel.
  - mjw1007 3y ago
    Well, I'm baffled then. From where I'm sitting that point 8 is clearly talking about what happens after a bug is discovered, and not about discovering bugs. The longer paragraph doesn't seem to contradict the notion either. My impression (based on the "How Many Eyeballs Tame Complexity" chapter) is that Raymond thought that "debugging" means "fixing bugs". If I were criticising this part of essay, I'd say the main weakness is that the things Raymond thought of as "taming complexity" weren't really addressing the hard problem of reducing the number of bugs.
    - anamexis 3y ago
      "Characterizing problems" reads to me like "discovering bugs," particularly given that he specifically mentions having lots of beta users.
    - doctor_eval 3y ago
      As I mention upthread, a lot of the talk at the time was about overall quality of the software. So an interpretation that the total number of bugs (known and unknown) would be reduced is well aligned with this outlook. If the objective is just to fix bugs that have been found, well, that doesn't really feed into this narrative. Also, ESR was making many claims about the efficacy of OSS, and limiting the scope to bugs already discovered would not really align with the rest of the goings-on at the time.
  - phkahler 3y ago
    >> Given a large enough beta-tester and co-developer base... That's a qualifier for what follows it. Seems true enough to me. If there are enough developers to notice bugs, they will probably be found and fixed quickly.
    - emodendroket 3y ago
      The argument here is that the pool of "developers" is essentially unlimited for open-source software. In principle I suppose that's indisputable, but in practice is it true?
- coldtea 3y ago
  If they're not "soon discovered" then the use of the term "shallow" means absolutely nothing...
- DonHopkins 3y ago
  Wow, what an impressive display of rhetorical gymnastics! It shows such fanatical dedication to the cause of carrying ESR's water. If you're up to it, I'd love to see you also have a go at rationalizing how his own words that I quoted aren't at all racist. https://news.ycombinator.com/item?id=35943008 https://news.ycombinator.com/item?id=35943008
jasmer 3y ago
It's interesting to say 'a lot of eyeballs will do something' in a world where nobody believed it. I think this thread overstates the reality of the very, very crude metaphor that illustrates 'why open source can work' - even if it is very flawed. I think by now we all kind of know 'it depends' aka there's context to everything.
colinsane 3y ago
if your process is “release often, but preserve quality by a staged release process (betas) in which power users can fix bugs before they reach the masses” then you’re pretty explicitly allowing bugs to be in the codebase transiently. combine that with projects of this era shipping with files like BUGS or ISSUES alongside their README or NEWS/release notes, and you have strong evidence that “transient” means “can knowingly be included in a release”. at that point it just feels false to read ESR as claiming anything strong like “with enough eyes the software will contain no latent bugs” (which i think is how one side of this thread is interpreting the essay?)
- deleted 3y ago
  [deleted]

pwdisswordfishc 3y ago

> The author seems to have had a worldview in which bugs don't really matter That would explain so much… https://gitlab.com/esr/gif2png/-/commit/a8a761561b2a071e7452a00868efd5bdf795c443 https://gitlab.com/esr/gif2png/-/commit/a8a761561b2a071e7452...

DonHopkins 3y ago
I don't think ESR would appreciate the irony of you directing many eyeballs to his carelessly bug-ridden code.