Nobody questions that OpenSSL is a vital part of the Internet's infrastructure. So many fundamentals are built on top of it and in so many places. Too much is at stake for it to be vulnerable to yet another Heartbleed, the dangers of which may linger for some time in embedded and client devices.
That's why the efforts, plural, to fix OpenSSL and make it more maintainable are so heartening. But having three such projects in the works, all operating in parallel, may be the wrong kind of plurality.
OpenSSL, originally maintained by a very small crew of developers only minimally compensated for their work, has been criticized for many reasons: too slow to respond to problems, too poorly coded to be robust. That last point was open source developer Marco Peereboom's contention when he flat-out stated, "OpenSSL is written by monkeys." Its oddball licensing model has also drawn a lot of fire, giving potential contributors pause.
Other groups have rallied to also give the OpenSSL team a hand. The CII (Core Infrastructure Initiative), a consortium organized by the Linux Foundation and backed by a slew of major tech companies, has pledged various kinds of support to OpenSSL. That could prove to be the most direct way to fix the problems, given how deeply entrenched (and difficult to disentangle) OpenSSL is in many projects and environments.
But at least two other alternatives have also arisen. One, provisionally known as BoringSSL, comes from Google. The company is a CII member, but BoringSSL isn't intended to replace OpenSSL so much as flank it. Really, its goal is to make things simple for Google, so it can keep an easily maintained version of the project primarily for its own use in Google Chrome/Chromium and Android.
Consequently, BoringSSL isn't intended as a drop-in replacement for OpenSSL in existing projects. Rather, it's meant to provide an environment where (as one of its developers wrote) changes can be imported from OpenSSL rather than rebased on top of them. Bug fixes will be sent back from BoringSSL to the OpenSSL team, but the sheer complexity of OpenSSL all but guarantees that the majority of the original code -- whose sprawl has been implicated as one reason for its issues -- will remain untouched.
On top of all this is a third project, a near-complete rewrite called LibreSSL spearheaded by developers from the OpenBSD project. Many aspects of it are positive: It discards much of the legacy code in OpenSSL (such as support for older, less-used operating systems), and it's available under a standard set of open source licenses. But the project's main focus is to deliver a solution to be used in OpenBSD first, with other operating systems to follow. Thus, a version that would be of broad use to other operating systems -- and of high quality -- is a ways off.
The most troubling part about these three separate, if interrelated, projects is how they hint at the difficulty in replacing or fixing OpenSSL. While LibreSSL is meant to be API-compatible with OpenSSL, OpenSSL's own API has been criticized as a major source of problems -- and BoringSSL isn't intended as a one-for-one replacement in the first place. That leaves the original team, with support from the CII, as the ones most in the position to do the right thing.
The open source way isn't to blame here. Like devops or test-driven development, open source and its associated practices constitute a powerful tool set for creating software. The real issue is in the way so much dependency on so many levels was built on top of a code library assumed to be everything it needed to be.
[Addendum: On July 11, 2014, the first release of LibreSSL was produced for platforms other than OpenBSD, although it's only "an initial release to allow the community to start using and providing feedback."]
This story, "Too many cooks may worsen the OpenSSL mess," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.