This was inevitably going to happen

... and it will continue as projects are forced to change their code to adapt to changing APIs, then discover massive performance regressions while testing the changes.

The accumulation of bad design choices is well explained in the article. Running "perf top" during operation is frightening, with malloc/free often taking the lead given how much stress the lib is putting on them for tiny elements (I seem to remember noticing numerous calls to malloc(4) at some point making me wonder why not to store that into a uint32_t instead).

I agree that the position of "openssl 1.1.1 performance will never be recovered" is totally unacceptable, given that it was already sub-standard due to locking and allocations. And the competition from much faster libraries like aws-lc and rusttls which are also way more responsive and listening to their users will put extra pressure on them to reconsider certain choices.

I think that more feedback like this article is needed. It's definitely unpleasant to write, because it feels a bit harsh to bash opensource software like this (we were in the same situation when writing our article on the state of ssl stacks), but it does help them better understand applications' use cases and important stakes, because they can feel that it's not just a developer whining on a small API change, but deep problems that go as far as condemning some use cases. And for me what happened here is a perfect illustration of how difficult it probably is for a library to sense how it's being used by applications.

On a positive note, we're in regular contact via periodic meetings with several members of the OpenSSL team who recently became more open to hearing about the issues faced by their users. I sense that such discussions might not always be pleasant for them to hear but at least they're asking for this feedback and they're taking notes of griefs, which is really great. They've improved their CI to integrate performance regression tests, not just on crypto functions but by directly running applications relying on their lib. This is the right thing to do, and if they had been doing that during 3.0 development, it would simply never had taken that direction at all. It's unclear how many years (decades?) it will take to undo all the massacre that was done to the code base since 1.1.1 and whether they'll stay the main library or if they'll just stay there for a few legacy applications. I would still prefer to see them manage to fix their problems (starting with the technical decisions making process so as to favor re-architectural work that addresses the causes rather than voting on strong beliefs leading to pointless workarounds like RCU), and ultimately take the lead back for the good of everyone. Let's wish them good luck as it will be a long and tedious work.