The common mantra of open-source advocates, myself included, is that when the source code is available, the code is better. Transparency allows the code scrutiny. The nature of the open source community would, by definition, root out any bugs and security flaws which help improve the software. The recent Heartbleed bug of OpenSSL was a strong reminder of how wrong this assumption is.
Understanding Heartbeat - The Core of Heartbleed
When a HeartbeatRequest message is received and sending a HeartbeatResponse is not prohibited as described elsewhere in this document, the receiver MUST send a corresponding message carrying an exact copy of the payload of the received HeartbeatRequest.
The Heartbeat mechanism is a simple way do keeping connections alive even when there is no data being transmitted. The Heartbeat message is sent by a requester to a server containing a some random string and the length of that string. The server responds by sending back the exact message to the requester.
It's a very simple protocol, but there exists a tiny but critical flaw, the length of the message. By allowing the requester to state the message length, the Heartbeat protocol does not attempt to verify the length.
This comic by XKCD perfectly explains the issue.
So all someone needs to do is to specify the incorrect length and they are able to get the up to 64 kilobytes of data from the server. That's a lot of data from a security perspective especially since there's no limit to how many times you can request the heartbeat.
Once you realize how simple this bug is, it almost begs the question, why did it take so long to fix. The Heartbleed bug existed since OpenSSL version 1.0.1 was released on March 14th, 2012. Two years is a long time to exploit such a critical bug.
So were there any major security audits done? No.
And that's the current state of open source. Proper security audits costs real world money. The heart of the Heartbleed bug is less about the bug itself and more about funding. The OpenSSL project was founded in 1998 to create a free encryption tools. Currently almost two-thirds of all internet servers use it. At present the entire group consists of a single full-time employee and 10 volunteers. Funding is provided by donations and some consulting work by the OpenSSL Software Foundation. In a year this nets them less than $1 million, which is a small amount when you consider the overhead of maintaining servers for the world's most popular SSL protocol.
Commercial Open Source - The Pay Later Model
There are many options to commercialize open source and Wikipedia lists quite a few of them.
However, the one's that seem to be the most viable in the long term seems to be a "Pay Later" option that requires a paid contract with for-profit organizations after a specific time length. This means that the use of the software is permitted across all users, however if a for-profit organization is to continue using after a specified length of time, they will need to pay for it.
This ensures that the originating goals of open source are there, but by having a progressive revenue model allows the contributors to know that their work is not going to be used long term without compensation.