如何使开源项目增长 10 倍，收入增长 5 倍

Original Henrik Ingo 开源社KAIYUANSHE

原文：https://www.openlife.cc/blogs/2010/november/how-grow-your-open-source-project-10x-and-revenues-5x

作者：Henrik Ingo, 2010-11-29

译者：刘天栋 Ted

【正文】

前段时间，我应邀对我们最受欢迎的开源项目进行了一项研究，以评估：

1）目前有哪些管理模式；

2）管理模式是否一方面对项目的成功（如开发者社区的规模）有影响，另一方面对相关供应商的业务有影响。其中一些结果非常显著，具有普遍适用性，因此我想在此与大家分享：

(2011-07-14 进行了小幅更新)

对最受欢迎的开源项目进行研究，比较管理模式与（开发者）社区规模，并估算拥有大型社区的商业价值。

通过研究最流行的开源项目中的一部分--我们认为这些项目或多或少都是完整的--并将它们的规模与管理模式联系起来，我们发现了一个强有力的结果，有些人可能会对此感到惊讶：

•有 9 个开源项目（Linux、KDE、Apache、Eclipse、Perl+CPAN、Mozilla+Addons、Gnome、Drupal 和 GNU）的规模明显大于其他项目，大约是其他项目的 10 倍。

•所有这些被归类为 "XtraLarge" 的项目都是由非营利基金会管理的社区合作项目。迄今为止，还没有任何一个供应商的项目能达到它们的规模。

•大型单一供应商项目（MySQL、Qt、OpenOffice、Mono、JBoss）的发展似乎受到了玻璃天花板的限制。

•尽管对 Linux 项目深不可测的规模和速度已经有了深入的研究并广为人知，而且偏好由基金会管理的协作项目也已开始成为一个普遍接受的事实，但令人惊讶的是，我们竟然发现有多达 9 个项目都明显地从其他项目中脱颖而出。从统计学角度看，9 比 0 的结果非常有利于基金会管理模式。

•加强这一结果的另一个因素是 "超大型" 组与其他项目之间的明显差距。这进一步增强了对结果有效性的信心。即使基础数据被认为质量不佳，但显然也不存在可以解释如此巨大差距的误差。

•所有 9 个 "XtraLarge" 项目的另一个共同特点是，软件架构要么是模块化的（Linux、Eclipse、Perl+CPAN、Mozilla+Addons、Drupal），要么是软件的集合（KDE、Apache、Perl+CPAN、Gnome、GNU）。事实上，许多项目（如 Eclipse 和 Apache）都是如此。

甲骨文控制的 OpenJDK 可能会成为一个例外，因为 IBM 在 2010 年宣布将参与 OpenJDK 的开发，并放弃 Apache Harmony。此前，红帽公司（Red Hat）已经加入，苹果公司也于 2011 年加入 OpenJDK。虽然围绕 OpenJDK 建立一个超大型开发者社区（如果成功的话）是 Sun 和甲骨文公司取得的一项令人印象深刻的成就，但所采取的路线或许并不适用于一般的开源项目：Java 是作为一个专有产品发展到目前的重要程度的，而 IBM 放弃 Apache Harmony 似乎是甲骨文方面某种非公开但强有力的胁迫的结果。这种 "蛮力" 策略对于大多数希望达到超大型级别的开源项目来说是根本不可能的。

通过比较 Red Hat 和 Novell 在 Linux 开发方面的相对投资，可以看出最大和第二大 Linux 供应商都明显受益于通过合作开发来分担开发成本。Red Hat 是最大的 Linux 开发商，提供了 12% 的开发工作，但其市场份额却占到了 62% 的比例。这表明，红帽公司从 Linux 的合作开发中获得的杠杆率大约是 5 倍。对于 Novell 来说，杠杆作用几乎同样显著，开发工作占 7.6%，市场份额占 29%，杠杆系数大约为 4 倍。

据进一步观察，如果 Linux 是由 Red Hat 一家厂商单独开发的，那么我们可以看到，其工程工作量可能要比今天整个 Linux 社区的总工作量小 10 倍左右。这似乎与前面的观察结果一致，即最大的单一供应商项目大约比 "超大型 "基金会管理的项目小 10 倍。

