4 ms·

Rubbish in point b. I've scratched plenty of itches working on proprietary software that did not come from product management.

by buerkle 12y ago

jordigh 12y ago
Agreed, the open source ideology as explained by esr says a bunch of things that are demonstrably not true, suggesting that proprietary software is an inferior way to develop software or that proprietary software just will have more bugs because fewer people can read its source code (yo, heartbleed!) Although the development model seems to more or less work for Linux because all of the corporate backing it has, despite being free, there are a lot of adages that esr started that sound like broken promises to me.
- stormbrew 12y ago
  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.
- icebraining 12y ago
  Heartbleed? You mean, the bug that was discovered because the source was available to unaffiliated third-parties?
  - jordigh 12y ago
    It is not clear how the bug was discovered. If it was because someone was reading the source code, it still took a long time for someone to read that part of the source code, so I don't think someone was backlogged with code reviews by two years. I think it is far more likely that someone first realised they were getting extra data and then went to read the source code to see why this was happening. I think it's safe to speculate that most bugs are discovered by inspecting the behaviour of the software, not by reading the source code. Of course, once the bug is found, having the source code makes it much easier to patch it, but it's amazing what people can do to patch bugs even without source code.
    - icebraining 12y ago
      I think it's perfectly clear. In the end of January, Google releases a design draft detailing how they are switching Chrome from NSS to OpenSSL[1]. Two months later, some Google employees announce they have found a major bug. I don't have any inside knowledge, but I think the causality chain is obvious - they did a security review of the code as part of the switch and found it. [1] https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1#heading=h.mi4wjwv8kmze https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...

Rubbish in point b. I've scratched plenty of itches working on proprietary software that did not come from product management.

by buerkle 12y ago

Rubbish in point b. I've scratched plenty of itches working on proprietary software that did not come from product management.

jordigh 12y ago

Agreed, the open source ideology as explained by esr says a bunch of things that are demonstrably not true, suggesting that proprietary software is an inferior way to develop software or that proprietary software just will have more bugs because fewer people can read its source code (yo, heartbleed!) Although the development model seems to more or less work for Linux because all of the corporate backing it has, despite being free, there are a lot of adages that esr started that sound like broken promises to me.

stormbrew 12y ago
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.
icebraining 12y ago
Heartbleed? You mean, the bug that was discovered because the source was available to unaffiliated third-parties?
- jordigh 12y ago
  It is not clear how the bug was discovered. If it was because someone was reading the source code, it still took a long time for someone to read that part of the source code, so I don't think someone was backlogged with code reviews by two years. I think it is far more likely that someone first realised they were getting extra data and then went to read the source code to see why this was happening. I think it's safe to speculate that most bugs are discovered by inspecting the behaviour of the software, not by reading the source code. Of course, once the bug is found, having the source code makes it much easier to patch it, but it's amazing what people can do to patch bugs even without source code.
  - icebraining 12y ago
    I think it's perfectly clear. In the end of January, Google releases a design draft detailing how they are switching Chrome from NSS to OpenSSL[1]. Two months later, some Google employees announce they have found a major bug. I don't have any inside knowledge, but I think the causality chain is obvious - they did a security review of the code as part of the switch and found it. [1] https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1#heading=h.mi4wjwv8kmze https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...