3 ms·

Ok, so the thing where heartbleed 'disproves' the many eyes theory has really got to stop, especially when used like a mallet as it is here. Many eyes has dimin

Ok, so the thing where heartbleed 'disproves' the many eyes theory has really got to stop, especially when used like a mallet as it is here. Many eyes has diminishing returns, but that doesn't mean that it isn't effective to a point. Bugs of similar scope have existed in proprietary software as long or longer, and have often even been deliberately placed as backdoors. Not to say that many eyes has been proven either, but you're going to need something a lot more solid than heartbleed to assert that it's demonstrably untrue that proprietary software has more bugs because fewer people read it.

Gracana 12y ago
I always figured that meant "given a difficult bug, a group of developers working on it will make it easier to solve." Not "with enough developers, all the bugs in this software will disappear."
jordigh 12y ago
The way esr created the open source movement, he made it sound as if open source was a superior way to ensure fewer bugs in software. This is not demonstrably not true: proprietary software developers are not incompetent, and just because you have visible source does not mean anyone is going to read it, or indeed, that you will get more people reading it than if you have a paid team of developers reading it. There are many, many proprietary packages that are far less buggy than free alternatives [citation needed]. TCATB just promises but doesn't deliver. There are reasons to value free software, but practical reasons as "a better development model" or that it produces better software are hard to justify.
- comex 12y ago
  I haven't read esr, but I disagree with your categorical statement that "producing better software" is hard to justify. (In other words, I agree with your first paragraph's statement that open source's superiority is not demonstrably not true.) In my experience, if you look at the big ticket projects, there are many proprietary packages that are less buggy than free alternatives, and many which are more buggy, and it mostly depends on the project's development process and history. For example, OpenSSL and gdb are very buggy mainly because they're terrible code, while Linux and OpenBSD are in general fairly stable because their development processes are good and in turn have made the code good. gcc and Clang beat MSVC++, Chrome beats Internet Explorer, because Microsoft doesn't care enough; Photoshop handily beats GIMP because it's Photoshop. And so on. But in my humble opinion, if you average over _all_ the software... including a lot of little projects that seem to end up with higher quality code, if only because the author was too embarrassed to release low quality code, and perhaps with the help of a few bug reports on GitHub... including medium-size projects which someone else took over maintainership over after the original quit, which would be impossible with proprietary software... including lots of low-quality proprietary NIH code where the default open source solution would be to use some already well-tested external code... open source wins by a significant margin. I am not sure this is inevitable or even correct, as proprietary software certainly has significant advantages, but I do not think it is reasonable to say it is demonstrably false.

Gracana 12y ago

I always figured that meant "given a difficult bug, a group of developers working on it will make it easier to solve." Not "with enough developers, all the bugs in this software will disappear."

jordigh 12y ago

The way esr created the open source movement, he made it sound as if open source was a superior way to ensure fewer bugs in software. This is not demonstrably not true: proprietary software developers are not incompetent, and just because you have visible source does not mean anyone is going to read it, or indeed, that you will get more people reading it than if you have a paid team of developers reading it. There are many, many proprietary packages that are far less buggy than free alternatives [citation needed]. TCATB just promises but doesn't deliver. There are reasons to value free software, but practical reasons as "a better development model" or that it produces better software are hard to justify.

comex 12y ago
I haven't read esr, but I disagree with your categorical statement that "producing better software" is hard to justify. (In other words, I agree with your first paragraph's statement that open source's superiority is not demonstrably not true.) In my experience, if you look at the big ticket projects, there are many proprietary packages that are less buggy than free alternatives, and many which are more buggy, and it mostly depends on the project's development process and history. For example, OpenSSL and gdb are very buggy mainly because they're terrible code, while Linux and OpenBSD are in general fairly stable because their development processes are good and in turn have made the code good. gcc and Clang beat MSVC++, Chrome beats Internet Explorer, because Microsoft doesn't care enough; Photoshop handily beats GIMP because it's Photoshop. And so on. But in my humble opinion, if you average over _all_ the software... including a lot of little projects that seem to end up with higher quality code, if only because the author was too embarrassed to release low quality code, and perhaps with the help of a few bug reports on GitHub... including medium-size projects which someone else took over maintainership over after the original quit, which would be impossible with proprietary software... including lots of low-quality proprietary NIH code where the default open source solution would be to use some already well-tested external code... open source wins by a significant margin. I am not sure this is inevitable or even correct, as proprietary software certainly has significant advantages, but I do not think it is reasonable to say it is demonstrably false.