如何評估一個 Linux 發行版的總體成本 | 開源之道

開源之道引言：為什麼要翻譯十一年前的一份白皮書？

（本白皮書發表於 2008 年。）答案很簡單，就是要學會算經濟賬，一個開源專案，尤其是大型的、經過多年開發的，企業利用該專案就要在開始的時候算好一筆經濟賬，它不是零成本，它像一個快速向前滾動（發展）的巨大磁石，如果你沒有投入，那麼很快便失去了任何的話語權，經過一段時間，則會被狠狠的甩下，體無完膚！不僅失去了創新的能力，而且成為了自己最大的負擔。最後以失敗而告終。

如果單單的只是將專案的某個時間的臨時性成果來作為自己的產品或服務，那麼就要想好要不要跟上步伐，要怎麼跟？不過這些都要基於一個基礎：這個階段性的成果總成本是多少？該如何評估？於是就有了這篇文章。

介紹

Linux 作業系統是歷史上最為成功的開源專案，但是一個 Linux 發行版中的軟體究竟“價值”多少錢？2002 年，David A. Wheeler 發表了一份備受後人推崇的研究，其指出典型的 Linux 發行版中軟體程式碼行數的意義所在。那麼他的發現是什麼？結果令人震驚：典型的 Linux 發行版中的總開發成本高達 12 億美元。我們將基於 Wheeler 先生的發現而繼續挖掘。使用相同的工具，我們重新以當前的美元來計算，構建 Fedora 9 發行版的成本需要大約 108 億美元。另外，僅核心一項的開發需要約 14 億美元，本論文概述了我們研究過程中使用的技術，並指出開發 Linux 的成本計算樣式。

Linux 作業系統是當今計算中最流行的開源作業系統，在 2008 年，它意味著是一個價值 250 億美元的生態系統。¹ 自 1991 年建立以來，它已發展成為計算機領域的一支重要力量，為紐約證券交易所、移動裝置、超級計算機、消費裝置提供重要的驅動力量。

作為一款開放的作業系統，Linux 是協同開發的，這意味著沒有任何一家公司對其開發或持續的支援負全部責任。參與 Linux 開發的公司與其合作伙伴、競爭對手分擔著研發成本。這樣的開發樣式進一步發展為個人和公司共同承擔，進而成為一個超大型的、生機勃勃的生態系統，而且驅動著無窮的創新力量。

超過 1000 多名的開發者，他們來自不同的公司，公司數量至少在 100 家左右，僅在過去兩年中，來自 200 家公司的 3200 多名開發人員就為核心做出了貢獻。² 值得註意的是，核心只是 Linux 發行版的一小部分，一款完整的 Linux 發行版，不僅包括核心，還有諸如 GNOME 和 KDE 桌面環境、GNU 元件、X Window 系統等等很多元件。為這些專案做出貢獻的個人開發者總數肯定會達到數千人。

正因為 Linux 是協作開發的，因此無法從某個單一的來源來估算開發該專案的成本。2002 年，David A. Wheeler 發表了一項備受好評的研究，該研究檢查了典型 Linux 發行版中存在的軟體程式碼行（基於 Red Hat Linux 7.1）。³ 他總結說 —— 正如我們所做的那樣 —— 軟體程式碼行數是確定開源軟體價值最實用的方法，因為它專註於最終結果而不是每個公司或每個開發人員的估算。⁴ 使用他開發的用於計算和分析 SLOC（軟體程式碼行數Software Lines of Code）的行業標準工具，他確定在美國透過傳統的封閉方法開發 Linux 發行版將花費超過 12 億美元。

但那已經是 6 年前的事情了，由於 Linux 的創新和增長速度每年都在增加，因此我們有必要更新這個 12 億美元的數字，從而希望能夠準確反映當今 Linux 中開發的真正價值（以及軟體開發本身的成本上升）。在本文中，Linux 基金會著手確定典型 Linux 發行版中所代表的總開發成本，並更新自 2002 年釋出以來廣泛使用的 12 億美元數字。

我們分析了 2008 年 5 月 13 日釋出的 Fedora 9 發行版。之所以選擇 Fedora，因為 Fedora 是一種流行度蠻高，口碑也還行的 Linux 發行版，它也是紅帽企業版 Linux 的原型，而紅帽企業版 Linux 則是擁有 Linux 市場的很大份額的發行版。更何況還是 Wheeler 在其原始論文中分析的 Red Hat Linux 7.1 軟體的直接後代。

