完美世界手游官网隐藏任务 www.gytoi.icu 經濟學有云:‘天下沒有免費的午餐’,那么一個開源項目到底價值多少錢?到了自己手里能夠增值還是貶值?那么拋開技術債務這一塊不說,光從經濟的角度考量下。這次我們要學習的是最最基礎的評估一個開源項目成本的方法論。

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

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

如果單單的只是將項目的某個時間的臨時性成果來作為自己的產品或服務,那么就要想好要不要跟上步伐,要怎么跟?不過這些都要基于一個基?。赫飧黿錐渦緣某曬艸殺臼嵌嗌??該如何評估?于是就有了這篇文章。

介紹

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(軟件代碼行數)的行業標準工具,他確定在美國通過傳統的封閉方法開發 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 用到了行業標準建設性成本模型(COCOMO),該模型是由 Barry Boehm 開發的算法軟件成本估算模型,該模型使用基本回歸公式,可以傳入從歷史項目數據和當前項目特征派生的參數。我們從2002年開始更新他的研究,包括不斷增長的Linux內核代碼庫和其他軟件包,以及軟件開發人員的薪水。(關于此的更多細節將在下文的“方法論”部分中進行詳細討論。)

基于該方法,如果是采用傳統的封閉方法來開發這樣一個規模的Linux發行版的話,我們估計需要108億美元(2008年)。

方法論

我們的基本方法是:

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

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

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

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

還應該指出的是,薪水本身并不是軟件開發成本的唯一決定因素。在他的文章中,Wheeler 提及了 SLOCCount 中的開銷參數,其中包括測試成本、設備、公司運營成本以及開發人員的總賠償金。這些參數被稱之為 Wrap rate。

要知道這些 wrap rate 的增長是非常之迅速的,在美國,專業員工的平均薪酬百分比(病假,休假,保險福利)為29.0%。因此,雖然我們剛才所提及的美國勞工統計局給出的數據是程序員的平均工資為75,662.0810美元,但是企業主實際要付的數字為97,604.08美元。而且這只是總的 wrap rete 部分。

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

源代碼和估計成本結果

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

代碼類型 代碼行數
全部總的代碼行數(SLOC) 204,500,946
開發效果估算:人年(人月)(基本的COCOMO模型,人月= 2.4 *(KSLOC ** 1.05)) 59389.53 (712674.36)
進度估算,年(月)(基本的COCOMO模型,月份= 2.5 *(人月** 0.38)) 24.64 (295.68)
預計總開發成本,(平均工資= 75,662.08美元/年,間接費用= 2.40) $10,784,484,309

旁注:最初的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 模型來進行衡量。增強的 COCOMO模型有更多的參數供選擇,因此,應該更準確地分析一個復雜的軟件本身。在2004年的文章中,他詳述了他對這些參數的評估細節,即調整整體的凈效應,將 SLOCCount 中的工作因子值從默認值3到4.64607,同時,-effort指數值也變為1.12,在增強的 COCOMO 軟件估算模型下,這是分配給半分離軟件項目的值。

基于這些新的參數,針對 Linux 內核做了一個單獨的評估(Fedora 9的內核版本是 linux-2.6.25.i686):

代碼類型 代碼行數
全部總的代碼行數(SLOC) 6,772,902
開發效果估算:人年(人月)(有效模型,人月= 4.64607 * (KSLOC**1.12)) 7557.4 (90688.77)
進度估算,年(月)(基本的COCOMO模型,月份= 2.5 *(人月** 0.38)) 15.95 (191.34)
預計平均開發人員數量(有效/時間表) 473.96
預計總開發成本,(平均工資= 75,662.08美元/年,間接費用= 2.40) $1,372,340,206

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

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

  • COCOMO 模型是研究封閉式軟件開發而設計的。 因此,我們認為它低估了開源,協作開發的軟件項目(如Linux)中固有的測試復雜性。由于變更的頻繁,且不論大小,而且開發者本身均是分布全球各地,Linux生態系統參與者的測試負擔比專有的獨立公司高出一個數量級。
  • 衡量Linux發行版價值的另一個困難就是確定開始時包含Linux發行版的內容。 我們的研究包含了Fedora的公共源代碼庫中所有軟件包。但是,Fedora本身也有不同的版本(例如LiveCD版本)。當然還有更大的發行版,例如,Debian GNU / Linux 的代碼倉庫就比Fedora更大?;褂寫罅康目慈砑諶魏我桓齜⑿邪嬤卸頰也壞???詞且桓齜淺4蟮撓鈧?,我們只是以Linux發行版為研究單位,盡可能的包含足夠多的開源軟件罷了。
  • SLOC分析的最大弱點是它專注于軟件項目的凈增加。 舉例來講,任何熟悉內核開發的人都會意識到,開發過程中最高的人力成本是刪除和修改代碼的時候。刪除和更改代碼所花費的精力,并未反映在與此估算相關的值中。因為在協作開發模型中,代碼被開發然后被更改和刪除,真正的價值遠遠大于現有的代碼庫。聰明的你,想一下內核的開發流程:當幾行代碼添加到內核時,必須修改更多代碼才能與現有的代碼兼容。理解依賴關系和結果然后更改代碼的工作在本研究中沒有得到很好的體現。
  • 協作開發意味著,通?;嵊卸喔齦鋈嘶蛐∽櫓鋁τ誚餼魷嗤際蹺侍獾牟煌椒?,其中只有一種方法“贏得”包含在最終版本中。 由于“失敗”方法并未包含在最終的發布版本中,因此該 SLOC 方法未考慮這些方法的開發工作。
  • 由于Linux不同的發行版之間,以及同一個發行版的不同版本之間的代碼行數是有著巨大差異的,所以將本研究冠以研究“Linux”是有點牽強的。 分析內容有很多不同的選擇,我們只能選擇一種。出于這個原因,我們發現所有發行版共享的離散包的估計值(例如內核)更有意義。
  • 很遺憾的是,我們只能以量來代替研究質。 Linux 社區的壯大速度很快,但同時也包含了一些不被經常用到的代碼,比如舊的驅動程序。但是,包含此代碼非常重要,因為Linux中包含特定于體系結構的代碼以及驅動程序(與其他操作系統不同)。因此,此數字將大于OS本身內不包含這些組件的其他操作系統。
  • 本研究假設所有開發者都來自美國,那么相應的就以美國勞動力的相關成本為基準來計算。盡管事實上,絕大多數的開源軟件開發都是全球性的,其勞動力成本也會相應變化。
  • 本研究中反映的數字表示從頭開始一款Linux發行版,進而計算開發所需的成本。 值得注意的是,這可以估算成本,但不會估算更大生態系統的價值,因為如此廣泛使用的核心技術改變將產生巨大而深遠的經濟影響。

