I remember so many people in the open source world angry or annoyed with the OpenBSD team for forking LibreSSL. The fact is it's more than a year later, several more high-risk vulnerabilities discovered, and OpenSSL has yet to make any noticable changes. Meanwhile those same vulnerabilities were fixed in LibreSSL due to code cleanup and removal.[1]
No matter how you feel about the forking or the openbsd team, there is something to be learned here. There are times when forking, deleting old code, and major clean-ups can be very useful strategies. Sunk cost bias can be an enemy of progress.
I'm curious what circles you run in in the open source world. In my little corner of it, most everyone had nothing but excitement and support for LibreSSL.
I was employed at a large open-source organization at the time of the fork. A conversation I participated in was specifically along the lines of (broad paraphrasing here) "They should be contributing their changes back to OpenSSL versus forking".
While attending a security conference in Vancouver earlier this year, someone commented that they thought the OpenBSD team was childish for forking LibreSSL, and several people chimed in with agreement.
Of course this is all hear-say for you, and your experiences may vary. I've met more than a handful of people who did not like the fork. There are lots of people in the world, and they all have different opinions.
> "They should be contributing their changes back to OpenSSL versus forking".
I suppose that this attitude comes from people who think the fork happened solely because of Heartbleed, when the real reasons are a little more intricate[0] but the straw that broke the camels back was the discovery that OpenSSL had known about certain bugs and let patches to fix them rot in their bug tracker for years. It's hard to contribute changes back when a project won't take patches.
OpenSSL could have taken LibreSSL's changes if they wanted to, it's all public in the OpenBSD source tree, but they haven't.
One of the big things they did was cut out enormous amounts of legacy code. Code that someone somewhere might be using. Since they were basically just making LibreSSL for themselves they didn't have to care about that and could be much more free with the changes.
The OpenSSL developers would have a much tougher time dropping MSDOS and VMS and OS/360 support because there are still a couple of people who need it.
They didn't make it 'just' for themselves - it supports Windows, Linux and and Mac OS X on various (modern) architecture also.
I think at some point, if you've got a legacy application running on such an old platform, the cost of maintaining your own fork of libraries like OpenSSL has to fall on you eventually.
Although OpenSSL themselves continuing to maintain these ancient ports is admirable in a way, the unmaintainability it has caused to the code base as a whole is a serious problem that has reduced security for everyone.
Having spent years working with openssl code, there's nothing you can do to save it but take a rusty axe to it.
Every horrifying thing in there is justifiable because "someone might be using it". Not enough reason to risk the security of every net-connected Unix over.
So, forking is pretty much the only way to do proper code cleanup in a timely fashion, right?
If you don't, people still clamor for legacy support and bug-for-bug compatibility. A fork is the only way of truly signalling "We aren't going to support our old mistakes anymore."
New features don't need forks, but cleaning up raging stupid and cruft does.
IMHO, there is a time an place for everything. Sometimes forking is a good idea sometimes not.
When you want to make idealogcal changes to an existing codebase that does not mesh with the idealologies of the maintainer(s), forking is a great way to make your changes happen. Time will tell if your ideas were good ones. That and how well your maintain and promote your fork. :-)
In the case of OpenSSL vs LibreSSL, it appears the OpenBSD team made a great call and they are making it work really well. As for if anyone else agrees and adopts it, only time will tell.
I do seem to recall some complaining about the tone the OpenBSD developers used, but they where not really getting anywhere by being nice either. Also some complaining about them not helping to fix OpenSSL instead.
I can only echo your sentiments. There seemed to be some skepticism about their attitude (what with the Comic Sans thing :)), but everyone in my circles at least respects the OpenBSD team's technical competence.
I recall a lot of renewed energy a year ago into improving OpenSSL, including funding and support. Has that panned out as I would have hoped? LibreSSL improvements are highly visible (and exciting) but I expect I would have overlooked any OpenSSL improvements.
There has been a whole bunch of changes and cleanups in OpenSSL, it's just stuff like that doesn't seem to pick up as much traction here (they don't really have the blogging / communicating thing down so well, I guess?)
This is the current roadmap. https://www.openssl.org/policies/roadmap.html
Picking out a few highlights:
* "Objective met (2015): The FIPS code has been removed from the master branch, and will be re-integrated more cleanly during a future validation. "
* "Objective met (2015): All use of dynamic memory allocation has been cleaned up and made consistent, and the internal memory pool has been removed. "
Under Coding Style:
* "Objective met (2015): All release branches were reformatted using a script included in the release." (so all code now adheres to a consistent style at least, which is a good starting point)
And amongst their targeted goals now:
* Legacy platforms that are unlikely to have wide deployment will be removed from the code.
.. but ..
* Non-supported platforms requiring regular maintenance activities will eventually be removed from the code after first seeking community owners to support the platforms in platform specific repositories.
Not convinced that's necessarily the right route, but I can appreciate where they're coming from.
No matter how you feel about the forking or the openbsd team, there is something to be learned here. There are times when forking, deleting old code, and major clean-ups can be very useful strategies. Sunk cost bias can be an enemy of progress.
[1] - https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...