从这些结果来看，一个显而易见的建议是，参与开放源码开发和业务的供应商应考虑参与社区合作开发的项目--其中标准和熟悉的管理形式是非营利基金会。如果一个供应商目前控制着一个开放源码项目，那么它就应该探索将该项目转让给现有基金会的方案，或者为其创建自己的基金会。由于在合作开发的项目中，原厂商总是最有可能成为主导厂商，因此，根据经验法则，如果执行得当，厂商可以预期这一战略将使项目和产品增长 10 倍，同时也会使潜在市场扩大 10 倍，厂商可预期在其中占据 50% 或更多的市场份额。

我们利用一些开源项目列表作为资料来源，创建了一份（接近）完整的全球最受欢迎开源项目列表。其中包括的项目必须是：

•开发代码的上游项目（例如，不是 Linux 发行版或类似 XAMPP 的项目）

•历史悠久，规模庞大，在同类产品中处于领先地位（或 "并列"，如 Gnome 与 KDE）。

使用的资料来源包括 Debian（https://popcon.debian.org/）和 Ubuntu（https://popcon.ubuntu.com/）中的流行度竞赛软件包生成的列表、SourceForge 的历年最高下载量（https://sourceforge.net/top/topalltime.php?type=downloads），以及一份上述抽样方法未找到但已知的大型重要项目的简短列表。

我们从 Debian 和 Ubuntu 的 "popcon "列表中收集了所有出现在前 1000 名中的项目。这是因为在安装的前 1000 个软件包中，98% 以上都是常见的系统库和实用程序，可以归类到 "gnu 系统工具 "中，如果不是来自 GNU，则可以作为 "其他 "丢弃。不过，在这 1000 个顶级软件包中，我们还能找到来自 Perl、Python、PHP、Gnome 和 Linux 内核等熟悉软件的代码。

SourceForge 的列表令人失望，它似乎被文件共享应用软件占据了榜首，甚至还有很多只在 Windows 下运行的软件。只有少数几个项目被认为与 "LAMP 服务器或 Linux 桌面 "的一般领域相关，因此被选中。

最后，作者还亲自添加了几个明显重要但仍然缺失的开源项目。

由此产生了以下开源项目样本。

表 1：研究中使用的流行开源项目样本

然后对所选项目的开发者社区规模进行估算，以便大致按规模排序。对于最大的项目 Linux、Apache、KDE、Gnome 和 Eclipse，已经对其开发工作的数量和结构进行了单独研究（参见末尾的 "资料来源"），或者由项目主办方公布了一些活跃参与者的数量。但即使是这些项目，要比较社区之间的相对规模也并非易事，因为每项此类研究都会得出不同的测量结果 1。

对于其他项目，则使用 OHLOH.net 来获取提交次数/天、活跃开发人员/月和所有开发人员的时间。虽然 OHLOH 服务是快速收集大量项目统计数据的便捷方法，但其数据质量似乎并不可靠。例如，OHLOH 声称 MySQL 在特定月份只有 25 名活跃开发人员，而作者本人所熟悉的全职 MySQL 开发人员却比这个数字还要多。另一方面，在 1000 多名全职 MySQL 开发人员中，由于人们使用不同的电子邮件地址，存在许多重复、三重和四重。此外，Thunderbird 的开发人员数量不可能是 Firefox 的 3 倍（两者都没有插件，只有核心）。还有一些需要注意的地方，例如，在 OHLOH 上搜索 "CPAN"，得到的是 Perl CPAN 模块的统计数据，而不是整个 CPAN 档案（可能无法从任何地方获得）。

尽管如此，大多数项目还是使用了 OHLOH 的数字，以获得一个有序的列表，并最终将其归类为不同规模的社区，但这与作者自己对项目观察的主观检查相平衡。这项研究的主要结果具有很强的统计学意义，不同类型项目的规模相差 10 倍，无论 OHLOH 不准确造成的误差有多大，肯定都小于这个数字。

下表是有关项目规模的各种统计数据：

表 2：按相对规模排序的项目，以及各种衡量标准

粗黑体数字乃基于项目本身的公开研究。其他数字则是基于 OHLOH.net。

在为期 3 年的开发过程中，有 954 人至少为 Drupal 7 的核心部分贡献了 1 个补丁。除此之外，截至目前，Drupal 还拥有约 8,291 个附加模块，与 Perl CPAN 档案库的数量相当。这些事实并不能很好地归入上表中的任何一列，但却凸显了 Drupal 社区的规模--事实上，Drupal 可能是目前最大的开源项目？下表显示的是 2010 年的 OHLOH 数据。

