红帽：我们为什么要改变 RHEL 源码的发布策略？

最近 Red Hat 改变 RHEL 源码发布策略进行了一些改变，引起了广泛讨论。有人认为 Red Hat 并没有违反开源协议，也有人认为 Red Hat 断了白嫖人的路、割韭菜。7 月 11 日，Red Hat 首席架构师张家驹、公众号开源青年主理人周荔人，做客《极客有约》，一起聊了聊 Red Hat 改变 RHEL 源码发布策略背后的那些事。本文根据直播内容整理并在不改变愿意上做了删减，点击查看完整视频。

CentOS Stream 和 RHEL 的差别

周荔人：Red Hat 对其企业发行版（RHEL）源码发布策略的调整，这个改变是否代表了 Red Hat 在企业战略上发生了变化，并且这个变化是有战略支撑的吗？

张家驹：Red Hat 在过去几年中对 Red Hat 企业发行版（RHEL）开发流程进行了调整。为了理解这个变化，我们需要回顾一下历史。去年以及之前的时间，有人普遍反映 CentOS 停止更新的情况。另外，这里还有一个名为 CentOS Stream 的项目。现在我将通过 PPT 来详细介绍 Red Hat 和 CentOS 之间的历史关系。

大家都知道，CentOS 社区开发者规模并不大，最初只有几个人。在 2014 年，Red Hat 收购了 CentOS，从而形成了下图中的第一行格局：

开源领域中上游和下游的概念，在发行版领域也同样适用。上游是指代码的来源，而下游是在上游提供的代码基础上进行增强和修改后的版本。

在 2018 年，我们开始准备相关工作，并在 2019 年发布了 CentOS Stream。然而，由于我们没有公开宣布，所以可能很多人并不知道。因此在 2019 年，CentOS 就出现了两种形态：CentOS Linux 和 CentOS Stream。

2019 年开始，我们基于 CentOS Stream 进行 RHEL 的开发。在此之前，我们的代码直接从 Fedora 获取。随后我们改变了整个发行版的开发测试流程，采用了自动化手段代替了之前的手工或瀑布式开发流程。我们认为，通过这种开发方式，RHEL 才能满足当今越来越敏捷的需求。因此，我们逐步将注意力从 CentOS Linux 转向 CentOS Stream。因此，大家听到的各种关于停止服务的说法都是因为这个原因。但对于 Red Hat 来说，并没有停止服务，只是 CentOS 项目从 CentOS Linux 转向了 CentOS Stream，也就是项目的重点发生了变化。

当我们讨论发行版的上游和下游时，有一些专业术语需要解释，如"Backport"（反向移植） 和"Test"。在这里，"Backport"是一个特殊的术语，意思是将上游的某些补丁反向移植到下游的版本中。这是我们保证发行版长期生命周期支持稳定性的一个重要步骤。

虽然都说 Linux Kernel 是 Fedora 的上游、Fedora 是 CentOS Stream 或 RHEL 的上游，以及 RHEL 是 CentOS Linux 的上游，但实际上这些上下游关系并非都一样，本质上是由发行版厂商之间来定义的。例如，Linux Kernel 与 Fedora 之间的关系。Fedora 是一个大的集成项目，不仅包括 Linux Kernel，还包括 GNOME 和很多其他的网络、存储等项目。这些项目集成到 Fedora 实际上是一个集成和打包的工作，以确保集成的产品可以运行。

从 Fedora 到 CentOS Stream 或 RHEL，都要经历一个所谓的"Backport & Test"过程。这一步是 Red Hat 的工程领域中最重要的工作。然后从 CentOS Stream 到 RHEL，实际上是一个补丁筛选的工作。

在 RHEL 的版本发布周期中，我们会选择在 Stream 中的补丁加入到 RHEL 中，但是 RHEL 中的所有补丁都一定在 CentOS Stream 中存在。CentOS Stream 中的所有补丁最终都会加入到 RHEL 中，可能会加入到 RHEL 的不同版本中。

因此，我们并不能说 CentOS Stream 是一个用于测试的版本，然后让社区的人或用户去测试。在 RHEL 中，我们已经没有其他的测试流程。所以如果问这东西是否稳定，测试的流程实际上是在"Backport"和"Test"这个动作里面去做的。

