开源软件如何盈利？开源软件公司赚钱的 5 种方式

开源软件盈利的五种商业模式：1.技术支持；2.托管服务；3.限制性许可；4.开放核心；5.开源开发者工具。除此以外，考虑盈利前每家开源公司所需的两个先决条件：先决条件#1：广泛采纳；先决条件#2：可信度。

如何评估您所使用（或考虑亲自开发）的任何开源软件背后业务的长期可持续性的指南。

随着开源软件愈发盛行，我们常听到的一个问题便是：这些项目是如何盈利的？换句话说：我如何确保那些我们使用的开源软件厂商不会倒闭？这些问题皆是同一个直接问题的不同形式。然而，答案却是复杂且不断变化的。

目前世界上已有一群开源软件企业，其中一些已经上市，年收入超过1亿（甚至10亿）美元：RedHat, Cloudera / Hortonworks（Hadoop）, MuleSoft, Automattic（Wordpress）, Elastic, MongoDB, Acquia（Drupal）, Hashicorp, Confluent（Kafka）, Databricks（Spark）等。（这里有超过30家。）若我们分析他们的成功，会发现他们构建可持续业务的共同模式。

在本文中，我们通过分享这些开源软件企业用以盈利的五种商业模式，来描述这一共同特点。

若您在自家企业内部应用开源软件，或是经营着属于自己的开源事业，抑或仅仅在考虑加盟一家开源初创公司，深入了解这些商业模式不仅能协助您准确评估软件产品的质量，更能洞察背后企业的长期可持续发展潜力。

但首先，每家开源公司在考虑盈利之前都需要满足两个先决条件。

考虑盈利前每家开源公司所需的两个先决条件

先决条件#1：广泛采纳

第一个先决条件是广泛采纳：开源项目需要拥有庞大的用户基础。

广泛的采纳是不可或缺的因素，因为开源公司仅能从其所创造的价值中获得微薄的一部分收益。更明确地说，开源公司将其研发出的绝大部分（如果非全部）软件免费提供，而多数用户却永远不会为之支付费用。

实际上，绝大多数开源产品的货币化转换率——即从用户至付费客户的转化比例——通常是相当微小的，往往仅为低位数的百分比，甚至更低。然而，只要拥有足够庞大的社群规模，这一微薄的转换率也将变得足够有力。这种现象是推动开源商业模式中规模经济运作的关键因素之一。换言之，广泛采纳的必要性也是开源领域中“赢家通吃”现象频繁出现的原因之一。

这种对前期大规模投资的迫切需求，也就成为如今绝大多数成功的开源公司最初为何会作为大型企业内部的项目（如Hadoop/HDFS起初在Yahoo!，Kafka起源于LinkedIn，Kubernetes则发源于Google）、学术研究产物（例如，Spark初始于伯克利）或是依赖风险资本支持的初创企业崭露头角的原因之一。

先决条件#2：可信度

第二个前提条件是社群内部拥有主导性的信誉。这一点至关重要，正因如此开源公司方能构建出高效的销售与营销渠道，这在货币化率相对较低的环境中显得尤为重要。

持有“主导信誉”意即当人们需要软件援助时，首选便是这家开源公司而非其他选择。缺乏此类信誉将意味着不得不与市场上其他竞争者争夺公众的注意力，导致业务模式的有效性和利润率大打折扣。

主导信誉的价值通常是通过成为项目的主导贡献者来赢得的。以Elastic（市值459亿美元，年收入1.6亿美元，29倍）和MongoDB（市值397亿美元，年收入1.55亿美元，26倍）相较于（合并前的）Hortonworks（市值123亿美元，年收入2.62亿美元，5倍）与Cloudera（市值173亿美元，年收入3.67亿美元，5倍）的市值、年收入和倍数为例即可见一斑。（以上数据截至2018年11月27日；收入数字源自最近一次公布的财年报告。）

由于Elastic和MongoDB在其各自的社群内拥有不可或缺的主导地位，他们成功地构筑了更为高效的商业模式，以相对较低的收入就能捕获更多的价值。与之对比，Hortonworks和Cloudera则不得不筹措更多的资金，在Hadoop市场中与对手展开激烈的竞争。（甚至有理由推测，主导信誉的迫切需求或许是近期Hortonworks与Cloudera合并背后的一个动因。）

一旦开源公司赢得了广泛的市场认可和权威性信誉，便可以着手建立需要其技术协助的企业渠道，并逐步实施多元化的商业模式，以构筑一个可持续发展的企业。

现在，让我们讨论那些商业模式。

五种开源商业模式

通过分析当今成功的开源公司，出现了五种常见的商业模式：

技术支持
托管
限制性许可
开放核心
混合许可

1.技术支持

技术支持，这一模式也被俗称为“红帽模型”，其主要运营机制包括：向在生产环境中实施项目的企业提供部署与集成服务，推出面向生产环境的“保险策略”，以及提供经过认证的二进制文件、专业培训、错误纠正等。

