The OpenSSL strategy seems to be to try to leapfrog LibreSSL in terms of version numbers (which already has released a 2.x branch, hence their 3.x versioning), and revise their API, but still have considerable complexity.
The LibreSSL approach was to write a new library and API, libtls, which does away with the substantial configuration complexity in applications: https://man.openbsd.org/tls_init.3
It is supremely unlikely Akamai (via Rich Salz who is leading and has led a lot of post heartbleed fixup) take libressl seriously at all nor do any other large contributing company. People in the FreeBSD community knew libressl would be a flash in the pan given the personalities involved and FreeBSD has legitimate large scale commercial usage.
OpenVPN also disclaims any interoperability with LibreSSL.
"Please note that LibreSSL is not a supported crypto backend. We accept patches and we do test on OpenBSD 6.0 which comes with LibreSSL, but if newer versions of LIbreSSL break API compatibility we do not take responsibility to fix that."
The Core will implement a property based look-up feature for finding algorithms, e.g. it might allow you find an algorithm where "fips=true", or "keysize=128, constant_time=true".
Why? What designer builds a system this way, without knowing precisely what algorithm they're using?
Strange that with the bump to 3.0 they didn’t at least announce the removal legacy primitives and TLS versions. Are they going to support DES and RC4 forever?
It might not be the exact use-case for OpenSSL but there's plenty of existing content or protocols using those algorithms, which no one is going to bother changing ("encrypted" PDFs come to mind).
In any case not having RC4 isn't such a big deal; it's a tiny algorithm you could literally memorise and write into where it's needed (which I suspect is why it became so popular.) DES is a bit trickier though.
Let PDF readers find their own DES library. Or at lest make its non-default part of the build.
But even having it there as optional is risky and adds to an already huge maintenance burden. You know the distro packagers will enable every feature just like they did with DTLS support (which is what made Heartbleed pervasive).
Packagers don’t want to deal with complaints and support tickets because their OpenSSL build doesn’t do 3DES. So they turn on all the things.
But libressl breaks ABI compatibility (see that BSD is taking a step backward).
OpenSSL is affected by what we can call "fame". It's the mostly wide used security library in the whole internet and it's the favourite target for hackers. For comparison, it's the same that happens to OS: windows and android are the preferred target platforms because of the large user base they have.
OpenSSL is also affected by the problem that it was basically a toy project in the first couple years and got very little attention for well over a decade. OpenSSL is currently where Windows was ~15 years ago: XP and previous releases were an unmitigated security disaster, and slowly, release-for-release things are now improving.
OpenSSL also suffers from typical industry diseases: Very poor documentation, poor interface design.
Are you volunteering to patch every program which uses OpenSSL? If not, you have the answer: it’s been widespread for decades and so many things use it that compatibility is a big concern. Think about a distribution like Debian with thousands of packages, some of which update frequently and others which haven’t been updated in years. If it’s compatible, you can ship one shared library update but if it’s not you’re either not upgrading or maintaining a ton of patches.
The LibreSSL approach was to write a new library and API, libtls, which does away with the substantial configuration complexity in applications: https://man.openbsd.org/tls_init.3
I'd argue that LibreSSL's is the better approach.