1.3.4 開源軟件的供應鏈

當今的軟件開發(fā)，為了快速提供軟件功能，沒有人會從零開始去編寫每一行代碼，開源軟件可以提供成千上萬個功能，從開源軟件中尋找并引用一些成型的功能，將大大加快開發(fā)人員的創(chuàng)新速度，這便在基于開源軟件的項目中引入了隱形的供應鏈關系。

由于開源軟件的廣泛運用和云原生時代的到來，基礎架構越來越復雜和多樣化，即使是同一個開源軟件，每個公司的架構方式和實施方式也會存在差異，選用的周邊配套組件也不盡相同。雖然開源軟件本身不存在使用權的限制，但是在全球復雜的政治、經(jīng)濟格局下，開源軟件供應鏈中只要有一個環(huán)節(jié)出現(xiàn)中斷，最終也會像工業(yè)制造的供應鏈一樣，波及最終的使用端。軟件供應鏈出現(xiàn)問題，不僅新的軟件供應會受到影響，甚至會直接影響到當下正在使用的軟件的可用性。

軟件的開發(fā)過程不像物品的制造過程，不需要供應鏈的上一環(huán)節(jié)每次都把生產(chǎn)出來的產(chǎn)品交付給下一環(huán)節(jié)，因為軟件一經(jīng)生產(chǎn)完成，你就可以無限次地部署和使用它，不再需要供應鏈的參與。但實際上，軟件需要安裝，出了問題需要有人服務，存在缺陷需要有人修復，這些環(huán)節(jié)也是供應鏈的過程。進一步講，對于企業(yè)版的開源軟件，提供授權許可就是供應鏈中的一環(huán)。

只要基于開源軟件的源代碼進行編譯，得到二進制安裝和運行文件或者使用社區(qū)提供的可運行文件，就可以自由使用開源軟件。這個供應鏈從表面上看非常簡單，但實際上開源軟件有著更為復雜的供應鏈結構。

開源軟件的源頭是開源項目，但事實上，開源軟件供應鏈的源頭起始于不同領域的開源軟件基金會。作為某一領域開源軟件方向的主導者，雖然多數(shù)基金會自身并不直接制定技術標準，但是基金會組織、引導并孵化該領域中的開源項目，這樣的過程最終會形成一種事實標準，并且基金會本身畢竟是一個經(jīng)國家批準的實體組織，依然要受注冊國的法律約束。

很多大型開源軟件要引用和集成幾十甚至上百個其他開源軟件，比如Linux操作系統(tǒng)就是把Linux Kernel通過Fedora、openSUSE、openEuler等若干不同的發(fā)行版，將應用、工具、類庫、各種運行時集成在一起，形成安裝即可用的操作系統(tǒng)。如今，沒有人會為了用Linux操作系統(tǒng)而從一個Linux Kernel開始做搭建。其他類似的系統(tǒng)還有很多，如AI平臺、容器平臺，大的集成性開源項目往往會關聯(lián)眾多的其他開源項目。

開發(fā)開源軟件的社區(qū)本身并不會為用戶提供技術服務和各種商業(yè)化的發(fā)行服務，比如廣泛的兼容性測試、產(chǎn)品手冊，甚至是安裝和升級工具。沒有足夠技術積累、人力資源和使用規(guī)模的商業(yè)用戶很難自己完成這類工作，這時一些IT公司擔當起開源軟件服務商的角色。比照以往的傳統(tǒng)軟件，軟件服務商可以分為兩類。第一類是軟件的發(fā)行商，這類服務商既可以提供軟件的日常使用類的服務，也可以提供缺陷修復類的服務，發(fā)行商掌握軟件的源代碼，能夠將運行代碼中的故障還原到源代碼的準確位置并進行修改，幫助用戶進行根因分析。第二類是掌握了該軟件技術能力的服務商，可以提供日常使用和配置類的維護，根據(jù)已知故障和修復方法，幫助用戶嘗試解決問題。但是由于這類服務商不具備對軟件源代碼的維護能力，因此他們無法幫助客戶進行代碼級的故障排查。但是對于開源軟件，這一狀況就發(fā)生了變化，開源軟件的源代碼是公開的，得到源代碼的服務商即使不是該軟件的主要開發(fā)者，也可以通過源代碼幫助客戶進行根因分析，并將修復的內(nèi)容提交到社區(qū)以徹底解決軟件故障。只要服務提供者能夠編譯該軟件的源代碼，并能夠復現(xiàn)編譯過程，就能夠提供該開源軟件的全面服務。