该模型在长期运营中存在诸多局限性：（1）技术支持通常需要大量手工操作，从而降低企业的利润率；（2）由于支持工作往往不易标准化，规模扩张变得困难；（3）这一模型可能导致开源公司产生不良激励，使产品易用性的提高会侵蚀到支持收入。实际上，当一个项目涉及复杂的部署要求和庞大的生态系统时，该模型通常能展现出其优越性，尽管这种优越性与提供最佳用户体验的目标存在一定的矛盾。

该模型因其效益低下而广受诟病，通常只有不足1%的用户最终转化为付费客户。这一现象其实并非出人意料。开源软件本质上是免费的，只有当企业在关键任务中严重依赖某一开源项目时，方会觉得有必要支付额外的技术支持费用。然而，随着时间的推移，对该项目产生高度依赖的企业逐渐会投入自身的工程资源以深入研究该项目，从而降低对外部技术支持的依赖。因此，该模型仅在特定的应用窗口期内显示出其有效性。

尽管面对如此多的挑战，技术支持模型仍是当今开源企业普遍采用的初始商业模式。然而，考虑到红帽在过去的25年里是唯一一个在开源领域成功实现了数十亿美元营收的企业，显然，开源公司若想获得持续成功，需要的远不仅是单一的技术支持模型。

2.托管服务

托管服务模型意味着为特定项目提供全托管的版本，从而允许用户仅通过几次简单的点击就能启动远程服务器，无需担心项目的稳定性问题，比如备份、停机时间和升级等诸多方面。考虑到云计算和托管服务的普及，这种商业模式逐渐在开源领域内获得了广泛的应用。

尤其值得注意的是，这也成为了公共云服务供应商（尤其是AWS）在不贡献于开源社群的前提下，实现开源项目商业化的主要手段，从而也引发了一定程度的社群抱怨和紧张关系（这也催生了其他商业模式的出现，稍后将予以探讨）。

该模型已被证实具有可行性，一些企业（如Databricks和Acquia）已在这一领域取得了显著的成功。然而，值得指出的是，托管服务模型常常与下文所列的几种其他商业模式存在某种程度的交集。

3.限制性许可

限制性许可模型为使用开源软件的个体或组织提供了一个付费的法律依据。该模型通过推出含有繁琐条款的开源许可证，强烈激励任何希望在生产环境中应用此类软件的方案与供应商达成商业合作。例如，GPL和AGPL许可证，以及近年出现的Commons Clause（在某些Redis模块中已被应用）都是该模型的典型代表。值得注意的是，AGPL和Commons Clause（还有MongoDB新近推出的SSPL许可证）往往被设计用于抵御公共云服务提供商的不当商业行为。

但是，这种方法有其局限性：基于GPL的许可证并不限制对未经修改软件的使用，并且仅在软件被修改且修改者不愿将其开源时才触发限制性条款；另外，Commons Clause在其条款语言中存在某种程度的模糊性，至今尚未明确这在法律层面将如何运作。最为关键的是，这类限制性许可证往往会成为软件广泛采纳的阻碍，让潜在的用户或采购方望而却步。尤其是，不少大型企业明确规定避免使用带有限制性条款的许可证。由于该模型固有的摩擦和限制，许多人遂选择回避此路，转向其他更具灵活性和可行性的商业模型。

4.开放核心

开放核心模型近年来迅速崭露头角，逐渐成为开源企业实现盈利的主流方式。该模型的基本思路在于，代码库的主要部分为开源形态，而一小部分则为专有代码，专门针对生产环境或企业级用户。这些专有部分或许以与开源基础部分接口对接的独立模块或服务的形式出现，或以开源基础的分支版本发布。

专有功能一般涵盖面向生产环境部署或大规模使用所需的各种特性。以开源数据库为例，像监控、管理、数据备份与恢复、以及集群化等功能往往会被设置为专有特性。此模型的一大优势在于，它允许开源企业使用相对宽松的许可证（例如Apache 2.0）来许可其开源核心，同时维持对专有代码的完全控制权。如此一来，这类许可证的广泛使用有助于软件的普及与推广。一旦客户开始使用专有功能，开源企业便能从这些客户那里实现长期、稳定的收入。

然而，此模型同样面临一系列挑战，其中一个便是如何平衡其商业模型与开源核心之间的界限，以便在短期收益与长期项目可持续性之间达成均衡。

5.开源开发者工具

这是一种极富探索性的商业构想，它在代码发布方式上采纳了一种较为中庸的立场。比如，Snyk、CircleCI与GitHub Actions等产品在开发者群体中享有盛誉，原因在于它们专用于构建与维护开源代码，尽管它们本身并未全面开源。这些开发者工具常以免费的基础版本为用户提供服务，而进阶功能与额外资源则需付费解锁。这一经营模式往往与软件即服务（SaaS）模型交织在一起，即用户可通过云端使用这些工具，从而免去了本地部署的必要。

最终，这并非一份详尽无遗的清单，开源商业模型仍在持续地创新与演进。然而，这些模型大多数已历经时光的洗礼，被证明为当前最为主流且成功的经营策略。