從日前召開的re:Invent發布會上可以看到，雲服務巨頭AWS對於供應商驅動的開源項目仍持謹慎態度，主張對所有開源依賴項進行業務健康檢查。這也可以理解，畢竟極具影響力的CentOS停止開發之後，AWS對於Amazon Linux的計劃也被意外打亂。
David Nalley是AWS開源戰略與營銷總監兼Apache軟體基金會總裁。「我的職責範圍幾乎涵蓋AWS的所有開源項目。」
與EC2（Elastic Compute Cloud）虛擬機的其他發行版相比，Amazon Linux用起來到底有什麼優勢？Nalley解釋道，「長期以來，Ubuntu都是人們首選的主要發行版。我們也與許多不同發行版保持合作，以確保其運行良好。」
FreeBSD也是一個選項。「我跟FreeBSD發布經理直接交流，討論為FreeBSD開發AMI（Amazon Machine Images）。我有種直覺，Amazon Linux應該會得到更好的支持，畢竟它的開發團隊就是亞馬遜的內部員工。」
Amazon Linux 2023（最終也在AWS之外發布）面對的一大障礙，就是無法支持EPEL（Extra Packages for Enterprise Linux），但其前代版本Amazon Linux 2卻能夠支持。考慮到EPEL軟體包的重要性，為什麼會有此變化？
Nalley解釋道，「不同之處，在於Amazon Linux之前基於CentOS。CentOS擁有一個充滿活力的社區，貢獻者們會打包大量軟體。但在Amazon Linux的最新版本中，我們通過重構將Fedora設為新的基礎。」
而原因很簡單，CentOS已經停止開發。「這就很尷尬了。其實打包工作本身並不困難，對大多數貢獻者來說，只要能獲得源rpm，就能輕鬆把它構建到別的發行版當中。我自己就曾經幫Fedora做打包工作。」雖然偶爾也會出現問題，但「對於絕大多數軟體包來說，保證源rpm還在更新就足夠了。」
另一個障礙在於，如果需要加裝安全補丁，則必須重複整個過程，而且發行方往往不會解釋到底為什麼需要更新軟體包。「沒錯，維護負擔需要由下游承擔。」
為什麼不能讓Amazon Linux從一種發行版就地升級成另一種？Nalley表示，「我們一直致力於打造一套穩定的平台，而就地升級在本質上就不夠穩定。要想升級glibc或者llvm的底層版本、同時在各個版本之間保持穩定和安全，其實是非常困難的。」
但這個問題影響的主要是那些小體量客戶。「掌握完善架構的客戶已經在使用基礎設施即代碼來定義這些實例的外觀，因此可以輕鬆啟動新實例，轉移原本部署在舊實例上的軟體，檢查是否能正常運行，最後把實際工作負載遷移過來。就這麼簡單。」
那麼，Linux 2023為什麼花了這麼長時間才發布？畢竟Amazon Linux 2已經相當陳舊、嚴重過時，而繼任者卻遲遲沒有出現。Nalley稱「這當然是有理由的。」
「我們不想發布還沒準備好的東西。我們正在對底層發行版進行根本性的重新調整。Amazon Linux 2維持著良好的安全補丁和支持，這對較舊的產品來說無疑是個挑戰。而且受架構問題影響，Linux 2023的發布時間晚於預期，我們曾先後多次宣布推遲。」
但眾所周知，Fedora是個快速發展的發行版，而Amazon Linux則向來以穩健著稱。這會讓雙方的合作關係發生衝突嗎？Nalley提到「肯定會有影響，跟我們以往使用CentOS時的情況不同。」
「但我們喜愛Fedora的原因之一，就是它始終在以極快的速度推動創新。我們認為Fedora為我們提供了一個更好的平台，而且我們會將支持周期延長到遠超Fedora官方支持的水平。Fedora的發展速度確實很快，當初新發布的CentOS版本都跟不上它的節奏。」
AWS與開源
考慮到催生出OpenSearch的Elastic等項目，AWS與開源社區之間的關係正在走向何方？
Nalley認為，「每一家使用開源軟體的公司所獲得的收益，都遠遠超出他們所付出的資源。這已經是個普遍真理了。」
每一家使用開源軟體的公司所獲得的收益，都遠遠超出他們所付出的資源。
「我確實認為AWS對於開源的理解和雙邊關係正在發生變化，而其中一些變化源自我們對開源發展的深刻理解。以往，大多數開源項目都完全由社區主導，包括Apache Web伺服器以及Linux核心，人們出於共同的使命感而走到了一起。但如今許多創新產品的出現，正逐漸轉向由廠商控制的開源軟體項目。對於這兩種形式，我們當然不能以同樣的方式看待，也不能指望以同樣的方式享受這兩類成果並期望獲得類似的效果。」
「我們對開源的理解已經開始轉變，並意識到一切依賴關係都必須匹配相應的風險衡量與評估。我們要如何確保所依賴的開源項目還能繼續存在、長期發展？Apache Web伺服器或者Apache Tomcat當然值得託付，但其他廠商主導的軟體包則可能各有不同的考量因素。問題的實質，在於社區的多樣性與健康狀態。我們正在積極研究這個問題，希望建立起更加穩定可靠的依賴關係。」
AWS本身也掌握著不少開源項目，比如SDK，這些項目主要由內部工程師推動、而非由社區所主導。Nalley解釋稱，「當我們發布軟體時，AWS會出於多種考量而使用開源成果。」
「其中之一在於，從智慧財產權（IP）的角度來看，開源許可證確實更容易理解。如果採用了基於Apache許可證或者MIT許可證的某些成果，公司的律師會覺得比較容易把控，而且可以預先批准引入這些許可證。我們已經在開源許可之下發布了很多項目，也並不指望能由此建立起相應的社區。」
但也有一些例外情況，比如現在已經被貢獻給雲原生計算基金會（CNCF）的AWS Karpenter項目。Nalley提到，「微軟就曾表示他們很喜歡Karpenter。」
「但微軟喜歡Karpenter的前提，就是該項目不能由亞馬遜一手控制。所以我們開展了內部對話，討論如何把Karpenter捐贈給CNCF會怎麼樣。現在它已經是個孵化項目，並且正在培育自己的社區。」
根據Nalley的介紹，另一個被他人以「意外但卻令人滿意的方式」接納的AWS開源項目是Bottlerocket，一款輕量級容器Linux發行版。「我們之所以開發這個項目，是為了在其之上構建Lambda。但也有一些客戶正利用它嘗試一些我們從未想到過的絕妙點子。」
面對眾多開源項目那糟糕的商業模式，AWS是否會感到擔憂？Nalley嘆了口氣，強調「其實每個服務團隊在審視自己的依賴項目時，都會考慮這個問題。」
「在AWS內部，我們建立了明確的戰略開源項目概念。我們要求服務團隊內的部門負責人每季度上報這些項目的運行狀況。這樣做，當然是為了確保項目所有者仍然關注自己的成果。我們不希望看到某些特別重要的技術要由住在地下室里、領著低保救濟的人來維護，這不符合我們客戶的最佳利益。」
AWS在消費公共開源項目時，要如何防範代碼篡改風險？Nalley表示「我們的創作者體驗團隊維護著一套內部軟體包repo」，同時也會審查軟體來源和許可證等內容。
他最後總結道，「這樣我們就能在出現安全問題迅速響應，跟蹤所有使用到該軟體的場景。」