在谈论关于 CentOS 8 (C8)的分支时，我们必须明确 git.centos.org 仅是源代码的一个归档，或者说一个镜像。实际上，Red Hat 企业版（RHEL）的主开发线是在 CentOS Stream 上进行的。我们的 RHEL 是一个 git tree，存放于 GitLab 上。在 GitLab 上，CentOS Stream 的主线就是 RHEL 的主开发线。

这可能引发一些困惑，即开发流程可能不稳定。实际上，这就是我需要解释的部分：CentOS Stream 并非采用传统的开发方式。通过 Stream 的方式，我们已经改变了整个开发流程。简单来说，只有那些经过全面测试并被 Red Hat 认为质量有保证、没问题的补丁，才会加到 Stream 的主线上。如果不符合这些条件，我们将不会将其加入主线。

CentOS Stream 的稳定性与 RHEL 是等同的，尽管它与 RHEL 存在微小的差异。现在，我们来看一 下 CentOS Stream 与 RHEL 的主要区别。由于 CentOS Stream 是一个流动的发展线，我们可以从一个例子来说明，比如从 8.2 到 8.3 的版本更新。我们每半年发布一个小版本，比如 8.2 可能在今年 1 月份发布，8.3 可能在 7 月份发布。8.2 发布时，CentOS Stream 就处于开发中。一旦确定了 CentOS Stream 的代码就会生成 RHEL 8.2。随后 Stream 的变化会进入到 8.3 的发布队列里。

主线接着向前发展，半年后，8.3 版本发布。从 CentOS Stream 的主线上，我再次生成一个版本，那就是 8.3。在 8.2 到 8.3 的 6 个月里，可能会添加 100 个补丁，但是在 8.2 的时间点，你只能获取到当时的补丁。比如当前是位于 8.2 发布后两个月，但是 8.3 还没出，可能有 20 个新的补丁已经添加到主线上，所以这时候你拿到的 Stream 和 8.2 是不完全一致的。

从用户的角度来看，他们可以从 8.2 升级到 8.3，来获取到这 100 个补丁。这种方式对于企业来说是必要的，因为他们无法每天进行升级。对于我们来说，发布版本也不能每天进行。一些小 Bug 修复和新功能实际上并不需要随时跟着升级。但如果选择了 Stream，你可以选择升级或者不升级。例如，在 8.2 的发布日，你下载了一个与 8.2 基本一致的代码，但你可以等到一年后发布 8.4 版本时再进行升级。

对于企业来说，Stream 的一个问题是，它没有固定的小版本。所以当你的软件与其他软件进行整合时，如果别人问你的版本是 8.2 还是 8.3，你可能会说不清楚。所以一些企业可能会表示无法使用 Stream。

但是我们需要考虑两个方面：一是稳定性，二是小版本的固定性。对于稳定性的要求，Stream 是完全符合的。但对于小版本的固定性，由于 CentOS Stream 是一条主线，实际上没有小版本，因此一些大型企业用户可能会选择使用 RHEL 的小版本。

关于稳定性，另一方面实际上是指应用的兼容性。从一个老版本到新版本，应用是否被打破、API 是否改变等都是用户最关心的。CentOS Stream 是连续的，而 8.2、8.3、8.4，这些 RHEL 的版本是离散的，所以我们是在 CentOS Stream 里确保了连续版本在每一点的兼容性，才能够保证 8.2、8.3、8.4 之间的小版本是兼容的。实际上，Red Hat 保证了这些小版本之间的兼容性，一个应用在 8.2 可以运行，在 8.3 也可以。

反过来说，我们为什么不能从 Fedora 的 28 版本开始分支，然后继续发展呢？实际上，如果你使用 28 版本，例如从 28 到 34，可能 28 里面有的一个功能在 34 里面完全不兼容，因为功能被彻底改写了。选择 openSUSE 或其他类似版本，实际上是同样的道理，你的应用很难保证不同版本之间的兼容性。

RHEL 源码发布策略调整的原因

周荔人：为什么 Red Hat 这两年把 CentOS 的源码的发布方式做了改变？