前文中提到了代碼庫，作為開源軟件承載的載體，代碼庫也是供應鏈中重要的一環(huán)。為開源軟件提供代碼庫的機構往往都是企業(yè)，這和基金會有所不同，企業(yè)會受到所在地政府更為直接的管控，政府有權限制企業(yè)服務于某個人、某個企業(yè)、某個地區(qū)，甚至某個國家。2019年，全球最大的代碼托管平臺GitHub更新了用戶協(xié)議，表示GitHub企業(yè)服務器及用戶上傳的信息要接受美國法律監(jiān)管。

所以，開源軟件供應鏈是否可以長期安全可控，是一件很復雜的事情。軟件不像硬件，存在性能接近的產(chǎn)品，可以直接替換使用。一個特定的開源軟件一定是唯一的，任何克隆或者仿制的結果都是一個獨立的新軟件，可能在開始克隆時兩個軟件基本相同，但是隨著時間的推移，兩者會存在越來越大的差異，無法做到既平行發(fā)展又保持高度一致。這就好比RHEL和SUSE Linux兩種流行的Linux操作系統(tǒng)，兩者都采用類似的架構、RPM包的安裝運行機制，相似度非常高，但是如果RPM包安裝錯了環(huán)境，應用也無法正常運行。

采用全新的供應鏈安全方式，不僅要看該軟件的供應鏈上游，還要看其下游是否能夠跟隨全新的供應鏈體系，這也是談到開源軟件的時候，生態(tài)建設遠比供應鏈可控更為重要的原因。在生態(tài)建設中，每一個參與方都應該是受益者，否則這個生態(tài)將無法長久存在，開源軟件的參與者可以是企業(yè)或者個人，但沒有誰完全依靠興趣和榮譽而為社區(qū)做貢獻。就像在前端開發(fā)方面非常流行的core-js項目，這是一個JavasCript庫，由Denis Pushkarev全職開發(fā)，在全球前10000個網(wǎng)站中，超過一半的網(wǎng)站在使用這個模塊，其中包括蘋果公司等大型公司。因為依靠目前的捐贈方式無法維持生計，Denis打算放棄對core-js的維護。在2015年之前，紅帽一直是Linux Kernel的最大貢獻者，但是Intel后來居上成為第一，其原因是參與Kernel項目讓Intel可以在第一時間把CPU的新特性推向市場，Linux的流行會帶來Intel CPU在企業(yè)端的廣泛應用。

對于最終用戶來說，最大的供應鏈安全是選擇上的自由而不是僅僅依靠信任來建立安全。與傳統(tǒng)軟件相比，開源軟件的變動更為頻繁，社區(qū)沒有義務為使用社區(qū)軟件的用戶提供軟件功能的連續(xù)性保障，因此在早些時候，經(jīng)常可以看到一些基礎開源軟件中已棄用的函數(shù)讓開發(fā)人員崩潰，甚至是一個開源項目突然銷聲匿跡。我們曾經(jīng)幫助一個有上萬臺服務器的客戶做了一個估算，是否可以把當前的操作系統(tǒng)A都替換成B，結果發(fā)現(xiàn)這是一件非常吃力又不討好的事情。雖然操作系統(tǒng)看起來不像數(shù)據(jù)庫那樣關鍵，不像中間件那樣和應用直接相關，不像開發(fā)框架那樣嵌入在應用代碼里，但是如果要更換操作系統(tǒng)，各種兼容性驗證、環(huán)境的參數(shù)還原、穩(wěn)定性測試，以及尋找切換的時間窗口，整個數(shù)據(jù)中心全年只能干這一件事，前提是業(yè)務應用開發(fā)部門會全力配合。

實際上，隨著云架構的廣泛運用，一些新的技術和管理方法能夠幫助企業(yè)來解決這類可能會發(fā)生的事情。基于容器化的部署、不可變基礎設施、模板化管理，再改變數(shù)據(jù)中心的系統(tǒng)構建模式，這不僅能使操作系統(tǒng)的更換變得更為容易，而且其他基礎設施的可替換性、中間件的可替換性都在大幅提升。企業(yè)需要盡快落地云架構能力，做到一切皆可換，才能真正實現(xiàn)“我的開源軟件供應鏈，我做主”，避免上游改道、下游遭殃的情況發(fā)生。