Generalizations about whether open-source developers or closed-source source developers have more resources, or are more professional, or whatever, are silly. The two groups of developers are very large with high variance in many dimensions, and a lot of overlap. There are open-source projects with one or 2 developers, and open-source projects that are the primary focus of $100-million, thousand-employee companies. There are also closed-source commercial projects developed by teams of hundreds, and closed-source commercial projects developed by a solo programmer when he's not busy answering customers' phone calls. Lots of developers work on both open and closed-source projects at one time or another.<p>It's important to discuss what changes we can (and should) make to make problems like heartbleed less likely in the future, but wildly waving competing generalizations in the air doesn't help anything.
"you cannot expect a person working in academia to be held to the same standards as professionals working in the industry for many years"<p>This is absolutely BS, especially in security and cryptography. Most security related code written by most so-called "professional" software developers is astonishingly terrible (e.g. ECB mode encryption, storing encryption key in code, reusing encryption keys, relying on (unauthenticated) encryption for authenticity, reusing IVs, linear time MAC verification, ...). Most cryptographers are academics. Also, anecdotally, the poisonous "demo an exploit or it doesn't happen" attitude in response to hints at a flawed system design is much more prevalent among "professional software developers" than in academia.<p>If anything, we should encourage more security experts in academia to engage in implementation, verification, and improvement of security code, not the other way around.<p>(Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
It seems to me that the author of this piece has a lot of "misconceptions about Open Source" himself.<p>An example: "anyone can contribute, regardless of background or proficiency".
I'd encourage the author to research how open source projects are run before making claims like this.<p>Also.. How was this bug found again? Oh yeah. By analyzing the _open_ source code.<p>Professionalism is orthogonal to open source vs. closed source. There's a place for both, and there is good and bad open source and closed source software.<p>Moving right along nothing to see here.
Apple has all the resources, and they had the "goto fail". You should not underrate open source. Bugs are shallow, but that can never mean <i>every</i> single bug. Some bugs will always be overlooked, no matter if open source or closed source.
This is BS; the bug was found by people analyzing the <i>open-source</i> code because anyone can do so. Also, criticizing the developer because he's a PhD student makes zero sense; the two best developers I've known were a student and a 13-year-old.<p>I also love how the author puts a thinly-veiled plug of his slimy "open-source" code-selling website in the middle. As benatkin said in his excellent comment [0], all four of their featured products are closed-source. The OSI should sue them for violation of their trademark of the term "open source".<p>[0] <a href="https://news.ycombinator.com/item?id=7579700" rel="nofollow">https://news.ycombinator.com/item?id=7579700</a>
open source doesn't necessarily mean "anyone can edit it and improve it".<p>patches and added features need to be reviewed by project owners.<p>open source mostly mean "you can read the source and modify your version, but that doesn't mean you can make a change that will go into the official release."<p>There are some very sensitive implementations of software which should be thoroughly examined by experts and criticized if they're not good enough. If there is no resources available to maintain a particular open source software, don't bother use it, ESPECIALLY if it's sensitive like openssl.<p>Open source allows software companies and other programmers to easily work together to solve a problem. Developer's time is precious so it's often time-saving to use somebody's else work, but that doesn't mean you should use it blindly.
"every software has bug and opensource has less resources to look at it"<p>i'd rather say "and you just don't know about the closed source ones because they're harder to find" ;-)
There has been a lot of really insightful hindsight about the heartbeed issue. This one seems to fall into the category of "we should of expended more resources on such a critical piece of infrastructure", where resources could of been time, attention or money. That is true, but not really very helpful.<p>This particular observation comes up any time something goes wrong in any context. The stuff about the shallowness of bugs really has nothing to do with the argument. This bug was in fact quite shallow, some random entity just found it by looking. If more people had of been looking then it would of likely been found sooner. You can only find a bug once.
BinPress is misusing the term Open Source in their slogan. All four of their featured "Popular Products" are closed source. IMO <a href="http://opensource.org/" rel="nofollow">http://opensource.org/</a> should be suing them to protect their trademarks, because their use of the term is trying to piggyback on the popularity of the Open Source community that OSI represents.<p>So I don't think they are in a good position to be talking about the meaning of Open Source, as they're doing in this article.
"OpenSSL is used and run by millions of companies around the world, many of which have dedicated software engineers working for them full-time, while reaching hundreds of millions of users. And yet, this issue was undiscovered for almost 2 years"<p>This is almost a non-sequitor (Sp?). Almost none of those software engineers looked at the source (and those few that did got eye bleed).<p>I quit reading after that.
The main point, that more eyeballs doesn't necessarily lead to more bugs found and fixed, is a good one. Reading code, or text, specifically with the intent of finding errors is very hard, and is itself an error-prone activity. Anyone who has had to do close proof-reading knows this. It's hard work, so our brains are constantly fighting us and trying to "relax" back to a higher level of abstraction. That's one of the reasons I read the Coverity post with some interest. We humans are hopelessly ill-suited for these tasks, and we need all the help we can get.
> “Given enough eyeballs, all bugs are shallow” – Eric Raymond
> only obvious problems are easily caught. An issue that manifests itself only under very specific conditions or not in a way that is obvious to the end-user, can go undetected for a long time.<p>There are fundamental differences between bugs and security holes. Bugs are something everyone has an interest in fixing. If a bug rarely manifests itself - then it is not that much of a problem.<p>Security holes are things which some people scrupulously search for, and then sometimes keep secret, for their own ends. Sometimes people even try to create security holes where there are none ( <a href="http://lwn.net/Articles/57135" rel="nofollow">http://lwn.net/Articles/57135</a> ).
That's funny. When I make this <i>exact point</i> here on HackerNews I get downvoted to oblivion.<p>Open Source gives you potential to build a rocket to the moon. But it requires money and time and people willing to mind the code, and people with humble attitudes willing to accept when they've made mistakes and patch the code.<p>Quality Assurance requires effort, and that's where the fallacy of "Free" software really comes from. If you're not paying for it, you're going to pay for it. (Either by being the QE team and fixing bugs yourself or by living with buggy software.)
Binpress doesn't promote Open Source software as anyone else knows it. Binpress promotes proprietary software where licensees can see the source code and modify it privately. Binpress calls this "Open Source" although it lacks all the qualities that everyone else assumes with that term.<p>Thus, Binpress always looks to combine their one very <i>good</i> point (that better funding for Open Source is important) with a bunch of junk trying to say that buying their proprietary software is the answer.
OpenSSL, and the other security problems lately, are just the top of a rabbit hole that is only ultimately resolved with isolated special hardware. Frankly we shouldn't trust our systems, open or proprietary, on the very simple basis they are too complex to verify.<p>Only by moving crypto functions to a separate user maintainable black box will this tide ever be stemmed. Of course, verifying that black box then becomes problematic, but it would be easier than the current situation.
I've always interpreted Linus's law in the following way: given a bug, there will exist someone to whom the bug is obvious and will immediately spot it. However the law doesn't state how many people you would need to check, it might be 2 or it might be 100,000 required.
If openSSL was closed-source and a vulnerability was found in it, couldn't it have been patched without revealing what the issue was? This seems to be a big security issue with open-source.