如何评估一个 Linux 发行版的总体成本

开源之道引言：为什么要翻译十一年前的一份白皮书？

答案很简单，就是要学会算经济账，一个开源项目，尤其是大型的、经过多年开发的，企业利用该项目就要在开始的时候算好一笔经济账，它不是零成本，它像一个快速向前滚动（发展）的巨大磁石，如果你没有投入，那么很快便失去了任何的话语权，经过一段时间，则会被狠狠的甩下，体无完肤！不仅失去了创新的能力，而且成为了自己最大的负担。最后以失败而告终。

如果单单的只是将项目的某个时间的临时性成果来作为自己的产品或服务，那么就要想好要不要跟上步伐，要怎么跟？不过这些都要基于一个基础：这个阶段性的成果总成本是多少？该如何评估？于是就有了这篇文章。

介绍

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 这个版本。我们统计了所有在 http://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和估计产量值如下。

旁注：最初的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）：

本研究方法的局限性和优势

没有完美的方法来估计像Linux那样复杂和不断发展的软件项目的价值。虽然我们认为这种方法是最好的方法，但它可能过度计算价值的某些方面，而低估了其他方面。以下是我们认为该方法限制的部分：

• COCOMO 模型是研究封闭式软件开发而设计的。 因此，我们认为它低估了开源，协作开发的软件项目（如Linux）中固有的测试复杂性。由于变更的频繁，且不论大小，而且开发者本身均是分布全球各地，Linux生态系统参与者的测试负担比专有的独立公司高出一个数量级。
• 衡量Linux发行版价值的另一个困难就是确定开始时包含Linux发行版的内容。 我们的研究包含了Fedora的公共源代码库中所有软件包。但是，Fedora本身也有不同的版本（例如LiveCD版本）。当然还有更大的发行版，例如，Debian GNU / Linux 的代码仓库就比Fedora更大。还有大量的开源软件在任何一个发行版中都找不到。开源是一个非常大的宇宙，我们只是以Linux发行版为研究单位，尽可能的包含足够多的开源软件罢了。
• SLOC分析的最大弱点是它专注于软件项目的净增加。 举例来讲，任何熟悉内核开发的人都会意识到，开发过程中最高的人力成本是删除和修改代码的时候。删除和更改代码所花费的精力，并未反映在与此估算相关的值中。因为在协作开发模型中，代码被开发然后被更改和删除，真正的价值远远大于现有的代码库。聪明的你，想一下内核的开发流程：当几行代码添加到内核时，必须修改更多代码才能与现有的代码兼容。理解依赖关系和结果然后更改代码的工作在本研究中没有得到很好的体现。
• 协作开发意味着,通常会有多个个人或小组致力于解决相同技术问题的不同方法，其中只有一种方法“赢得”包含在最终版本中。 由于“失败”方法并未包含在最终的发布版本中，因此该 SLOC 方法未考虑这些方法的开发工作。
• 由于Linux不同的发行版之间，以及同一个发行版的不同版本之间的代码行数是有着巨大差异的，所以将本研究冠以研究“Linux”是有点牵强的。 分析内容有很多不同的选择，我们只能选择一种。出于这个原因，我们发现所有发行版共享的离散包的估计值（例如内核）更有意义。
• 很遗憾的是，我们只能以量来代替研究质。 Linux 社区的壮大速度很快，但同时也包含了一些不被经常用到的代码，比如旧的驱动程序。但是，包含此代码非常重要，因为Linux中包含特定于体系结构的代码以及驱动程序（与其他操作系统不同）。因此，此数字将大于OS本身内不包含这些组件的其他操作系统。
• 本研究假设所有开发者都来自美国，那么相应的就以美国劳动力的相关成本为基准来计算。尽管事实上，绝大多数的开源软件开发都是全球性的，其劳动力成本也会相应变化。
• 本研究中反映的数字表示从头开始一款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.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个软件包的统计数值，（供参考）：

参考资料

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. 该论文发表之后，Linux基金会发表的官方报道：Linux Foundation Publishes Study Estimating the Value of Linux