张家驹：首先，对于 CentOS 社区，我们期望实现更为频繁和有效的互动。我们希望下游的 CentOS 用户能够直接将需求和提议反馈到社区，并在接下来的版本中得到实现。这也是我们过去几年对 CentOS 系列产品进行各项工作的主要驱动力。

在 git.centos.org 的代码问题上，我们的策略也做出了调整。过去，这些代码由 Red Hat 构建，然后供 CentOS 使用。但现在，Red Hat 不再构建 CentOS，而是创建了一个 CentOS Stream 社区。因此，将代码存放在 git.centos.org 上实际上是多余的。这不仅增加了人力成本，还需要进行额外的维护工作。然而，对我们而言，它本质上是一个不必要的步骤，因为我们可以直接从 Stream 中获取代码。

此外，我们不仅仅考虑维护成本，还希望社区更加健康和活跃。这是 Red Hat 的初衷，我们希望社区能够健康发展，有更多的互动和反馈，持续改进和发展。我们也不希望社区仅仅停留在打包的阶段，而希望下游能够进行更多的创新，并通过一种更好的方式将这些创新反馈到企业版中。

目前的问题是，如果 CentOS 仍然存在，那么最大的问题就是它的单向性。我们将代码放在那里供人们使用，但如果用户发现问题或有改进的建议，他们无法有效地反馈给 Red Hat 或 CentOS 社区，因为 CentOS 是一个静态的平台，不像其他可以进行互动的平台，它只是一个代码存储的地方。

坦诚地说，我们的主要出发点是基于刚才讲述的生态问题。作为生态的副产品，这对下游的 rebuild 来说可能会变得不那么容易。然而，所有的下游 rebuild 现在仍然活跃，所以并不是说下游的 rebuild 无法进行。但是，我们在官方声明中也已经表达了这一观点。事实上，我们并没有义务让下游的 rebuild 工作变得非常容易，但我们也并没有完全堵死这条路。

在这个问题上，我认为有点像 iPhone 的升级策略。如果你使用 iPhone，你会发现它总是在升级，而且很难找到降级的方法。升级后，你可能会发现很多习惯与原来不同，对此你可能会感到不满。但这也是他们的产品策略，强迫你以新的方式使用产品。

我们期望看到更多用户能够跟随 CentOS Stream 的发展，使用最新的应用。这实际上是一件好事。虽然在升级的瞬间，你可能会觉得很多习惯和以前不同，但是我们坚定地推动 CentOS Stream，我们希望 CentOS Stream 能够更加繁荣起来。

周荔人：对于 Red Hat，其主要工作并非仅仅是从企业版提取代码供下游免费使用，而是去鼓励大家参与贡献代码。这可能是 Red Hat 推动变革的主要原因。然而，对于下游的 CentOS 可能会变化且可能导致不稳定的担忧，这应是下游的大型制造商需要考虑的问题。在这个问题上，Red Hat 实际上并没有必要过度担忧。

有人在直播间中提出了一个问题：原先的 CentOS 用户是否都被各种 CentOS 的替代品取代了？我认为这并不是 Red Hat 需要担心的问题。实际上，这又引发了另一个问题：为什么 CentOS 的服务被停止？对于这个问题，我们是否可以请家驹老师来解释一下：当年 Red Hat 收购 CentOS 的原因是什么？难道他们收购 CentOS 就是为了鼓励更多的专家参与到生态系统中来、为生态系统做出贡献吗？

张家驹：这个问题十分重要：为什么 Red Hat 当初决定收购 CentOS？一些观点可能认为，我们收购 CentOS 后，养肥了几年，然后停止了服务。但真相并非如此。在深入讨论之前，必须明确一点：我们不能仅以收购行动本身进行判断，而需要将它放在更大的背景中审视。我们应从整体视角来观察，避免断章取义。

事实上，在 2014 年至 2019 年期间，尤其是 2014 年收购之后，我们可以看到 Red Hat 的策略是将 RDO（OpenStack 社区版）的内容引入 CentOS。

