很多人都知道，OpenSSL 1.1.0版本有意介绍了从以前的版本引入了重大的API更改，以前公开可见的大量数据结构已经变得不透明，添加了访问器函数以获取和设置这些现在不透明结构中的一些字段。值得注意的是，使用不透明数据结构对库通常是有益的，因为可以改变这些数据结构而不破坏ABI。因此，这些变化的总体方向在很大程度上是合理的。
然而，虽然API更改通常是进展所必需的，但OpenSSL似乎没有转换计划，完全忽视了这些更改对整个开源生态系统的影响。
目前来看唯一可接受的方案是把重任转接给每个使用OpenSSL 的软件项目中：在依然兼容以前API的情况下推进每个项目中把核心代码迁移为OpenSSL 1.1 ，同时保持与先前API的兼容性（例如php-src和openssh-portable）。这迫使每个项目提供自己的向后兼容性，肯定会引发一些问题，引入潜在的安全问题或内存泄漏。
由于许多因素，使用OpenSSL的软件项目不能简单地迁移到1.1 API，并且不再支持1.0 API ——在大多数情况下，他们需要继续支持这两者。首先，我不知道有任何平台已经发布OpenSSL 1.1版本 —— 任何支持OpenSSL 1.1的软件，没有平台可以使用。其次，OpenSSL 1.0.2版本支持到2019年12月31日，而OpenSSL 1.1.0只支持到2018年8月31日——显然任何LTS风格版本都会考虑使用1.0.2。
尝试与OpenSSL 1.1 协同工作的平台已经遭遇了明显的挑战 ：例如，目前Debian518个中就有257个包不是针对OpenSSL 1.1 构建的。同时还存在隐藏一些问题，类似不同的类库基于不同的OpenSSL 版本但却贡献OpenSSL 数据结构的场景，这些问题都很难被察觉。因为他们只会在运行时出现。
但是，OpenSSL（仍然有）至少两个选项可以避免这种情况，使得软件项目从旧的API平滑过渡到新的API，而不是每个单独的项目都必须向后兼容至少三年（实际更长）。
我恳求OpenSSL项目认真重新考虑他们的API改变的方法，更重要的是相关的迁移，尤其是记住什么是最好的整体生态系统，而不仅仅是OpenSSL项目。我还要求使用OpenSSL的软件项目仔细考虑他们如何处理这种情况，特别是考虑他们需要多长时间携带兼容性代码和#ifs。
最后我想说的是，这不是LibreSSL的问题 —— 如果我们添加所有的OpenSSL 1.1访问器，为OpenSSL 1.0或OpenSSL 1.1编写的软件将可以与LibreSSL无缝工作。但无论如何，软件仍然必须保持与两个OpenSSL API的兼容性。