What evidence is there that there actually were "many eyes" on this code? If anything this underscores the importance of license compatibility in order to maximize the utility of the "many eyes" resource. Honestly, GnuTLS seems to exist purely for ideological shim reasons, and it's not surprising that ideological shim reasons don't motivate "many eyes" to bother show up.
That's a No True Scotsman argument. The problem with the "many eyes bugs shallow" theory is that all eyes aren't created equally, and the valuable eyes aren't distributed uniformly across all software.
It would only be a No-True-Scotsman argument if the original statement of Linus' Law were, "In an open-source project, all bugs are shallow" and someone were now trying to claim that GnuTLS wasn't open-sourcey enough.
In reality, the law is about code that has many eyeballs on it, and it's a fair argument to point out that evidence suggests GnuTLS didn't have that many eyeballs on it.
Can you present some of that evidence about the lack of eyeballs on GnuTLS? Because my point is that the right kind of eyeballs were not on GnuTLS; my point isn't compatible with this supposed "law".
So are you saying that GnuTLS had "valuable eyes" and missed this or that they had "many eyes" and missed this? What exactly is your alternate hypothesis?
So do you mean that (until now) they just failed to find them, or that (until now) they were only found by people who did not have the incentive to report these bugs?
Because in the top post you call the bug "simple and basic".
But then in that same top post you imply (in your last line) that GnuTLS gets so very little attention, but now you say that lots of people have tried to find bugs in it.
I'm not trying to criticize you here, but trying to figure out what you're trying to say?
That's part of the fallacy. In the OSS world it's assumed that when code passes through many hands, is depended upon by many projects, and is critical to the functioning of many systems used by many users then naturally the code in use will be seen by many eyes.
But this is anything but true. The reality is that code review is far less common than code use, with many defects impacting many users as the logical consequence.
> That's part of the fallacy. In the OSS world it's assumed that when code passes through many hands, is depended upon by many projects, and is critical to the functioning of many systems used by many users then naturally the code in use will be seen by many eyes.
Right and as you point out that's not true. What gets less attention is why. I know in my own code there are dependencies I know very, very well. Some of them I have helped to author. Some of them I have helped with regarding maintenance programming later. But there are many which I don't.
There are a bunch of reasons for this:
1. Code has varying degrees of readability and is easily comprehensible to various extents. Code which reads like a book gets more time than that which I have to figure out its structure first.
2. Code that is well maintained provides less necessity to add someone else. I tend to be more likely to read poorly maintained code than well maintained code, for example because bugs don't get fixed is a good reason to try to fix them myself....
