平衡CentOS平台的需求

在过去的几周中，我已经阅读并听取了很多人对我们有关CentOS项目未来的新闻的反应。我看到很多惊喜和失望，也看到人们担心未来以及未来将如何影响他们，他们的生计以及整个生态系统。我听到人们强烈的背叛感。

我不知道我在这里的故事对您有没有帮助，但感谢您通读并听完我要说的话。我认为所涵盖的历史对于了解我们今天的状况是必要的。从这里开始，如果您想进一步谈谈为什么我认为结果还可以的话，我将在CentOS开发列表和Twitter上显示。

自成立以来，我一直在CentOS项目管理委员会任职。我也是最近宣布的关于转移项目重点的共识决定的一部分。我在Red Hat呆了19年，在此之前，我一直很关心这个空间。从最早的时候开始，我就参与了Fedora项目，领导文档项目并担任当时的Fedora董事会成员。我领导了Red Hat的团队，在2013/2014年使CentOS项目更接近Red Hat，并且由于这项工作，我获得了CentOS理事会的席位，在那里我担任Red Hat联络和董事会秘书，直到2020年春季。

让我们回到2003年，Red Hat看到了进行根本改变的机会，从而成为具有开源开发方法的企业软件公司。

为此，红帽做出了艰难的决定，并于2003年将红帽Linux分为红帽企业Linux（RHEL）和Fedora Linux。 RHEL偶尔是Fedora Linux的快照，它是一种产品-减慢，稳定并按计划进行生产。 Fedora Linux及其周围的项目是创新的开源社区，它速度更快，易于更改，并且随时准备探索。这解决了在单个项目中尝试保持两个不兼容的核心值（快/慢）的问题。之后，每种发行都在其预期的受众范围内蓬勃发展。

但是这种分裂留下了两个重要的空白。在项目/社区方面，人们仍然希望OS努力做到移动速度慢，足够稳定且没有成本（可用性差距）。在产品/客户方面，存在开放性鸿沟-RHEL用户（因此，所有重建用户）对RHEL的贡献并不容易。重建工作开始了，并解决了可用性方面的空白，但是他们拒绝向核心Linux发行版本身作出贡献。

2012年，红帽致力于提供操作系统以外的产品，这导致需要一个易于访问的平台，用于上游项目的开源开发（例如Gluster，oVirt和RDO），这些平台均来自这些产品。当时，Fedora的创新步伐使其不容易使用。例如，Fedora中内核更新的速度导致这些分层项目的中断。

我们组建了一个由我在Red Hat领导的团队来解决这个问题，在与CentOS Project核心团队进行讨论之后，Red Hat和CentOS Project同意“联手”。我们说合并是因为没有要收购的公司，所以我们雇用了核心团队的成员，并开始将CentOS扩展到不仅仅是一个重建项目。其中包括投资基础设施和保护品牌。目标是发展成为一个项目，该项目也可以在其上构建事物，并且该项目将比以往任何时候都更开放地做出贡献，这是对开放性鸿沟的部分解决方案。

将CentOS Linux用户带回了Red Hat系列，他们被困在可用性差距中的人们带回了家，这是该计划的一个很好的副作用。我从参与者到活跃的开源贡献者的经验始于Fedora项目诞生之后的2003年。那时，作为一个富有同情心的人，我发现应对Red Hat Linux分裂带来的持续情绪冲击是一项挑战。我许多长期的社区朋友自己都受到了影响。作为一家公司，我们不知道RHEL还是Fedora Linux是否可行。我们做出了一个艰难的决定，正在余震中航行。从那时起，我们所有人都学到了很多东西，包括开源开发方法的难度更大的动态。因此，对我来说，再次让CentOS和其他重建社区与Red Hat建立实际的关系是很高兴看到，体验和帮助实现的。

自从最终结盟以来的六年中，我们在这些目标上取得了良好的进展。我们成立了特殊兴趣小组（SIG）来管理分层项目体验，例如存储SIG，Virt Sig和Cloud SIG。我们创建了一个前所未有的治理结构。我们将RHEL源代码存储在git.centos.org中。我们在一个项目中设计并建造了一个重​​要的公共基础设施和CI / CD系统，该项目以前一直是密闭的。

但是，RHEL本身的开发仍然在Red Hat防火墙之后仍然处于封闭状态。这已经有将近二十年的历史了。对于开放源代码开发生态系统而言，这是一个重要且通常令人痛苦的鸿沟，与2003年的鸿沟仍然相同。

这将我们带到了今天，也是我们现在生活的当前章节。将项目重点转移到CentOS Stream的举动是关于通过一些关键方式填补开放性空白。本质上，红帽通过将CentOS的位置从RHEL的下游转移到RHEL的上游来填补Fedora和RHEL之间存在的开发和贡献差距。

就像我们联合起来一样，Red Hat提出了CentOS项目的计划，而CentOS董事会也签署了该计划。该计划的重点不仅在于弥合开放性鸿沟的反馈回路部分，还在于找到一种方法来帮助将RHEL开发从发生在Red Hat内部发展为发生在外部。

董事会完全意识到，填补一个空白后，我们冒着重新打开等式的最终用户方面的可用性空白的风险。虽然CentOS Stream可以以前所未有的方式开放供稿，但它可能会与CentOS Linux有所不同。

但是我们也知道，一个项目试图同时做两个对立的事情就意味着两者都做得不好。为我们的社区提供扎实，可靠的发行版，足以满足您的工作量，这是CentOS品牌的重要组成部分。我们相信CentOS Stream可以做到这一点。

而且，尽管我现在确定CentOS Linux不能做CentOS Stream所能解决的开放性鸿沟，但我有信心CentOS Stream可以覆盖可用性鸿沟中各方面的95％（或左右）的当前用户工作负载。我相信Red Hat也将提供可用的解决方案，这些解决方案可以弥补差距的其他方面，而最终不会导致过多的用户伤心欲绝。

从现在开始，是时候真正地帮助CentOS项目更详细地了解CentOS Linux替代品中的需求。甚至您最愤怒的帖子也被阅读，您热情的观点也被看到和理解。我不是唯一从事此工作的Linux老手。

这是您有机会认识到可用性或开放性差距所在的位置以及差距如何存在的机会，从而使设计RHEL解决方案的人员在考虑您的用例的情况下就可以做到。此输入正在发生。新的电子邮件地址[email protected]直接发送给业务部门的人员（不在销售部门），他们试图使用这种开源开发方法解决您的问题。

很难在制定业务决策的需求和过程与制定开放社区决策的需求和过程之间取得平衡。可以说，红帽一直是跨越这条艰难而细线的最佳组织之一。如果您足够信任我们的代码可以长期运行，那么请您相信我们在这里做出正确的决定。我要求您信任Red Hat和CentOS董事会与您一起寻找一种将社区带入下一章的方法。

如果您想与我进一步交谈，最好的地方是centos-devel列表或Twitter。