不止十亿：估算GNU/Linux的规模（2001年）

# 超越十亿美元：估算GNU/Linux的规模 来源：https://dwheeler.com/sloc/redhat71-v1/redhat71sloc.1.00.html **超越十亿美元：估算GNU/Linux的规模 David A\. Wheeler \(dwheeler@dwheeler\.com\) 2001年6月20日 版本 1\.0***本文分析了GNU/Linux的源代码量，以Red Hat Linux 7\.1作为具有代表性的GNU/Linux发行版，并展示了我认为有趣的结果。* *特别地，按照美国传统的专有方式开发这个Linux发行版，成本将超过10亿美元（10亿美元 - 一个十亿美金）。这与Red Hat Linux 6\.2版本（大约一年前发布）估计的6亿美元形成对比。此外，Red Hat Linux 7\.1包含超过3000万行物理源代码行（SLOC），而6\.2版本则有超过1700万行SLOC。使用COCOMO成本模型估计，该系统开发大约需要8000人年（相比之下，开发6\.2版本需要4500人年）。因此，Red Hat Linux 7\.1在规模、工作量和传统开发成本上比Red Hat Linux 6\.2增长了60%以上。这归因于全球范围内成熟和正在成熟的开源/自由软件程序的增加。* *许多其他有趣的统计数据浮现出来。最大的组件（按顺序）是Linux内核（包括设备驱动程序）、Mozilla（Netscape的开源网络系统，包括网络浏览器、电子邮件客户端和HTML编辑器）、X-windows（图形用户界面的基础设施）、gcc（编译系统）、gdb（用于调试）、基础二进制工具、emacs（文本编辑器及更多）、LAPACK（用于数值线性代数的大型Fortran库）、Gimp（位图图形编辑器）和MySQL（关系数据库系统）。使用的语言按代码行数排序为：C（71% - 曾为81%）、C\+\+（15% - 曾为8%）、shell（包括ksh）、Lisp、汇编语言、Perl、Fortran、Python、tcl、Java、yacc/bison、expect、lex/flex、awk、Objective\-C、Ada、C shell、Pascal和sed。* *主要的软件许可证是GNU GPL。略超过一半的软件仅使用GPL许可证，而使用copyleft许可证（GPL和LGPL）的软件包（至少部分使用或作为替代）占代码的63%。在所有方面，copyleft许可证（GPL和LGPL）在这个Linux发行版中是主导许可证。相比之下，只有0\.2%的软件是公共领域。* *本文是我之前关于估算GNU/Linux规模论文的更新，该论文评估了Red Hat Linux 6\.2[\[Wheeler 2001\]](http://www.dwheeler.com/sloc)。由于Red Hat Linux 6\.2于2000年3月发布，Red Hat Linux 7\.1于2001年4月发布，本文展示了大约一年内发生的变化。* *更多信息可在http://www.dwheeler.com/sloc获取。* ## 1\. 引言 GNU/Linux操作系统（也简称为“Linux”）已从一个未知事物发展成为一股强大的市场力量。一项调查发现，比任何其他操作系统更多互联网服务器使用Linux[\[Zoebelein 1999\]](http://leb.net/hzo/ioscount)。IDC发现，1999年购买的所有服务器操作系统中有25%是Linux，使其仅次于Windows NT的38%[\[Shankland 2000a\]](http://news.cnet.com/news/0-1003-200-1549312.html)。这似乎有很多原因，而不仅仅是因为Linux可以免费或低成本获得。例如，实验表明Linux具有高度的可靠性。1995年对一组独立组件的研究发现，GNU和Linux组件的可靠性显著高于其专有Unix竞争对手（GNU和Linux的故障率为6%到9%，而使用其测量技术的专有软件平均故障率为23%）[\[Miller 1995\]](http://www.cs.wisc.edu/~bart/fuzz/fuzz.html)。ZDnet在1999年进行了一项为期十个月的实验，发现虽然Microsoft的Windows NT在“典型”内部网负载下每六周崩溃一次，但在相同负载和请求集下，Linux系统（来自两个不同的发行商）*从未*崩溃[\[Vaughan\-Nichols 1999\]](http://www.zdnet.com/sp/stories/issue/0,4537,2387282,00.html)。 然而，在许多开发者和用户中，Linux流行最重要的原因可能是其源代码通常是“开源软件”和/或“自由软件”（这里的“自由”指的是“自由”）。一个“开源软件”或“自由软件”程序本质上是一个其源代码可以被获取、查看、更改和重新分发而无需支付版权税或受其他限制的程序。“开源软件”的更正式定义可在[OSI \[1999\]](http://www.opensource.org/osd.html)找到，“自由软件”的更正式定义可在[FSF \[2000\]](http://www.gnu.org/philosophy/free-sw.html)找到，关于这些主题的其他一般信息可在[Wheeler \[2000a\]](http://www.dwheeler.com/oss_fs_refs.html)找到。使用开源/自由软件的定量理由在[Wheeler \[2000b\]](http://www.dwheeler.com/oss_fs_why.html)给出。Linux操作系统实际上是一个组件套件，包括其基于的Linux内核，并且它由各种发行商打包、销售和支持。Linux内核是“开源软件”/“自由软件”，典型的Linux发行版的所有（或几乎所有）其他组件也是如此。开源软件/自由软件使用户免于成为特定供应商的俘虏，因为它允许用户立即修复任何问题、定制其系统并以任意方式分析其软件。 令人惊讶的是，尽管任何人都可以分析Linux的任意属性，但我发现很少有关于Linux发行版包含的源代码行数（SLOC）的公开分析。我找到的唯一公开数据（除了我自己的）是Microsoft在通常称为“万圣节 I”和“万圣节 II”的文档中开发的[\[Halloween I\]](http://www.opensource.org/halloween/halloween1.html)[\[Halloween II\]](http://www.opensource.org/halloween/halloween2.html)。在之前的论文中，我考察了Red Hat Linux 6\.2以及万圣节论文中的数字。 本文更新了我之前的论文，估算了一个当今GNU/Linux发行版的规模，并估算使用传统软件开发技术重建这个典型Linux发行版的成本。包含了各种定义和假设，以便其他人能够确切理解这些数字的含义。我特意撰写本文，使你无需*先*阅读本文的先前版本。 出于我的目的，我选择了Red Hat Linux 7\.1版本作为我的“代表”Linux发行版。我相信这个发行版在几个方面具有合理的代表性： 1. 根据IDC的数据，Red Hat Linux是1999年销售最流行的Linux发行版[\[Shankland 2000b\]](http://news.cnet.com/news/0-1003-200-2662090.html)。Red Hat在1999年销售了所有副本的48%；市场份额第二大的发行版是SuSE，占15%。并非所有Linux副本都以本研究会计数的方式“销售”，但该研究至少表明Red Hat的发行版是受欢迎的。 2. 许多发行版（如Mandrake）基于Red Hat Linux的旧版本。 3. 所有主要通用发行版都支持（至少）Red Hat Linux所支持的功能类型，如果不是出于其他原因，至少是为了与Red Hat竞争。 4. 所有发行商都从同一组开源软件项目开始选择要集成的组件。因此，其他发行版很可能为相同类型的功能选择相同或类似的组件，通常具有相似的规模。 不同的发行版和版本会产生不同的规模数字，但我希望本文即使不试图评估“所有”发行版，也具有启发性。请注意，某些发行版（如SuSE）可能会决定添加更多应用程序，但也请注意，这只会导致更大（而不是更小）的规模和估计的工作量水平。在我开始这个项目时，版本7\.1是可用的Red Hat Linux最新版本，因此我选择了该版本进行分析。 请注意，Red Hat Linux 6\.2于2000年3月发布，Red Hat Linux 7于2000年9月发布（我没有计算其代码），Red Hat Linux 7\.1于2001年4月发布。因此，Red Hat Linux 7\.1与6\.2之间的差异显示了大约13个月（约一年）内累积的变化。 显然，全球范围内可用的开源/自由软件远多于本文所统计的。然而，发行商的工作是审查这些不同的选项，并选择他们认为足够成熟且对其目标市场有用的软件。因此，考察一个特定发行版会导致对此类软件的选择性分析。 第2节简要描述了用于估算该发行版“规模”的方法（更多细节在附录A中）。第3节讨论了一些结果。第4节给出结论，后接附录。 ## 2\. 方法 我的基本方法是：1. 以未压缩格式安装源代码文件；这需要仔细选择要分析的源代码。 2. 计算源代码行数（SLOC）；这需要SLOC的仔细定义。 3. 使用估算模型估算以专有方式开发相同系统的工作量和成本；这需要一个估算模型。 4. 确定每个组件的软件许可证并基于这些类别制定统计信息。 更多关于此方法的详细信息在附录A中描述。然而，有几个总结点值得在此提及。 ## 2\.1 选择源代码 我包含了Red Hat发行版中提供的所有软件，但请注意Red Hat不再包含仅适用于其他CPU架构的软件包（因此不适用于x86系列的包被排除）。我没有包含软件的“旧”版本，或者有非beta版本可用时的“beta”软件。我确实包含了没有替代品的“beta”软件，因为有些开发者即使软件被广泛使用并被认为可靠也不会移除“beta”标签。 我使用md5校验和来识别和忽略重复文件，因此如果相同的文件内容出现在多个文件中，则只计数一次（作为决胜局，此类文件被分配给按字母顺序排列的第一个构建包）。 Makefile和RPM包规范中的代码不包括在内。使用了各种启发式方法来自动检测生成的代码，任何此类代码也从计数中排除。还使用了许多其他启发式方法来确定语言是否是源程序文件，如果是，它是什么语言。 ## 2\.2 定义SLOC 本文主要使用“物理源代码行数”（物理SLOC）作为SLOC的度量。非正式地说，本文中的物理SLOC是指除注释和空白字符（制表符和空格）外包含其他内容的行。更具体地说，物理SLOC定义如下：“物理源代码行是以换行符或文件结束符结尾，并且包含至少一个非空白非注释字符的行。”注释分隔符（除换行符外开始和结束注释的字符）被视为注释字符。仅包含空白字符的数据行（例如，多行字符串中仅包含制表符和空格的行）不包括在内。 请注意，“逻辑”SLOC不是本文使用的主要度量；逻辑SLOC度量的一个例子是“C文件中所有终止分号的计数”。选择“物理”SLOC而不是“逻辑”SLOC，是因为需要测量的语言太多了。我在让免费工具在这个规模上工作时遇到了麻烦，而非免费工具对我的预算来说太贵了（也不确定它们是否会表现得更好）。由于我必须开发自己的工具，我选择了一种更容易实现的度量。实际上，\[Park \[1992\]\](http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.020.html)建议使用物理SLOC度量（作为最小值），出于这个和其他原因。“物理”SLOC度量有缺点。特别是，物理SLOC度量对代码的格式敏感。但逻辑SLOC度量也有问题。首先，如前所述，实现测量逻辑SLOC的工具更困难，需要对代码进行更复杂的分析。此外，有许多不同的逻辑SLOC度量，需要更仔细的定义。最后，逻辑SLOC度量必须为要测量的每种语言重新定义，使得跨语言比较更加困难。有关测量软件规模的更多信息，包括必须做出的问题和决定，请参见\[Kalb \[1990\]\](http://sunset.usc.edu/research/CODECOUNT/documents/3rd_REVIC.pdf)、\[Kalb \[1996\]\](http://sunset.usc.edu/research/CODECOUNT/documents/ispa.pdf)和\[Park \[1992\]\](http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.020.html)。 请注意，这要求每个文件都按语言类型分类（以便应用正确的注释、字符串等语法）。此外，必须检测并忽略自动生成的文件。谢天谢地，我的工具“sloccount”可以自动完成此操作。 ## 2\.3 估算模型 选择使用物理SLOC也意味着对于工作量估算器，我需要使用原始的COCOMO成本和工作量估算模型（见Boehm \[1981\]），而不是更新的“COCOMO II”模型。这仅仅是因为COCOMO II需要逻辑SLOC作为输入，而不是物理SLOC。 基本COCOMO旨在估算从产品设计（在计划和要求制定之后）到详细设计、编码、单元测试和集成测试的时间。请注意，不包括计划和需求开发。COCOMO旨在包括管理开销和文档创建（例如用户手册）以及代码本身。同样，请参阅Boehm \[1981\]以了解有关模型假设的更详细描述。特别值得注意的是，基本COCOMO不包括将文档、数据和程序消息翻译成其他人类语言的时间，也不包括字体开发的时间。 有理由相信这些模型虽然不完善，但对于估算开源/自由软件项目的工作量仍然有效。尽管许多开源程序不需要人力资源管理，但它们仍然需要技术管理、基础设施维护等。设计文档在开源项目中捕获得不那么正式，但通常由于必要而捕获，因为开源项目往往有许多地理位置分散的开发者。显然，系统仍然必须被编程。测试仍然在进行，尽管与当今许多专有程序一样，大量测试是通过alpha和beta版本完成的。此外，许多开源项目通过同行评审提交的代码来提高质量。估算可能低于实际值，因为它们不包括人类语言翻译和字体的估算。 对于程序员薪