SSL has a good "OPEN SOURCE" license. The license guarantees continuity of the product and we contribute because the product will always be available to us. In contrast we may contribute to proprietary software and have our ideas capitalized and posessed - with no guarantee of access to the software or my input ideas in the future (read the "input agreement" when you talk to the vendor).
The GPL and other good licenses tend to protect us from arbitrary decisions by software companies. Such decisions can include complete cancellation of the product or no future bug fixes. So the real cost of committing to a software product tends to favor open source.
The statement "Most of the world's best newspapers and magazines struggle to survive while we swim in a sea of free news of questionable quality." is very revealing about the whole situation.
First, it's wishful thinking. The reason that those papers struggle to survive is that they forgot the difference between a real magazine and a tabloid and sacrificed quality factual reporting in favor of slanted sob stories that pull on the heartstrings of the illiterate. The demand for alternative news grew from the vaccuum they left, not from the difference in subscription rates.
Likewise, open source software isn't created by a demand for cheap software. Developers who work on these projects have valuable skills and it would cost far less for them to purchase commercial software -- if it met their needs, that is. The closed source companies created the need for alternatives by overselling and underdelivering, failure to listen to customers, and charging early adopters for the privilege of beta testing products released too early.
When people with the technical wherewithal to do it themselves decided that they had no choice but to do so, the natural thing to do would have been to recoup their investment by commercializing their competing solution. But they identified the commercial interests as the cause of the poor quality they were trying to overcome. That's why open source grew.
Now, of course, there's a lot of peer pressure toward open source and it no longer is solely the work of experts creating high quality products (although some still is).
But to blame open source for the struggles of "the world's best software vendors" is quite ridiculous. They caused their own struggles, by making building new wheels a better value proposition than buying them.
Open Source Community was originally started by the academician against the price hikes and constant charging mechanism of the paid software's, the original view behind this was to provide minimal functionality of the software at no cost to the user. But later on the paid alternatives go on putting the additional features and functionalities and continue attracting the users for it, the corporate world were ready to pay for it, this was the users were in constant need of feature rich software, but for open source community it will not be possible to survive providing constant improvements in the software's, this led to use the shareware and in turn malwares along with it. There are many group who are trying to make money by selling the ads via open source software's and this had bring down the quality of the open source software's.
The discussion about open vs. proprietary is important, but too general for the Heartbleed bug.
Security software is a special case. Its requirements are different. Its testing is (or should be!) different.
Most bugs are failures that get in the way of the end-user; they get reported and fixed as a consequence. The end-users have become beta testers (for good or for ill, but that's a separate discussion).
But security software has a second set of requirements: no leak of information. How is this going to be tested? The "end-users" doing this kind of "testing" have no incentive to come forward. Programmers using the library will not even notice unless the interface is broken.
A vendor of proprietary software has a clearer incentive to spend programmer cycles attacking his own software. In addition, the visibility of bugs is lower, and their scope (who is using the buggy software) is generally more restricted.
Who has the incentive to do the "black-hat" testing of security software? Open source does not provide a crisp answer to this question. IMO, that's where the discussion should focus.
Confusion over what open software does and does not do well is widespread and seems to be related to what the word "open" means.
1. Looking at open software it is possible to see "the tragedy of the commons." This is an economic theory stating that individuals acting independently and rationally according to each one's self-interest, behave contrary to the whole group's long-term best interests by depleting some common resource ( http://en.wikipedia.org/wiki/Tragedy_of_the_commons ). This, as I understand it, is what Rick Merrett alludes to. This economic theory applies more to the users of open (as in free) software, than the developers, in the Heartbleed case.
2. The "best" security system is the one still providing protection after the strongest attacks. The assumption here is that software attacks are stronger when the source code is known. I don't have a reference for this aphorism other than common sense. In the case of security, the subject of other comments in support of Open SSL, it seems clear that open source software (a different type of open) is an advantage not a disadvantage.
To sum this up: An economic approach (not discovered) that allowed the profitable sale of open source software might be beneficial. One alternative to such an economic approach is taxation. This is how the police (another form of security) are usually financed. Interestingly, the open software environment might be where to attempt a commercial form of taxation. This suggests a new form of software license administered by an "open software group".
The foundation of Internet is build on Open Sources. The OS is Linux. The webserver is either Apache or others open source webservers. Database engine is MySQL or other NoSQL DB. gcc is free. php is free. perl and python are all free. The core of today's networking, TCP/IP stack including DNS are all from open source. I have no doubt that we would never be where we are today without the contribution of open sources. To make an open source project to be successful, widely adopted, isn't a trivial task. The instance of the OpenSSL bug is just one small bug that causes a huge problem. I agree with a lot of other people that given the time of OpenSSL, the developers have done an amazing job to keep it from bugs.
I like that the author is asking questions. I think we need to remember not to generalize Open or Closed Source too much, and being biggoted won't help us.
Lots of Open Source doesn't mature to anything useful. Have you perused SourceForge or the like for something new and useful? It's often an exercise in frustration: searching through countless dead, half-baked projects. Quality of code varies in successful and unsuccessful projects alike.
There are an amazing number of very successful Open Source projects. I include OpenSSL in this pool. It's amazing that we haven't experienced more flaws in OpenSSL in the _many_ years we've all been using it. Compare its record to any Open or Closed technology and it will fare well.
I've used OpenSSL to build many comercial products as a Software Develoer and the quality of the OpenSSL code was arguably better than much of the surrounding proprietary code.
I don't believe in perfect code. High quality code does exist. Maybe this incident will reinvigorate us to invest the time and money to make OpenSSL even better than it is today? There aren't many projects of equal importance in the Open or Closed Source ecosystem. It's a fundamental building block of our Internet.
If this problem were to have happened in a closed source library, it would have taken a report to the vendor, and time for them to priortize the problem, debug it, run it through channels and figure out how to spin the problem to not be their fault, or minimize it, and then schedule a release to contain it.
Since the problem was open source, the code was looked at, and someone other than the vendor was able to find the problem, and the fix was made available. No spin, no wait for the release, just the fix.
I have often wondered about the risks of open source software with regard to security for the Internet. In particular, the Internet of Things.
I have scheduled a live chat on this topic for Wednesday the 23rd at 8am Pacific time. Like EETimes, you have to be registered on the IoT World site to post, but you can come "listen in" without registration as well.
As a special guest, Dave Hughes of HCC, a security middleware provider, will join in to talk about the role of commercial software in security for the IoT.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.