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

（本白皮書發表于 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 年）。

方法論

我們的基本方法是：

1. 以非壓縮格式安裝源代碼文件；這需要下載源代碼并在我們的測試機器上正確安裝。
2. 計算源代碼行數（SLOC）；這需要仔細定義 SLOC。
3. 使用估算模型（基于 COCOMO 實踐）來估算以專有方式開發相同系統的工作量和成本。

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

為了延續原作者的研究，我們決定使用和 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 那樣復雜和不斷發展的軟件項目的價值。雖然我們認為這種方法是最好的方法，但它可能過度計算價值的某些方面，而低估了其他方面。以下是我們認為該方法存在限制的部分：

• COCOMO 模型是研究封閉式軟件開發而設計的。因此，我們認為它低估了開源、協作開發的軟件項目（如 Linux）中固有的測試復雜性。由于變更的頻繁，且不論大小，而且開發者本身均是分布全球各地，Linux 生態系統參與者的測試負擔比專有的獨立公司高出一個數量級。
• 衡量 Linux 發行版價值的另一個困難就是確定開始時包含 Linux 發行版的內容。我們的研究包含了 Fedora 的公共源代碼庫中所有軟件包。但是，Fedora 本身也有不同的版本（例如 LiveCD 版本）。當然還有更大的發行版，例如，Debian GNU / Linux 的代碼倉庫 ¹³ 就比 Fedora 更大。還有大量的開源軟件在任何一個發行版中都找不到。開源是一個非常大的宇宙，我們只是以 Linux 發行版為研究單位，盡可能的包含足夠多的開源軟件罷了。
• SLOC 分析的弱點是它專注于軟件項目的凈增加。舉例來講，任何熟悉內核開發的人都會意識到，開發過程中的人力成本是刪除和修改代碼的時候。刪除和更改代碼所花費的精力，并未反映在與此估算相關的值中。因為在協作開發模型中，代碼被開發，然后被更改和刪除，真正的價值遠遠大于現有的代碼庫。聰明的你，想一下內核的開發流程：當幾行代碼添加到內核時，必須修改更多代碼才能與現有的代碼兼容。理解依賴關系和結果然后更改代碼的工作在本研究中沒有得到很好的體現。
• 協作開發意味著，通常會有多個個人或小組致力于解決相同技術問題的不同方法，其中只有一種方法“獲勝”而包含在最終版本中。 由于“失敗”方法并未包含在最終的發布版本中，因此該 SLOC 方法未考慮這些方法的開發工作。
• 由于 Linux 不同的發行版之間，以及同一個發行版的不同版本之間的代碼行數是有著巨大差異的，所以將本研究冠以研究 “Linux” 是有點牽強的。 分析內容有很多不同的選擇，我們只能選擇一種。出于這個原因，我們發現所有發行版共享的離散包的估計值（例如內核）更有意義。
• 很遺憾的是，我們只能以量來代替研究質。Linux 社區的壯大速度很快，但同時也包含了一些不被經常用到的代碼，比如舊的驅動程序。但是，包含此代碼非常重要，因為 Linux 中包含特定于體系結構的代碼以及驅動程序（與其他操作系統不同）。因此，此數字將大于操作系統本身內不包含這些組件的其他操作系統。
• 本研究假設所有開發者都來自美國，那么相應的就以美國勞動力的相關成本為基準來計算。盡管事實上，絕大多數的開源軟件開發都是全球性的，其勞動力成本也會相應變化。
• 本研究中反映的數字表示從頭開始一款 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 文件：

rpm -ivh *.src.rpm

經過一段時間后，安裝了所有 5547 個軟件包，規范文件（.spec）位于 rpm/SPECS 目錄中，源文件和圖形填充了 rpm/SOURCES 目錄。

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

rpmbuild -bp –nodeps *.spec

運行此命令后，所有軟件包都已在 BUILD 目錄中正確安裝。

然后可以開始實際計數。因為發行版不是單個軟件項目，所以不應該這樣計算。SLOCCount 提供了一個參數來補償： -multiproject。

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

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

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

參考資料

1. IDC “The Role of Linux Commercial Servers and Workloads”, 2008 ↩

2. Greg Kroah-Hartman, Jonathan Corbet, and Amanda McPherson, “Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It”, April 2016, https://www.linuxfoundation.org/events/2016/08/linux-kernel-development-2016/ ↩

3. David A. Wheeler, “More Than a Gigabuck: Estimating GNU/Linux’s Size” 2001 (revised 2002) ↩

4. http://en.wikipedia.org/wiki/Source_lines_of_code ↩

5. http://en.wikipedia.org/wiki/Estimation_in_software_engineering ↩

6. http://en.wikipedia.org/wiki/Barry_Boehm ↩

7. http://en.wikipedia.org/wiki/Regression_analysis ↩

8. http://en.wikipedia.org/wiki/COCOMO ↩

9. http://www.dwheeler.com/sloccount/sloccount.html ↩

10. Bureau of Labor Statistics, CES Database http://www.bls.gov/ces/#data ↩

11. Bureau of Labor Statistics, http://www.bls.gov/news.release/ecec.t05.htm (March 2008) ↩

12. David A. Wheeler, “Linux Kernel 2.6: It’s Worth More!” 2004 (revised 2007) http://www.dwheeler.com/essays/linux-kernel-cost.html ↩

13. For more information on Debian source-code counts, see Counting Potatoes: The size of Debian 2.2 (http://people.debian.org/~jgb/debian-counting) and Measuring Libre Software Using Debian 3.1 (Sarge) as A Case Study: Preliminary Results (http://www.upgrade-cepis.org/issues/2005/3/up6-3Amor.pdf) ↩

14. Greg Kroah-Hartman, Jonathan Corbet, and Amanda McPherson, “Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It”, April 2008, http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php ↩