在收购之前，CentOS 被普遍视作 RHEL 的复刻版。然而收购完成后，特别是在 2014 年之后，情况发生了变化。CentOS 中增加了许多 RDO 的代码和软件包，这些新增的部分主要与虚拟化和云计算相关。这意味着，这些软件包是直接从上游获得的。

如果我们认为经过 RHEL 测试流程的版本是稳定和可靠的，那么 RDO 就可能是最不稳定、最不可靠的版本，因为它相当于把 Fedora 的内容引入到了 CentOS 中。为什么要做这样的操作？这并不是为了混淆，而是因为当时我们看到使用 CentOS 的用户群体中，有很多人都在尝试进入云计算领域，大力推动 OpenStack。所以，在基于 RDO 进行开发时，他们需要一个稳定的操作系统。因此，我们决定将 RDO 的一些软件包加入到 CentOS 中。

虽然我们可以鼓励这些致力于云计算的开发者使用 Fedora，但 Fedora 本身并不稳定。所以，当出现问题时，开发者很难确定是系统本身导致的问题，还是他们自己开发的云计算相关程序不稳定导致的。因此，在一个稳定的 CentOS 操作系统上添加云计算相关的内容，对于在 CentOS 或者 Red Hat 社区中进行开发的人来说会更方便。

因此，Red Hat 收购了 CentOS，并且增加了以上内容。大家拿到的 CentOS，实际上并不是一个纯粹的 RHEL 克隆版。

周荔人：直接把 CentOS 的拿掉，找 Red Had Enterprise Linux 去做不是更好吗？

张家驹：Red Hat Enterprise Linux（RHEL）是我们的商业产品，主要基于付费模式。尽管有免费用户，但主要以付费用户为主，这是我们的主要经济来源。如果基于 RHEL，相当于将商业产品免费提供给所有人使用。然而，购买 RHEL 的用户将享受我们的技术支持服务，一旦你的系统出现问题，我们有责任帮助你解决。而对于 CentOS，我们并没有提供这样的服务，因为 CentOS 是一个社区版，不存在服务支持的问题。

在 Red Hat 收购 CentOS 之前之后，CentOS 都是一个免费的社区版。如果你使用 CentOS 遇到问题，不能指望得到 Red Hat 的售后服务。

Red Hat 混合云服务商的转型

周荔人：大家普遍认为 CentOS 和 RHEL 有竞争关系，但这并不是重点。其实，CentOS 的主要目标并非为 RHEL 提供用户转化，更多的是作为 Red Hat 转向云原生时代的一个跳板，所有的跟 Red Hat 云原生相关的工作都是 CentOS 来完成的。

张家驹：确切地说，我们希望让社区不仅仅停留在操作系统领域，也走向云计算领域。在 OpenStack 时代，我们就已经开始这样的转变，随着 Kubernetes 的出现，我们更加重视云原生，希望社区能够涵盖更多的领域、完成更多的任务。

周荔人：直播间有一个问题，Red Hat 是否向用户提供源码？这是大家争论最多的问题。

张家驹：根据 GPL 的协议，用户在拿到二进制的同时也可以获取源码。并且，这个源码和二进制是严格对应的，他们并不会存在差异。在用户协议中，我们并没有限制用户拿到源码的权利。

周荔人：可以拿到源码但是不能像订阅用户之外的人分发，这也是用户协议里面的限制吗？

张家驹：我的理解是，并没有这样的限制。当然，我并非专门研究协议或法律的专家，如果你发现了什么特殊的条款，可以提出来或者后续跟我们保持沟通。但是目前来看，GPL 协议中承诺的任何权利在 Red Hat 的用户协议中都没有被剥夺。

周荔人：在 Mike 的两篇文章中，第一篇较为官方，涉及了成本问题。第二篇也讲了成本问题，比如“我们目前维护 3~4 个主流版本，每个版本可能需要在上游进行反向移植，维持 5 年到 10 年，这会带来相当大的成本。”能否和我们大家分享一些 Red Hat 在维护过程中的困难与挑战呢？

张家驹：确实如此，这里涉及到 Red Hat 的商业逻辑。我可以明确地说，Mike 提及维护工作的困难和挑战，实际上是因为 Red Hat 需要出钱雇佣工程师，使开源软件从“黑客的玩具”变为企业可以稳定使用的项目。