在本研究中，我們使用了 David A. Wheeler 所開發的 SLOC 工具 —— SLOCCount。SLOCCount 用到了行業標準的建設性成本模型COnstructive COst MOdel（COCOMO），該模型是一個演演算法軟體成本估算模型，⁵是由 Barry Boehm ⁶ 開發的。該模型使用基本回歸 ⁷ 公式，其引數衍生自歷史專案資料和當前專案特徵資料。⁸ 我們從 2002 年開始更新他的研究，包括不斷增長的 Linux 核心程式碼庫和其他軟體包，以及軟體開發人員的薪水。（關於此的更多細節將在下文的“方法論”部分中進行詳細討論。）

基於該方法，如果是採用傳統的封閉方法來開發這樣一個規模的 Linux 發行版的話，我們估計需要 108 億美元（2008 年）。

方法論

我們的基本方法是：

如果大家對於我們是如何安裝和分析原始碼感興趣的話，請參閱附錄內容。

為了延續原作者的研究，我們決定使用和 2002 年所採用同一套基礎程式碼，即選擇了 Fedora 社群發行版，這也是紅帽企業版 Linux（RHEL）的基礎平臺。經過一番考量，我們決定採用 Fedora 9 這個版本。我們統計了所有在 http://mirror.kernel.org 映象歸檔檔案中公開的 Fedora 9 軟體包。之所以選擇這個源，是因為我們不想我們最終衡量的結果被其它因素所影響。Fedora 包含比紅帽企業版 Linux 更多的軟體包，其中一個原因是多元化社群參與構建 Fedora，而不僅僅是一家公司。使用 SLOCCount 應用程式是一項相對簡單的任務：只需將其指向原始碼所在的正確目錄，然後讓它執行即可。在 Wheeler 的網站上仍然提供有關程式如何工作以及如何使用它的詳細說明。⁹

欲計算該發行版的開發成本，我們從美國勞工統計局查閱了計算機程式員的基本工資概況。根據美國勞工統計局的資料，2008 年 7 月美國程式員的平均工資為 75,662.08 美元。 ¹⁰ 這也是我們的 SLOCCount 執行中使用的工資金額。（當然，如今大多數軟體開發都是全球性的，因此使用僅限美國的工資數字有點以偏概全。然而這時一個值得我們持續探索的主題，在未來我們要找到一個途徑來確定全球平均工資，將之作為生產成本的基準。）

還應該指出的是，薪水本身並不是軟體開發成本的唯一決定因素。在他的文章中，Wheeler 提及了 SLOCCount 中的開銷引數，其中包括測試成本、裝置、公司運營成本以及開發人員的總賠償金。這些引數被稱之為總包比例wrap rate。

要知道這些總包比例的增長是非常之迅速的，在美國，專業員工的平均薪酬百分比（病假、休假、保險福利）為 29.0％。¹¹ 因此，雖然我們剛才所提及的美國勞工統計局給出的資料是程式員的平均工資為 75,662.0810 美元，但是企業主實際要付的數字為 97,604.08 美元。而且這隻是總包比例的一部分。

Wheeler 當年的評估將總包比例的值設為 2.4。雖然這個數字明顯因公司和地區而異，但進一步的研究顯示，沒有任何重要證據表明這個數字需要在我們所測試中進行調整。

原始碼和估計成本結果

根據前面所示的所有假設，Fedora 9 的 SLOC 和估計產量值如下。

旁註：最初的 SLOCCount 年薪數字是 2000 年 $56,286 美元，有心人可以看到我們對此進行了相應的轉換。為了實現它，我們將總費用乘以 2008 年美元（10,784,484,309 美元）的 0.744，這是 SLOCCount 通常使用的 2000 年程式員工資（$56,286）與我們發現的 2008 年 7 月工資（$ 75,662.08）之間的比率。結果是 2000 年開發 Fedora 9 的成本超過 80 億美元。這使讀者很好地瞭解了這六年中 Linux 發行版中添加了多少程式碼和功能。

聚焦 Linux核心，及其增強 COCOMO 模型

正如本文的研究改寫的內容，聰明的讀者一定發現了，並非所有 Linux 系統中所有的元件都需要得到同等的對待。根據 COCOMO 模型，一些專案的性質和複雜性需要不同的考慮。

這一點在 Wheeler 自己的 2002 年文章的後續行動中更為明顯，他強調了對 Linux 核心就應該使用的不同估計模型。¹² 在這篇新文章中，Wheeler 堅持認為，由於 Linux 核心程式碼通常比“普通”應用程式更複雜 —— 特殊的除外 —— 它需要的分析超出了基本的 COCOMO 模型。例如，像 Mozilla 這樣的使用者空間應用程式更容易逐行編碼，因為它在更高的層次上被抽象，並且只需要處理更少的任務。然而，現代企業級作業系統核心則需要同時執行大量極其複雜的操作，也就是說技術含量更高、難度也更大。