对于 Perl 来说，唯一可用的统计数据是 CPAN 上的模块数量。开发人员的数量很可能一直少于 8500 人，但它提供了一个很好的数量级。同样的逻辑也适用于 Mozilla（Firefox 和 Thunderbird 因共享代码和插件而合并在一起）。

2011 年，我们试图获得有关 OpenJDK 工程投资的更准确数字--这是因为我们认为，由于甲骨文、IBM 和红帽的投资，OpenJDK 现在有可能达到超大规模。另一方面，OHLOH.net 上关于 OpenJDK 的数字仅报告了每月 50 多名开发人员。通过与熟悉 Sun Java 开发和 OpenJDK 的人讨论，似乎这可能是大致正确的，无论如何，OpenJDK 没有数百名开发人员。

由于数据不准确，绘制地图或其他图表并无用处。取而代之的是，可将项目按规模分为特大型、大型和中型类别（小型项目省略）。然后将这些项目与已知的治理模式进行关联：

表 3：项目管理模式与开发者社区规模的相关性

备注

类别是观察到的，而不是预先确定的，也就是说，它们是从样本中观察到的。例如，"多个供应商联盟 "在样本中没有被观察到。(例如：Eclipse 2001-2003）。

Linux 项目基本上只生产内核这一种产品，而 KDE、Apache、Gnome 等其他项目则是承载许多子项目的整个基础，但在这里被视为一个社区。这里的理由是，这些软件项目的集合仍然属于某些共同的主题，例如 Apache 主要生产网络软件和支持开发人员的实用程序。随着 OpenOffice 被捐赠给 Apache，这种解释也许已经达到了极限，除了 Apache 许可证之外，OpenOffice 似乎与其他 Apache 项目没有任何共同之处。

同样，Perl、PHP、Drupal 等项目中的独立 "贡献者模块 "档案也被视为主项目的一部分，因为模块化架构是发展大型社区的关键因素。比较一下，如果 MySQL 也是由社区驱动的，phpMyAdmin 就可以成为它的一部分，而不是像现在这样成为一个独立的项目。

GIMP 早于 Gnome，但现在是 Gnome 的一部分。

GCC 是 GNU 的一部分，但根据现有数据单独列出。作者估计，如果能找到数据，"GNU 项目" 也会是一个超大型项目，因为 GCC 本身就已经是大型项目中的佼佼者。

同样，OpenJDK 可能是第一个进入 XtraLarge 类别的供应商控制项目，请参见结论中的讨论。

Python 于 2000 年更名为基金会。Subversion 以前由 CollabNet 领导，但自 2009 年起成为 Apache（基金会）项目，Wordpress 于 2010 年从 Automattic 转移到自己的基金会，但这两个项目在这里都被归类为供应商项目，因为在其生命周期的大部分时间里都是这种模式。

Qt、MySQL 和 GhostScript 是 1990 双许可证时代的明星。

OpenOffice 于 2010 年被分叉。创建 LibreOffice 分支的文档基金会在几个月内就新增了 77 名贡献者。2011 年，甲骨文公司将 OpenOffice 代码捐赠给了 Apache 基金会，IBM 也在该基金会中投资开发人员并召集社区成员。本研究将历史上的 OpenOffice 归类为 Sun，因为现在谈论 Apache 和 LibreOffice 的后代还为时过早。

Mozilla 基金会的收入约为 1 亿美元（更新：2011 年 12 月，Mozilla 宣布谷歌现在将每年向 Mozilla 公司支付 3 亿美元），并雇用了许多工程师，而其他基金会项目的工程师通常在参与公司工作。值得注意的是，这使得 Mozilla Corp 的收入规模超过了供应商一栏中的任何一家营利性供应商，这也与下文关于财务动机的讨论相关！(更新：凭借超过 3 亿美元的年收入，Mozilla Corp 成为无可争议的领导者）。

Wordpress 仅有核心数据，插件和主题是作为估计值添加的，甚至无法达到 Medium。

请注意，在作者了解到 "PHP 小组 "从未在任何司法管辖区正式成立之后，PHP 已于 2011 年被移至 "只是一个项目 "一栏。尽管如此，PHP 确实有一套明确的成员资格和决策制定流程，与更正式的组织类似。缺乏一个合法的组织似乎主要是在 PHP 需要维护商标或版权或以其他方式对某些威胁提起法律诉讼的情况下出现的问题--这种情况从未出现过。PHP 很可能是世界上最大的非法人项目。

所有大型项目都有某种形式的正式管理机构，要么是单一供应商，要么是非营利基金会。

有 9 个项目（如果包括 GNU，因为没有相关数据）属于 "超大 "类。这些项目明显有别于下面的 "大型 "类别。平均而言，它们的规模要大 10 倍。(Gnome 比这一顶级类别中的其他项目稍小一些，但也明显有别于下一类别中月度开发者人数约为 100 或更少的项目）。

所有 XtraLarge 项目都是由非营利基金会管理的，没有一个单一供应商项目能够发展到如此规模。

上述结果具有很强的统计学意义。Linux 项目规模之大、速度之快令人瞠目结舌（每天更改 18 000 行代码！），但这并不是一个单独的案例，而是共有 9 个合作项目和基金会管理的项目达到了这一规模。

对于单一供应商项目来说，似乎存在一个玻璃天花板，禁止它们从大型项目向上发展。为了真正发挥其最大潜力，建议开放源代码项目考虑采用非营利基金会这一行之有效的管理模式，让参与者围绕基金会开展合作。

甲骨文公司的 OpenJDK 可能会成为第一个由供应商控制的超大型项目。红帽公司（Red Hat）已经为该项目做出了贡献，IBM 公司最近也宣布将放弃与之竞争的 Apache Harmony 项目，转而为 OpenJDK 做出贡献。然而，OpenJDK 是一个特例：1）Java 是作为一个纯粹的专有产品发展到今天的规模的；2）虽然没有公开，但 IBM 从 Apache 转向 OpenJDK 似乎受到了甲骨文公司某种胁迫的影响，例如与甲骨文对谷歌针对 Dalvik/Harmony 的专利和版权诉讼有关的胁迫，或者是对 JCP 进程的某些方面的胁迫，等等。因此，尽管围绕以前的封闭源代码产品建立一个庞大的开发者社区是一项了不起的成就，但实现这一目标的途径也许并不适用于一般情况。

由供应商管理的大型项目往往会引起争议：

•MySQL：金融明星，但现在已经分叉多次。现在要让它继续生存下去，需要做大量的工作。

•OpenOffice：典型的 Sun 公司风格 - 自 2000 年以来停滞不前，管理不善。现在成功分叉：所有 Linux 用户立即支持，2 个月内新增 77 名贡献者。

•Mono：FOSS 原教旨主义者因为 .NET 的起源而抵制它，其他人则不在乎它是由供应商管理的。

•Qt：技术上更胜一筹，但由于 Trolltech 的过度控制，失去了完全的主导地位，与 GTK（Gnome 的一部分）平分秋色。(财务状况尚可：2008 年被诺基亚收购）。

•JBoss 在社区中一直没有争议，但在市场份额上受到了 IBM 支持的 Apache Geronimo 的攻击（但还是挺了过来）。

•在甲骨文公司迫使 IBM 为 OpenJDK 做出贡献后，OpenJDK 很可能会跻身超大型供应商行列。

众所周知，大型供应商项目的社区贡献也很低。(待办事项：进一步发掘 JBoss？）

超大型基金会 "收购 "中型项目。(Subversion, GIMP）

人们普遍认为，开源项目要想蓬勃发展，模块化架构必不可少。当然，任何软件项目都建议采用模块化架构，但在开源项目中，模块化架构被视为实现典型的分布式开发的先决条件。我们不难发现，所有的 XtraLarge 项目要么是模块化架构（Linux、Eclipse、Perl+CPAN、Mozilla+Addons、Drupal），要么是软件集合（KDE、Apache、Perl+CPAN、Gnome 和 GNU）。事实上，许多软件如 Apache、Eclipse 和 KDE 都是这两种软件的集合。

从直观上看，如果一个项目采用一种模式比另一种模式的规模大 10 倍，那么这种模式在财务上显然也是积极的。然而，从供应商的角度来看，这也是一个恰当的问题：即使项目的风险大大降低，但为了更好地从中获利，将项目控制权交给供应商在财务上是否仍然更可取？请注意，这将直接导致产品的开发投资减少。

为了回答这个问题，我们将研究 Linux 项目及其主要供应商的财务业绩。在所有项目和市场中，这是研究最多的一个。此外，Linux 供应商市场可被视为开源业务的先驱，因此，我们有理由期待--或者说希望--在这个市场上首次出现的动态后来也能在其他项目中看到。

我们的任务是估算 Linux 厂商通过合作分担开发成本所获得的收益，以及它们因开放而可能损失的收入和市场份额。我们可以从 Linux 开发报告和不同 Linux 厂商的市场份额中看出这一点：

•Red Hat 是 Linux 开发的最大贡献者，占 12% 的提交量。

•红帽公司（Red Hat）对 Linux 开发的控制力最强，它雇佣了 36% 的顶级开发人员来审查提交文件（......几年前这一比例曾达到 50%）。因此，我们还注意到，虽然红帽公司与其他公司分担开发成本，但却牢牢控制着这个项目。

•Red Hat 占有 Linux 操作系统销售市场 62% 的份额

上述情况意味着，与开发投资相比，红帽公司作为领先的 Linux 供应商，拥有不成比例的巨大市场份额 2 。因此，红帽公司从参与 Linux 的合作开发中获得的杠杆作用是：

杠杆率 = 62/12 ~= 5 倍

为了证明上述计算背后的逻辑，我们还需要补充一些说明：产品的收入取决于

1.潜在的市场总量（操作系统的市场总量约为数百亿美元）

2.产品的市场份额

3.限制产品市场份额的一个因素是其功能和特性在多大程度上满足了整个潜在市场的需求。例如，在早期，有人可能会说 Linux 并不适合所有类型的服务器工作负载，而且作为桌面操作系统，也许仍然不适合许多用户。某种程度上，产品所能服务的市场机会有多大，直接取决于产品所获得的工程投资。

从以上对红帽公司在 Linux 合作开发中的作用及其市场份额的分析中，我们可以得出这样的结论：如果红帽公司只作为单一供应商开发 Linux，那么 Linux 得到的工程投资总额将只有目前的 1/10。这反过来又意味着，Linux 在整个操作系统市场中的总市场份额可能只有当前市场份额的 1/10，因为它的产品会更弱，服务的客户也不会像现在这么多。(当然，更有可能的情况是，Linux 与市场毫不相干，市场份额非常小。）

另一方面，通过合作开发 Linux，整个 Linux 市场的规模要大 10 倍，而红帽公司已经成功地占领了这一更广阔市场的 62%。这似乎是一个极好的战略，它带来的收入是其他战略的 5 倍。

对第二大 Linux 供应商 Novell 也可以进行同样的计算：

•占所有代码提交数的 7.6%

•29% 的市场份额

•杠杆率 = 3.8 倍

Novell 似乎也从 Linux 的合作开发模式中获益匪浅，其市场份额几乎是其工程投资的 4 倍。这意味着 Red Hat 和 Novell 都从合作开发中获得了巨大收益--这就是通常所说的双赢局面。(当然，如果 Linux 是一个单一厂商的项目，那么 Novell 作为第二大厂商的份额将趋于零或微不足道，因此参与合作项目对第二大厂商的好处是相当巨大的）。

最后，我们应该指出的是，这些关于厂商收入和对 Linux 投资的观察结果与上文关于开源项目管理模式的论述是一致的：我们注意到，如果 Red Hat 公司单独开发 Linux，其规模将缩小约 10 倍。另一方面，这也正是 "超大型 "类别中 9 个由基金会管理和合作的项目与最重要的单一供应商项目的平均规模之间的差异。

从这些结果来看，一个显而易见的建议是，参与开放源代码开发和业务的供应商应考虑参与社区合作开发的项目--其中标准和熟悉的管理形式是非营利基金会。如果一个供应商目前控制着一个开放源码项目，那么它就应该探索将该项目转移到现有的基金会或创建自己的基金会。由于原来的供应商总是最有可能成为合作开发项目的主导供应商，因此，作为经验法则，供应商可以预期这一战略--如果得到充分执行--将导致：

•项目规模扩大 10 倍。

•供应商可以占领 50%或更多的市场份额。

•更大的开发社区也会带来 10 倍的潜在市场。