Mike 试图阐述的是，虽然我们收取订阅费，但这种商业模式是有意义的，并非因为是开源项目就不能收费。这种收费实际上是解决了一个问题。

接下来，我们讨论一下“反向移植”。维护多个版本非常困难，原因之一是“反向移植”。实际上，这应当与“上游优先”结合起来看。当你开发一个新功能或修复一个 Bug 时，你需要首先在上游提交你的功能，这个过程被称为“上游优先”，然后你再把它反向移植到你自己的版本上，这就是所谓的“反向移植”。

所以，先将新功能放在自己的版本里，然后再在一段时间后将其推送到上游，这并不符合“上游优先”的原则。在 Red Hat，我们将“上游优先”定义为：必须先将代码提交到上游，再将其反向移植到我们的版本中。

周荔人：在您的记忆中，最长的一个特性从 upstream 到达 Red Hat 企业版（Red Hat Enterprise Linux，RHEL）需要多久？

张家驹：存在数年之久的例子。一个 Patch 可能包含几十个甚至上百个版本，这是 upstream 过程中常见的现象。我们现在更关注的不仅仅是 upstream，更多的是反向移植（backport）。开源让我们可以接触到所有开源的开发者。开源加速了创新，许多人更愿意在 upstream 中工作。Linux 绝不缺乏开发者，无论在国内还是国外。

对于开发者来说，从一定程度上，参与开源项目是对个人编程水平和技术实力的一种展示。在寻找工作或制定求职策略时，这样的经历确实有一定的优势。

然而，upstream 有一个特性，也是开源的魅力之一，那就是 upstream 不太考虑兼容性和延续性。例如，我在某个版本中增加了一个新功能，但在下一个版本中，我可能认为前一个版本的实现不佳便将其废弃，并实现了一个全新的版本，这在 upstream 中经常发生。

然而，对于企业来说，需要一个稳定的版本，而这个稳定的版本谁来做呢？如果没有发行版厂商去做 backport，实际上没有人会做这个工作。如同内核中的长期支持（Long Time Support），大部分通过 git cherry pick 来完成，这是一种简单的 bug fix，可以由个人或一个小团队完成。

然而，这种维护的年限是有限的，比如原本是 2 年，现在最长的可以达到 6 年。以 Red Hat 为例，最长可以支持 14 年。所以在支持年限以及 backport 的力度上，发行版厂商具有明显优势。

关于上游社区，比如 Linux 接收到一个新的补丁，我会将其加入 backport。但它缺少来自真实用户的反馈，尽管也有一定数量的克隆点，但在生产级用户的反馈方面却很匮乏。由于商业发行版与许多大型企业合作，因此 Red Hat 得到了许多补丁，这些补丁来自于 Red Hat 的真实用户或是客户报告的实际问题，而这些问题可能在开发者社区或一般用户社区中并未被发现。

再举例说明，当你需要在一个版本差距很大的旧版本上进行 backport 时，由于许多结构体都已经发生变化，保证 backport 的正确性会变得非常困难。另外，你还需要保证内核 API 及 ABI 的稳定性，这需要做出一些考量，这些都是 backport 的工作。

这些工作可能会在发行版的 tree 中，以 RPM（Red Hat Package Manager）的方式在最终发行时发布（Red Hat 和 SUSE 都采用类似的做法）。最终，并不是所有的 changelog 都会被写上，因此在 backport 中的许多工作其实是默默无闻的。从个人的主动性来讲，是偏弱的，所以需要一个公司或企业的有组织的行为。如果版本间隔很大，就需要花费大量的精力去维护和修复问题。

周荔人：当我们面对一个 6.1 版本的内核，期望将其从 4 点几版本开始的一些特性反向移植，这项任务岂不是相当于在内核层面进行重写？

张家驹：确实如此。我常常强调，简单的反向移植任务相对轻松，但当涉及到更复杂的特性，任务的难度将大幅度增加。

Red Hat 50%的工程师负责内核开发

