除了迅雷还有什么软件更好用

想象一下，发布基于开源软件的一项主要的新基础架构服务，只是发现您所部署的产品发展得如此之快，以至于您发布的版本的文档不再可用。 在彭博社，我们在部署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本机组织Cloud Cloud Computing Foundation。 它有一个正式的最终用户社区 ，其成员包括像我们这样的组织：那些试图使开源软件对其内部客户有用的企业。 公司成员在投票选举代表参加CNCF 技术监督委员会时也有机会表达自己的意见。 同样，在OpenStack社区中，彭博社参与半年一次的运营商聚会，在该聚会中，为自己的用户部署和支持OpenStack的公司聚在一起讨论他们的挑战，并为OpenStack开发人员社区提供指导。

在过去的几年中，开源基础设施非常出色。 如果您在一家大型企业工作，那么部署如上所述的开源项目的机会将使您的公司更高效，更敏捷。

随着像我们这样的大公司开始使用更多开源软件来满足其基础结构需求，在决定使用哪种方法之前，他们将考虑一长串考虑因素：许可证兼容性，自付费用和运行状况开发社区只是其中的几个例子。 根据我们的经验，我们将在列表中添加一个充满活力和参与度的最终用户社区。

对开源基础设施项目的依赖日益增加，这也凸显出一个关键问题：开发社区中的人们对于将其工作的软件部署到生产环境中或支持使用该软件的人每天完成工作的经验很少。 这些项目的快速更新给部署和使用它们的人们带来了一些意想不到的问题。 我可以举很多例子，其中开源项目的更新频率如此之高，以至于新版本通常会无意间破坏向后兼容性。

随着开源越来越成为许多企业运营的基础，这是不允许发生的，用户社区的成员应据此进行自我声明，并敦促创建正式代表。 最后，软件只能更好。

翻译自: https://opensource.com/article/18/2/important-conversation

除了迅雷还有什么软件更好用