如何评估一个 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 年）。

方法论

我们的基本方法是：

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 和估计产量值如下。

< 如显示不全，请左右滑动 >

代码类型	代码行数
全部总的代码行数（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 模型intermediate COCOMO model来进行衡量。增强的 COCOMO 模型有更多的参数供选择，因此，应该更准确地分析一个复杂的软件本身。在 2004 年的文章中，他详述了他对这些参数的评估细节，即调整整体的净效应，将 SLOCCount 中的工作因子值从默认值 3 到 4.64607，同时，-effort 指数值也变为 1.12，在增强的 COCOMO 软件估算模型下，这是分配给半分离软件semi-detached software项目的值。

基于这些新的参数，针对 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 更大。还有大量的开源软件在任何一个发行版中都找不到。开源是一个非常大的宇宙，我们只是以 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 个软件包的统计数值，（供参考）：

< 如显示不全，请左右滑动 >

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
1792482	bigloo3.0b	ansic=1621378, lisp=143716, sh=10296, java=8233, cs=7846, cpp=849, asm=159, yacc=5
1788219	gcc-3.4.6-20060404	ansic=858843, ada=485364, cpp=196337, java=175563, asm=24403, sh=19731, yacc=14038, exp=5657, objc=4408, fortran=2032, perl=898, lex=587, awk=189, pascal=86, haskell=66, sed=17
1543156	ParaView3.2.1	cpp=960400, ansic=509436, tcl=45787, python=19574, perl=3112, yacc=1787, java=1517, sh=644, asm=471, lex=400, objc=28

参考资料

---

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 (March2008) ↩

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 ↩