周荔人：许多人反映，在历史版本中进行核心功能测试远比在新版本中要困难。这些看似辛酸的故事其实是开源社区中的常态。因此，希望大家能积极参与开源社区，不仅仅是获取源代码，更是要参与其中，贡献我们的力量。

张家驹：的确，一方面是这个问题。另一方面，我想稍微透露一些关于 Linux 发行版的事情。Linux 发行版包括内核和用户态的部分，但从 Red Hat 的角度来看，我们基本上有一半的人员都在做与内核相关的工作。

对于大量的用户软件包来说，对内核进行长期稳定的支持保证无疑是更为困难的。这很好理解，GCC 和 GDB 等工具非常重要，它们是单独运行的程序，而内核则是一大块在内核态运行的程序。任何小的驱动修改可能都会导致大问题。许多时候，我们会发现某些问题，比如某处的锁有问题，但可能会犹豫是否要修改它。因为我们不确定有多少地方引用了。与微服务这种云原生架构相比，这些问题在内核中更为复杂。

周荔人：对，修改内核就像牵一发而动全身。例如，一个 GCC 版本的更改需要保证任何使用 GCC 的地方都能兼容，每次修改都需要重新进行一遍测试。这实际上是一个指数关系，因此非常复杂。那么，付费用户能否将 Red Hat 的源码转发给社区，以构建类似 CentOS 的东西？会不会违反 Red Hat 的用户协议呢？

张家驹：如果你拿到了 Red Hat 的源码，并打算分享给他人，这是完全可行的。你可以自由地让他人查看源码，甚至重新构建它们。在你的管理下，你有权进行源码的构建并分享给他人。这是你的权利，我的理解是这样的行为是被允许的。

周荔人：实际上，我有个问题一直很好奇。社区治理模式中，Red Hat 公司是一种特殊的情况，被称为"企业主导的开源生态"。无论是 Red Hat 还是 CentOS，所有权都在 Red Hat 公司手中。与之相反的模式是 Open Foundation，即开源基金会。为什么最初没有考虑把生态系统置于基金会的架构之下，这样更多的人可以参与其中？

张家驹：我们刚才提到，Red Hat 所有发行版都需要进行反向移植（backport）工作。因此，关键的问题并不在于项目归属于谁，而是由谁来完成这些让开源项目可以被企业稳定运行的技术工作。

Red Hat 拥有很多内核工程师。我对于基金会模式是否能够支持工程化的发展持怀疑态度。并不是说我们不会把项目交给基金会，例如新项目的孵化，我们也会将其交给基金会。然而关键问题是，如果没有投资，就没有人愿意去做这些具体的甚至是乏味的维护老版本的技术工作。

周荔人：我理解，没有人做这项工作，而且即便有人做，也可能无法像企业版那样及时。企业版作为商业产品，需要及时的技术支持，这是基金会这种松散的架构所不能做到的。协调企业之间的合作关系其实比编写代码要困难得多。

张家驹：另外，基金会不能对最终用户做出承诺。例如，对于目前存在有关软件供应链安全的问题，Red Hat 推出了一个名为“Red Hat Trusted Software Supply Chain”的产品，即我们对这个产品有保证。然而，如果我是一名最终用户，我使用这个产品出问题了去找谁？这就是问题所在。你去找基金会显然是不合适的。

周荔人：的确，基金会并不提供商业技术支持。因此，如果你选择使用 Linux 社区版本，就不应该期待太多的技术支持。你可以提交 PR，但如果有问题，不要指责社区。这也是为什么我们需要像 Red Hat 这样的公司来进行开源软件的商业化。

社区提问

社区： git.centos.org 上的代码，也就是 CentOS 8 分支以及对应的 RHEL 8 代码是否会继续更新？或者说，是否将被 CentOS Stream 的代码所取代？

张家驹：CentOS Stream 是一个总的代码仓库，而 git.centos.org 可以被理解为这个仓库的一个镜像或者视图，Red Hat 客户门户（Customer Portal）也是另一个视图。这两个视图都是为了方便用户下载和使用。实际上，所有的代码都存储在 CentOS Stream 上。无论用户是否有 Red Hat 的订阅，都可以从 CentOS Stream 上下载源代码。”如果不是这样的话，那就是个 bug，那么你也可以向我们报告”（引用 Mike 博客中的话），理论上 RHEL 的所有内容都在其中。

