想象一下，发布一个基于开源软件的主要新基础设施服务，却发现您部署的产品演进得如此之快，以至于您发布的版本的文档已不再可用。在彭博社，我们在部署 OpenStack 时亲身经历了这个问题。在 2016 年末，我们花了六个月的时间在我们的 OpenStack 环境中测试和推出 Liberty。那时，Liberty 大约有一年历史，或者比最新版本落后两个版本。
当我们的用户开始利用其新功能时，我们发现自己无法解决一些棘手的问题，也无法回答关于其 API 的一些详细问题。当我们寻找 Liberty 的文档时，在 OpenStack 网站上却找不到。事实证明，Liberty 已被标记为“生命周期结束”，并且不再受 OpenStack 开发人员社区的支持。
这种消失并非有意为之，而是开发社区没有预料到用户的实际需求的结果。文档与源代码一起存储在源分支中，并且随着 Liberty 被较新版本取代，它已被删除。更糟糕的是，在随后的几个月中，较新版本的文档已完全重组，并且无法以有用的形式轻松重建它。请相信我，我们尝试过了。
在咨询了其他用户和我们的供应商后，我们发现 OpenStack 每年发布两个版本的开发节奏造成了一些意想不到的，但却令人非常沮丧的后果。通常仍在广泛使用的旧版本正在被取代，并且实际上为了支持的目的而被淘汰。
最终，OpenStack 用户和开发人员之间进行了对话，从而促成了改变。文档已从源分支中移出，现在用户可以为他们正在使用的任何版本构建文档——或多或少是无限期的。问题得到了解决。（我特别感谢我的同事 Chris Morgan，他全身心投入到这项工作中，并首先在 OpenStack Superuser 博客上详细介绍了此事。）
许多其他企业用户与彭博社的处境相同——运行比最新版本落后三到四个版本的旧版 OpenStack。这有一个很好的理由：平均而言，一个规模相当大的企业大约需要六个月的时间来鉴定、测试和部署新版本的 OpenStack。而且，根据我的经验，这通常适用于大多数开源基础设施项目。
在过去的十年中，像彭博社这样采用开源软件的公司依赖于发行商来整合、测试、验证和支持其中的大部分软件。这些供应商提供长期支持 (LTS) 版本，这使企业用户可以计划在两到三年周期内进行升级，知道即使他们的部署计划略有延迟（这种情况经常发生），他们仍然会获得一两年的支持。然而，在过去几年中，基础设施软件发展如此迅速，以至于即使是发行商也难以跟上。而这些供应商的客户又被进一步剥离，因此许多人选择在没有供应商支持的情况下部署此类软件。
失去供应商支持通常也意味着没有 LTS 版本；OpenStack、Kubernetes 和 Prometheus 以及更多其他软件尚未提供他们自己的 LTS 版本。因此，我认为，对于任何开源基础设施的采用，开发和用户社区之间的健康互动都应该在考虑事项列表中名列前茅。构建软件的开发人员是否关注部署它并使其对其企业有用的用户的需求和挫败感？
关于如何做到这一点，有一个可靠的模式。我们最近加入了 云原生计算基金会，它是 Linux 基金会的一部分。它有一个正式的 最终用户社区，其成员包括像我们这样的组织：试图使其内部客户能够使用开源软件的企业。企业成员也有机会发出自己的声音，因为他们投票选出代表在 CNCF 技术监督委员会任职。同样，在 OpenStack 社区中，彭博社参与了每半年一次的运营商聚会，在聚会上，为自己的用户部署和支持 OpenStack 的公司聚集在一起，讨论他们的挑战，并向 OpenStack 开发人员社区提供指导。
过去的几年对开源基础设施来说是美好的。如果您在一家大型企业工作，那么部署上面提到的那些开源项目的机会使您的公司更高效、更敏捷。
随着像我们这样的大公司开始消耗更多的开源软件来满足其基础设施需求，他们在决定使用什么之前会考虑很长的清单：许可证兼容性、直接成本以及开发社区的健康状况只是几个例子。由于我们的经验，我们将把活跃且参与度高的最终用户社区的存在添加到列表中。
对开源基础设施项目的日益依赖也突显了一个关键问题：开发社区中的人们很少有经验将他们开发的软件部署到生产环境中，或者支持使用它来完成日常工作的人们。这些项目的快速更新为部署和使用它们的人们带来了一些意想不到的问题。我可以举出许多例子，在这些例子中，开源项目更新频率如此之高，以至于新版本通常会无意中破坏向后兼容性。
随着开源越来越成为如此多企业运营的基础，这种情况不能被允许发生，用户社区的成员应该相应地坚持自己的权利，并争取建立正式的代表机构。最终，软件只会变得更好。
评论已关闭。