Linux 是如何增長的

本研究還沒有考慮逐步更新和擴展Linux代碼庫的年度開發成本?;謖廡┦鄭ɑ蛉魏穩碩訪inux發行版的直接經驗),很容易看出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%,考慮到代碼樹的大小,這個數字非??曬?。但是這不僅僅是代碼數量上的增長,還有實際功能、性能等諸多的其它因素的改進和進化,因為每一次的變更都意味著代碼的增加、刪除、修改?!?/strong>

雖然Linux內核與Linux發行版當中的大多數其他組件相比,可能更改的更為頻繁,但是從整體而言,我們的數據也反映出整個Linux發行版每年都在不斷增長和變化。由于Linux內核只是Linux發行版的一個?。ǖ淺V匾┳榧?,其每年投入的迭代開發成本非常的高,但在本次研究中還沒有將其進行特別的處理。

總結

那么在閱讀完這篇研究之后,你知道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 的內容,去閱讀相關文檔。

致謝

我們要感謝以下人員對本文的審核和反?。篔ames 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,其安裝盤并沒有包含源代碼,所以我們的代碼是從//mirrors.kernel.org上下載的。因為確定要分析的文件會在流程中進入另一層次的主觀性,所以決定將所有5547個可用的開源軟件包(src.rpms)下載并安裝在測試機器上。

從FTP服務器下載src.rpms后,就可以安裝它們了。關于RPM的特性和使用手冊請查閱相關資料。

可按照如下命令執行:

rpm -ivh *.src.rpm
rpmbuild -bp –nodeps *.spec
sloccount –multiproject –personcost 75662.08 /usr/src/rpm/BUILD/ &> sloc.txt

如需進一步檢查,以下是Fedora 9源代碼中的前10個軟件包的統計數值,(供參考):

SLOC OSS項目 按語言分別計算的SLOC(已排序)
5961705i kernel-2.6.25i686 ansic=5727336, asm=216356,perl=6019, cpp=3962, yacc=2901, lex=1824, objc=613,python=331,lisp=218, pascal=116, awk=96
4991916 OpenOffice.org cpp=4518218, java=262028, ansic=109607, perl=66501, sh=11288, yacc=6657, cs=6600, python=3023, lex=2474, asm=2453, lisp=920, awk=734, objc=594, pascal=407, csh=301, php=104, sed=7
3118105 Gcc-4.3.0-2 0080428 ansic=1559056, java=646496, ada=478683, cpp=305899, f90=50636, asm=25272, sh=19070, exp=11829, fortran=7651, objc=3539, perl=2732, ml=2485, yacc=1440, pascal=1092, awk=764, python=582, lex=461, tcl=381, haskell=37
2664636 Enterprise Security Client 1.0.1 cpp=1725793, ansic=862640, perl=27244, asm=16749, sh=16435, cs=6232, java=5325, python=3077, lex=306, php=244, pascal=230, csh=132, objc=97, yacc=79, ada=49, sed=4
2216353 eclipse-3.3.2 java=2089544, ansic=96269, cpp=24302, jsp=3965, perl=1325, sh=878, python=46, php=24
2123390 Mono-1.9.1 cs=1862734, ansic=257228, sh=1998, perl=807, asm=335, yacc=288
2088834 firefox-3.0 cpp=1280521, ansic=743238, asm=32703, sh=14686, perl=7177, python=6549, java=2668, makefile=2451, objc=867, lisp=256, pascal=159, awk=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. //en.wikipedia.org/wiki/Source_lines_of_code
  5. //en.wikipedia.org/wiki/Estimation_in_software_engineering
  6. //en.wikipedia.org/wiki/Barry_Boehm
  7. //en.wikipedia.org/wiki/Regression_analysis
  8. //en.wikipedia.org/wiki/COCOMO
  9. //www.dwheeler.com/sloccount/sloccount.html
  10. Bureau of Labor Statistics, CES Database //www.bls.gov/ces/#data
  11. Bureau of Labor Statistics, //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) //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 (//people.debian.org/~jgb/debian-counting) and Measuring Libre Software Using Debian 3.1 (Sarge) as A Case Study: Preliminary Results (//www.upgrade-cepis.org/issues/2005/3/up6-3Amor.pdf)
  14. 該論文發表之后,Linux基金會發表的官方報道:Linux Foundation Publishes Study Estimating the Value of Linux
余下全文(1/3)

本文最初發表在www.ocselected.org,文章內容屬作者個人觀點,不代表本站立場。

分享這篇文章:

請關注我們:

發表評論

電子郵件地址不會被公開。 必填項已用*標注