此外，Red Hat 的订阅用户可以在用户的 Portal 上获取所需的二进制程序以及源代码。如同你在微信或任何其他平台上需要账户一样，Red Hat 的订阅也需要一个账户，通过这个开发者账户你可以获得二进制程序和源代码。这些代码和我们商业使用的代码完全相同，因此从技术角度来看，尽管可以进行 rebuild，但实际上并无必要。

社区：关于企业版的小版本发布，以前需要进行 release 的测试，现在不再需要额外的小版本的 release 测试了，这是因为我们现在更有信心吗？

张家驹：事实上，我们每天都在进行测试。我们改进了整个研发流程，只添加一个补丁就会运行所有的自动化测试。所以，关于小版本的问题，从 CentOS Stream 到 RHEL 只是一个选择过程，这个选择是基于时间而与稳定性无关，然后在 Release Note 中会明确在小版本中修复了哪些补丁。

周荔人：对于希望继续使用的人来说，他们应该具备筛选 CentOS Stream 中全量代码的能力，如果能做到这一点，实际上没有发生什么变化，只是需要付出一些额外的努力吗？

张家驹：是的，而且我认为 CentOS Stream 的方式实际上是在教你如何去“打鱼”，即“授人以渔”。在当前的大环境下，我们都希望自主学习和掌握更多的知识。如果没有 CentOS Stream 这种方式，尽管你最终可以获取 Red Hat 的二进制和源代码，但你不知道这些是如何生成的。但是现在，你可以看到每一个步骤，我遇到了什么样的 Bug、然后是如何修复的，有哪些讨论，最终如何制作这个产品，所有这些你都可以看到。所以，这种开放的方式在我看来是非常重要的。

周荔人：现在官方是否支持企业版本的跨大版本升级？

张家驹：是的，我们一直支持跨大版本的升级。

周荔人：尽管 CentOS Stream 8 的维护周期可能要比 RHEL 的版本短得多，那么在 Stream 8 的维护周期结束后，RHEL 的代码会存放在何处？

张家驹：虽然 CentOS Stream 8 可能停止维护，但 RHEL 的小版本分支依然存在。例如，尽管 Stream 8 可能在 5 年后停止维护，但如果某个版本需要 10 年或者 14 年的维护期，该版本仍然可以继续维护。尽管我们不再在 Stream 8 上新增内容，选择将其放在 Stream 9 上，但这并不意味着 Stream 8 就会消失，它仍然在主线中存在。

关于 CentOS 和 RHE L 的差异，许多人误解了两者的关系。在过去，许多人以为 CentOS 与 RHEL 的生命周期不一致，就像几年前的 CentOS 5 和 CentOS 6，它们的生命周期确实比 RHEL 短。然而，实际上这种现象在 RHEL 和 Stream 之间也存在。

Red Hat 作为一家商业公司，不可能完全以非商业的原则运作。因此，对于长期维护老版本的支持，是我们的核心价值之一。

周荔人：因此，我们需要从商业角度出发，而不仅仅是从开源的理想出发。从商业角度看，Red Hat 的决策目的是在商业上获得更多利益，对于任何企业来说，这都是无可厚非的。但是，对于开源社区和开发者来说，Red Hat 的决策也是有益的。

张家驹：这个世界并非非黑即白，有人会问，Red Hat 是完全为了公益而努力，还是出于商业利润？这是两个极端。作为一家以开源为主要业务的公司，我们的社区情怀和盈利目标是可以并行不悖的。例如我们停用了 git.centos.org，但并未完全基于商业考虑。如果完全出于商业考虑，我们可以选择不开放 Stream。实际上，我们为社区做了更多贡献。所以，我们的决策旨在繁荣社区，使社区更健康，同时作为企业，也要获得我们应有的利益。

周荔人：当这个事件刚出来的时候，许多媒体只是在哄抢，但实际上，从商业角度看，这并无不妥。只是时代变了。家驹老师，您还有其他想分享的吗？

