There will always be bugs, sure, but differences in the engineering approach can result in orders-of-magnitude differences in the frequency of bugs.
For example, see "Some thoughts on security after ten years of qmail 1.0," where the qmail author explained why he thought qmail had a dramatically different security track record than sendmail: http://cr.yp.to/qmail/qmailsec-20071101.pdf
The kind of things he's talking about can't just happen on the level of "more people submitting patches" and "more financial contributions." You need a top-down approach that's designed to produce secure code.
It was a stupid, "really? again?" type bug that is typical of low-level badly written C programs and a common cause of security vulnerabilities.
One large company I know has a technical review system which we use frequently to root cause failure and more importantly to update systems and workflows that will avoid the cockup being discussed in future. Blaming a team or oneself is not entertained (we don't care about the who), the important question is why and what can we do to fix it.
In my opinion, I think the OpenSSL team should come up with such a document and a list of corrective countermeasures.