紅帽：我們為什麼要改變RHEL源碼的發布策略？

當我們討論發行版的上游和下游時，有一些專業術語需要解釋，如"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 對我們是否有價值，其實都非常實在。

C# 和 Type 之父親自帶隊開源 TypeChat，又一 AI 技術瓶頸被攻破？

終於找到 ChatGPT 「智商」下降的原因了！OpenAI 側面回應，GPT 可能真被你們玩壞了？

微信取消秋招；谷歌軟體工程師基本年薪超 500 萬；通報批評員工到點下班？比亞迪回應 | Q資訊

十年磨礪，持續闖入「無人區」，這家公司如何做好金融科技？