张家驹：很多人都有自己的自媒体平台，各种声音很多。我说的这些大家可以自己判断，可以选择信或者不信，但是你可以去尝试。对于 Stream，我们实际上是通过提供工具，帮助你学会“钓鱼”，而不是直接给你“鱼”。这就是我们为社区做的事情。如果你只是想“吃鱼”，而不愿意学习“钓鱼”，那是另外一个问题。

最近，中国开源软件推进联盟(COPU)举办的一次会议，请到了 Linux 基金会的 Jim Zemlin，他讲得非常好。基金会主要是为了服务于 Linux 内核的那 100 个最核心的开发者，这并不是说不考虑用户，你不能完全黑白化地去看待这个问题。最核心的是，如果没有这 100 个人的贡献，我们很难有今天的 Linux。正如 Red Hat Mike 文章中所说，“很多开发者在 backport 中做了很多贡献，我们必须为他们的付出给予回报”。

周荔人：Red Hat 关注并致力于服务其有价值的客户以及对其产生贡献的开发者。这些都是 Red Hat 的核心关注对象，反观那些只想获取源码而无任何贡献的用户，Red Hat 可能并非其首选的服务提供商。

张家驹：对于这类用户，我们也为其提供了选择的权利。请参考 Mike 的博客，其中阐述了我们对于开发者或者学生等没有经费预算的用户，有提供免费使用途径。事实上，我们的用户注册过程极为简便。

我们始终遵循将代码发送到上游的原则，即“upstream first”原则，以及遵守开源许可证协议，如 GPL。我们首先将代码发送到上游，然后再反向移植到我们的产品中，这一过程与我们的商业逻辑紧密相连。

有些公司可能会选择“open core”模式，也就是将开源代码作为营销的手段，而将最核心的代码保留在自己手中。但 Red Hat 的做法并非如此，我们坚信将所有优质的内容推到社区，随着社区的繁荣，我们基于社区的开源项目，将其转化为产品并提供服务，从而实现自身的价值。

GPL 的协议仅要求你的代码开放，而我们做得更多，我们推动了“upstream  first”和"backport"的做法。如果你没有"upstream first"，那么也就不存在"backport"。如果所有人都不将他们认为好的东西推到上游社区，那么上游可能只是一个空架子，这样从上游再反向移植到你自己的版本，就变成了一个笑话。我们认为"backport"是商业发行版的核心价值，因此我们始终遵循"upstream first"原则。这就是其中的逻辑。

可能有些了解 Red Hat 的人认为这是理所当然的，但我还是想强调一下：Red Hat 的商业发行版 RHEL 的代码是 100%开源的，不存在任何闭源代码。而 Red Hat 公司能 100%开源并且依然盈利、持续生存下去，实际上跟我前面讲的“upstream first”和“backport”是息息相关的。

周荔人：Red Hat 已经不仅仅是一个 Linux 操作系统的发行版厂商，而是一家混合云服务供应商。服务是 Red Hat 的核心业务，这也是 Red Hat 能够盈利的主要原因。

张家驹：我认为，CentOS Stream 的稳定性完全有保证。然而，如果您是一名基础用户，对 Linux 一无所知，只希望享受原厂商提供的全面支持，那么情况可能会有所不同。尤其是大型企业，它们有许多决策无法独立作出。尽管 CentOS Stream 的稳定性得到保证，但企业用户不能向其他部门解释所有细节。对于这样的典型企业需求，选择 RHEL 版本可能会更好。实际上，RHEL 就是为企业级用户提供的。

这时，我们可以换一个思考角度。如果 Red Hat 有所变化，您可能会选择另一家供应商。但是，如果这家供应商提供的是商业发行版，那么他们也一定会收费。没有商业发行版是免费的。因此，你需要对比 Red Hat 的商业发行版 RHEL 和其他公司的商业发行版，以确定哪个更符合你当前的业务需求，包括兼容性、稳定性和开源性等因素。

无论是预算有限，还是团队能力强，你可能不会使用商业发行版。比如许多大型互联网公司，他们很少使用商业发行版。对于这些商业发行版，实际上并不需要过多解释，因为我们都是业内人士。在明确的情况下，讨论 CentOS Stream 对我们是否有价值，其实都非常实在。