所以 Wheeler 解釋說，發行版中的元件不能使用同一種標準的方法來進行分析，就核心來說就應該使用增強 COCOMO 模型intermediate COCOMO model來進行衡量。增強的 COCOMO 模型有更多的引數供選擇，因此，應該更準確地分析一個複雜的軟體本身。在 2004 年的文章中，他詳述了他對這些引數的評估細節，即調整整體的凈效應，將 SLOCCount 中的工作因子值從預設值 3 到 4.64607，同時，-effort 指數值也變為 1.12，在增強的 COCOMO 軟體估算模型下，這是分配給半分離軟體semi-detached software專案的值。

基於這些新的引數，針對 Linux 核心做了一個單獨的評估（Fedora 9 的核心版本是 linux-2.6.25.i686）：

本研究方法的侷限性和優勢

沒有完美的方法來估計像 Linux 那樣複雜和不斷發展的軟體專案的價值。雖然我們認為這種方法是最好的方法，但它可能過度計算價值的某些方面，而低估了其他方面。以下是我們認為該方法存在限制的部分：

Linux 是如何增長的

本研究還沒有考慮逐步更新和擴充套件 Linux 程式碼庫的年度開發成本。基於這些數字（或任何人對 Linux 發行版的直接經驗），很容易看出 Linux 發行版中包含的功能在過去六年中是如何以爆炸般的形式發展的。

例如，Fedora Linux 9 包含超過 2.04 億行純的原始碼（SLOC），相比之下 Red Hat Linux 7.1（2002 年釋出）才是區區的 3000 萬行，而再往前的版本 6.2 中只有超過 1700 萬行。程式碼庫在過去的六年裡，增加了 1.74 億行程式碼。使用 COCOMO 成本模型，我們估計 Fedora 9 需要大約 60,000 人年的開發時間（相比之下，Red Hat 7.1 為 8,000 人年，而 6.2 版為 4,500 人年）。因此，與 Red Hat Linux 7.1 相比，Fedora 9 的大小增加了大約 680％，工作量增加了 750％，傳統開發成本增加了 900％。背後的原因之一則是由於過去幾年全球範圍內可用的、成熟的開源/自由軟體程式數量的增加。這種增長表明 Linux 具有更大的發展勢頭：不斷增加開源軟體包可以增強 Linux 使用者可用的應用程式，反過來也使得 Linux 作為計算平臺更具吸引力。

透過審視發行版中排名前十的軟體包串列，我們可以輕易得知，（構成發行版的）Linux 的模組化是它本身的特性。如果有時間的話，這個特性的分析本身就是十分有趣的事情，比如，就拿嵌入式 Linux 的發行版來說吧，分析其使用最頻繁的元件以及與該計算部分相關的開發成本會很有意義。

對於 Linux 創新的影響分析來講，不能僅僅透過線性的程式碼增加來進行衡量。正如近來釋出的“是誰在撰寫 Linux 核心？”的報告中所稱：”在已經釋出的版本中，核心團隊每年的增長率非常穩定，約為 10％，考慮到程式碼樹的大小，這個數字非常可觀。但是這不僅僅是程式碼數量上的增長，還有實際功能、效能等諸多的其它因素的改進和進化，因為每一次的變更都意味著程式碼的增加、刪除、修改。” ¹⁴

雖然 Linux 核心與 Linux 發行版當中的大多數其他元件相比，可能更改的更為頻繁，但是從整體而言，我們的資料也反映出整個 Linux 發行版每年都在不斷增長和變化。由於 Linux 核心只是 Linux 發行版的一個小（但非常重要）元件，其每年投入的迭代開發成本非常的高，但在本次研究中還沒有將其進行特別的處理。

總結

那麼在閱讀完這篇研究之後，你知道 Linux 的”價值”所在了嗎？雖然它可能還不是一個能夠完全回答的問題，但有些事情非常明確，那就是：Linux 的真正價值在於它重用它的能力以及它所創造的巨大靈活性。

