开放源码开发和用户社区之间的健康交互应该是一个优先事项。
想象一下，发布一个基于开源软件的大型新基础设施服务，却发现您部署的产品发展得如此之快，以至于您发布的版本的文档不再可用。在布隆伯格，我们在部署OpenStack时亲身经历了这个问题。2016年下半年，我们花了6个月的时间在OpenStack环境中测试并推出了Liberty。到那时，Liberty已经有一年的历史了，比最新的版本晚了两个版本。
当我们的用户开始利用它的新功能时，我们发现自己无法解决一些棘手的问题，也无法回答一些关于它的API的详细问题。当我们寻找Liberty的文档时，在OpenStack网站上找不到。事实证明，Liberty被贴上了“生命的终结”的标签，OpenStack开发社区不再支持它。
消失并不是故意的，而是开发社区没有预料到用户的实际需求的结果。文档与源代码一起存储在源分支中，并且由于Liberty已被新版本所取代，所以它已被删除。更糟的是，在这期间的几个月里，新版本的文档已经完全重新构建了，没有办法以一种有用的形式轻松地重新构建它。相信我，我们尽力了。
在咨询了其他用户和我们的供应商之后，我们发现OpenStack每年发布两个版本的开发节奏产生了一些意想不到的结果，但也非常令人沮丧。通常仍在广泛使用的旧版本正在被取代，并出于支持的目的被有效地删除。
最终，OpenStack用户和开发人员之间的对话导致了变化。文档已从源分支移出，用户现在可以为他们正在使用的任何版本构建文档——或多或少是无限期的。问题解决了。(我特别要感谢我的同事克里斯·摩根(Chris Morgan)，他对这项工作非常投入，并首先为OpenStack超级用户博客详细地写了一篇文章。)
许多其他企业用户与运行bloomberg的OpenStack旧版本的用户处于同一条船上，后者比最新版本落后三到四个版本。这样做有一个很好的理由:一个相当大的企业平均需要大约6个月的时间来限定、测试和部署OpenStack的新版本。而且，从我的经验来看，这通常适用于大多数开源基础设施项目。
在过去十年的大部分时间里，像彭博这样采用开源软件的公司都依赖于分销供应商来整合、测试、验证和支持大部分开源软件。这些供应商提供了长期支持(LTS)版本，这使企业用户能够计划在两到三年的周期内进行升级，因为他们知道，即使他们的部署计划出现了一点偏差(就像他们经常做的那样)，他们仍然可以在一两年内获得支持。然而，在过去的几年里，基础架构软件的发展如此之快，甚至连发行版供应商都难以跟上。而且这些供应商的客户又少了一步，所以许多人选择在没有供应商支持的情况下部署这种类型的软件。
失去供应商的支持通常也意味着没有LTS版本;OpenStack、Kubernetes和Prometheus等公司还没有提供自己的LTS版本。因此，我认为开发和用户社区之间的健康交互应该是采用任何开源基础设施的首要考虑因素。构建软件的开发人员是否注意到部署软件并使其对企业有用的人员的需求和挫折?
这应该如何发生，有一个可靠的模型。我们最近加入了云本地计算基金会，它是Linux基金会的一部分。它有一个正式的最终用户社区，其成员包括像我们这样的组织:试图使开放源码软件对内部客户有用的企业。企业成员也有机会在投票选举CNCF技术监督委员会代表时表达自己的意见。类似地，在OpenStack社区中，彭博社也参与了半年度的运营商聚会，在那里，为自己的用户部署和支持OpenStack的公司聚集在一起，讨论他们面临的挑战，并为OpenStack开发者社区提供指导。
过去几年对于开源基础设施来说是非常好的。如果您正在为大型企业工作，那么像上面提到的那样部署开源项目的机会会使您的公司更高效、更敏捷。
像我们这样的大公司开始消耗更多的开源软件满足基础设施的需求,他们会看着一长串的考虑后再决定如何使用:许可证兼容性,付现成本,开发社区的健康只是几个例子。由于我们的经验，我们将增加一个充满活力和参与的最终用户社区的存在名单。
对开源基础设施项目越来越多的依赖也突出了一个关键问题:开发社区的人们很少有将他们工作的软件部署到生产环境的经验，或者支持那些每天使用它来完成工作的人。对这些项目的快速更新给部署和使用它们的人带来了一些意想不到的问题。我可以举出许多例子，其中开源项目更新得如此频繁，以至于新版本常常会无意中破坏向后兼容性。
随着开源越来越成为众多企业运营的基础，这是不允许发生的，用户社区的成员应该相应地维护自己，并要求创建正式的表示。最后，软件只能更好。