想象一下，假如在一個 Linus Torvalds 不允許（實際上是迫使）Linux 使用者允許其他人重覆使用他們的貢獻的計算世界。如果他們沒有免費使用 Linux 並且能夠根據他們的需求修改它，那麼會不會有谷歌？如果沒有可以免費使用的價值 108 億美元的軟體，是否會有不斷擴大的低於 350 美元的新型超便攜電腦？亞馬遜是否能夠建立其新的 Kindle 閱讀裝置系列，而無需為其提供 14 億美元的免費研發費用？而且不能單單以金錢來衡量，Linux 發行版還意味著時間這個巨大的經濟因素，如果這些公司被迫向任何一家公司支付每臺裝置或每臺伺服器的許可費，那麼這些例子中的經濟學就不可能實現，那麼他們就不得不花費數千人年的開發時間來建立這個軟體。

我們可以從這項研究中學到什麼？基於社群的 Linux 發行版所代表的大量開發成本反映了其在計算領域日益增加的價值和重要性。公司和個人透過參與 Linux 相關的專案，公司透過同行（有時是競爭對手）分擔開發費用，進而創造自己的利潤。軟體世界的一個越來越明顯的事實是，像微軟那樣，單獨承擔這種研究和開發負擔是一種昂貴的構建軟體的方法。雖然過去的壟斷地位使他們能夠為這一巨大的發展提供資金，但我們深信，隨著時間的推移，未來來自合作力量的競爭將使這種孤立的做法變得難以為繼。

正如我們從這項研究中看到的那樣，透過 Linux 在所有計算領域的爆炸式增長，協同開發創造了巨大的經濟價值！諸如 IBM、Intel、HP、Fujitsu、NEC、Hitachi、Google、Novell、Oracle、RedHat 等公司，以及其它所有參與到開發中的公司，他們均從這個開放式軟體開發的生態中找到了自己的利益立足點。但是，請務必澄清：當這些公司參與且貢獻較大時，請不要忘記獨立的個人參與的開發和造就的價值是同等重要的！要知道，所有這一切都是從個體開啟的。

本文中的資料由 SLOCCount 生成， SLOCCount 的版權 © 2001-2004 歸 David A. Wheeler 所有，SLOCCount 是開源軟體/自由軟體，基於 GNU GPL 許可協議。

SLOCCount 沒有任何的擔保，非常歡迎大家基於 GNU GPL許可下自由的分發該軟體，欲瞭解 GPL 的內容，去閱讀相關檔案。

致謝

我們要感謝以下人員對本文的審核和反饋：James Bottomley、Jon Corbet 以及 David A. Wheeler。

作者介紹

Amanda McPherson is vice president, marketing and developer programs, at the LF and leads its promotion, developer, and community-relations activities.

Brian Proffitt is community manager with the LF, managing the Linux Developer Network.

Ron Hale-Evans is senior specifications writer with the LF and works closely with the Linux Standard Base (LSB) developer team to create LSB specifications.

附錄

Fedora 9，其安裝盤並沒有包含原始碼，所以我們的程式碼是從 http://mirrors.kernel.org 上下載的。因為確定要分析的檔案會在流程中進入另一層次的主觀性，所以決定將所有 5547 個可用的開源軟體包（src.rpm）下載並安裝在測試機器上。

從 FTP 伺服器下載 src.rpm 後，就可以安裝它們了。即使沒有任何 rpm 作為二進位制 RPM 包安裝（因此可能實際只是做為測試機器上安裝的應用程式），也建立了一個程式來允許構建和準備原始碼的 RPM，而無需 root 訪問許可權，修改發現的過程在一個存檔的 Red Hat howto 頁面上。

原始碼已下載到測試使用者的主目錄。

然後使用 gedit 建立一個指令碼並將其儲存為同一主目錄中的 .rpmmacros。建立了標的目錄集，然後使用以下命令安裝 src.rpm 檔案：

1. rpm -ivh *.src.rpm

經過一段時間後，安裝了所有 5547 個軟體包，規範檔案（.spec）位於 rpm/SPECS 目錄中，源檔案和圖形填充了 rpm/SOURCES 目錄。

在此階段，必須構建和準備 src.rpm 檔案，這將所有應用程式的原始碼一一對應地放到 rpm/BUILD 目錄中自己的目錄。為此，使用了以下命令：

1. rpmbuild -bp –nodeps *.spec

執行此命令後，所有軟體包都已在 BUILD 目錄中正確安裝。

然後可以開始實際計數。因為發行版不是單個軟體專案，所以不應該這樣計算。SLOCCount 提供了一個引數來補償： -multiproject。

對於 Fedora 9，使用的命令是：

1. sloccount –multiproject –personcost 75662.08 /usr/src/rpm/BUILD/ &> sloc.txt

如需進一步檢查，以下是 Fedora 9 原始碼中的前 10 個軟體包的統計數值，（供參考）：

參考資料