PingCAP，中国第一只开源独角兽总融资达3.4亿美元，不能错过的开源深度解析

开源软件(OSS)指的是源代码可供用户免费使用、分发、修改的软件。任何用户都可以免费获取源代码，并对其进行修改并且分发自己的程序版本。除此之外，用户还可以根据需要，分发尽可能多的原始程序副本。任何人都可以出于任何目的免费使用该程序，也没有授权费或其他限制。

举个例子，譬如 Ubuntu 是一个开源操作系统。任何人都可以免费下载 Ubuntu，根据需要创建任意数量的副本，然后将其提供给他人。用户可以在不限数量的计算机上安装 Ubuntu，然后在 Ubuntu 中下载程序的源代码并进行修改从而创建一个属于自己的自定义版本。有了开源许可证就可以执行以上这些操作，闭源则会施加诸多限制。开源软件的反义词是闭源软件，他限制了用户的权利并保留软件的源代码。Firefox，Chrome，OpenOffice，Linux和 Android 是开源软件的一些流行示例，而Microsoft Windows 则可能是最受欢迎的闭源软件。

1. 共创性：由于可以自由访问源代码并且开源社区非常活跃，很多不同的程序员会积极参与，贡献、检查或改进源代码。

2. 透明度：程序员可以确切知道哪些类型的数据或者源代码做了改动，自己检查和追踪这些改动而不必依赖供应商。

3. 可靠性：一般来说专有的代码依赖于公司或者个人保持其更新、修补和运行。开源代码则会有更长的生命周期，通过活跃的开源社区不断更新，开放性和共创性可以确保对开源代码进行适当且频繁的调试。

4. 灵活性：由于可以自由更改源代码，用户可以根据自己实际的需求和问题做很多自定义的修改，并且可以依靠开源社区和同行去评估和检查自己的新方案。

5. 低成本：使用开源软件，代码本身是免费的，但有时需要为技术支持、附加功能和/或管理服务等支付费用（譬如 Red Had）。

6. 更自由：可以将开源代码应用于任何用途。

7. 开放式协作：一个活跃的开源社区意味着用户可以找到一个集资源、观点、技术支持为一体的超级社区。

最初的开源项目并不是真正的商业行为，而是对于封闭源代码软件公司正在获得的不正当利润的革命。微软，甲骨文，SAP 等巨头从软件提取类似垄断的“租金”，而当时的顶级开发人员并不认为这些软件是世界一流的。因此，从最广泛使用的基础软件（操作系统和数据库）开始，渐进式开发人员通常以异步方式协作来编写出色的软件。每个人不仅可以看到公开的源码，还可以通过松散的管理模型来添加、改进和增强它。

此类软件最初是为了开发人员而创建的，而这意味着一开始它对普通用户通常并不容易上手。但其通过高效性和灵活性逐渐渗透到整个软件领域，并且在十多年来， Linux 成为第二流行的服务器操作系统（仅次于 Windows），MySQL 也蚕食了 Oracle 的统治地位。

最初的创业企业试图通过为这些软件提供订阅制的“企业级”支持和服务收取费用盈利。RedHat 就是最早利用这一模式成功的企业。然而这样的模式和业务存在明显的局限性，仅靠支持服务这种低毛利重人力的方式很难让大多数开源软件盈利，但是 OS 和数据库的市场规模如此之大，以致于尽管存在更多挑战性的业务模式，但仍可以建立规模较大的公司，譬如 RedHat。

第一批开源业务的成功为第二代开源公司奠定了基础，这一代的主要代表人物是 Cloudera 和 Hortonworks。这些开源项目和业务在两个方面都与第一代产品有着根本的不同。首先，该软件主要是在现有公司内部开发的，而不是由广泛的非附属社区开发的（例如 Hadoop 是在 Yahoo 内形成的）。其次，这些项目中只有部分是免费的，因此它们可以根据商业授权向客户收取使用某些特定软件的费用。这样的设计是专门为企业生产使用而构建的，因此更容易获利。即使这些产品的市场没有操作系统和数据库那么吸引人，这些公司也有能力获得更多的收入。

但是这种第二代的开源业务模型也有局限。首先是没有一家公司对软件拥有道德权威，因此竞争者可以通过提供更多免费的软件来争夺利润。其次，这些公司经常对软件的发展进行平衡，以求与众不同。另外一点让事情变得更加困难的是，这些企业在最初构建时就没有考虑云服务，因此云服务商可以使用开源软件来创建具有相同软件基础的 SaaS 业务。亚马逊 EMR 就是一个很好的例子。

最新的发展是创业者抓住了开源第一代和第二代中存在的业务模型挑战，并用两个重要元素对项目进行开发。首先是开源软件现在主要在企业内开发。通常，这些项目中 90% 以上的代码是由该商业化软件公司的员工编写的。其次，这些企业从很早就开始将自己的软件作为云服务提供。从某种意义上来讲，这些是开放核心/云服务混合业务，具有多种途径使得产品获利。通过以SaaS的形式提供产品，这些企业可以将开源软件与商业软件交织在一起，因此客户不再需要担心应该获得哪个许可证。诸如 Elastic，Mongo和 Confluent 之类的公司以及诸如 Elastic Cloud，Confluent Cloud 和 MongoDB Atlas 之类的服务就是第三代的例子。这种演变的深刻意义是开源软件公司现在有机会成为该领域的软件基础架构的主导业务模型。

开放核心已经迅速成为开源公司最流行的赚钱方式。开核背后的想法是大多数代码库都是开源的，而留有较小比例（针对生产或企业用户）是专有的。这部分专有的部分可以打包成独立的模块或者服务与开源的部分连接，也可以分发到开源基础的分支版本中。

优势

通常，专有功能是生产部署和/或大规模部署所需的功能。例如，对于开源数据库，监控、管理、备份/还原和群集管理等功能通常是专有的。这样做的好处之一是，它允许开源公司以非常宽松的执照来授权核心（例如 Apache 2），同时保留对专有功能收费。它还允许开源公司通过在专有代码库中保留某些功能来抵御譬如公有云提供商。

挑战

这种模式的挑战在于如何平衡开源价值和专有权：如果一家公司开源的部分太多，那么它就放弃了赚钱的机会。反之，如果开源的部分太少，那么该项目就很可能无法得到广泛的采用。

另一个挑战是，有时很难将开源代码与代码中的专有功能区分开来。即使将它们分开很容易，但从工程的角度来看，维护两个不同的代码库也可能是一个挑战：例如管理独立版本的发行版可能需要互操作和/或来回移植代码以防止代码随时间推移而发散。通常，工程师宁愿在开源仓库中工作，也不愿在“业务”仓库中工作。 

应用场景

人们开始注意到开放核心的设计模式和公司的商业产品是互补的，而不是相互冲突的。这些包括：易于使用的模式：SaaS, UX, 协作工具；企业模式：可伸缩性，安全性，管理和集成；解决方案模式：用例特定功能

促使作出开核模式主要有两个因素：1. 对企业用户有价值的功能；2. 不太可能由社区提供，也不在开放核的路线图上。对于开源成功的案例，包括 Confluent，Elastic 和 Github 之类的产品，都是采用 Open-core 为主要的商业模型。

提供服务/支持模型也被称为“ RedHat ”模型，向在生产中部署项目的企业出售部署和集成服务以及经过认证的二进制文件、培训、错误修复等。早期的开源模型通常基于专业服务，而公司则需要提供技术支持和咨询服务。

限制

由于以下几个原因，该模型在长期内会受到限制：1. 专业服务通常需要大量的人工工作，因此降低了业务利润率；2. 扩张很困难，因为专业服务通常不容易复制；3. 它会给开源公司造成不合适的激励，即提升产品易用性反而会蚕食专业服务的收入。实际上，当项目需要具有庞大生态系统的复杂部署时，此模型非常有效，但这常常不利于建立最佳的用户体验。

此外服务收入通常是极不可预测的，这会使公司在财务预算以及收入转移时面临风险。另外，专业服务的利润率也比基于产品的公司要低得多。2019 年，RedHat 的服务毛利率仅为 31％，而订阅的毛利率为 93％。这意味着为了聘请额外的核心人员，红帽必须从咨询业务中获得 3 倍的收益。利润率的巨大差异意味着以咨询为基础的开源业务通常依赖于大量顾问人员，资源有限，无法用于开发其核心开源产品。

在过去的十年中，托管已成为开源公司（尤其是在数据空间中）的常见产品，使最终用户能够以类似于 SaaS 产品的方式使用基础架构组件，而不必担心管理基础架构的运营开销。

托管意味着提供项目的完全托管版本，以便当用户想要试用项目，甚至将其部署到生产环境中时，只需单击几下即可使用该软件并启动远程服务器，而不用担心它会在不稳定状态下运行（即不用担心备份、停机、升级等）。

应用场景

近年来，云托管提供商（最著名的是 AWS）已开始为常见的开源软件提供托管解决方案，从而进一步降低了开源公司的利润。这导致 Redis 和 MongoDB 等许多开源产品更改了许可证，以防止来自云供应商的竞争。

Confluent 和 Elastic 等公司选择的则是另一种策略，专门在其托管服务中提供开核中不可用的功能，从而创建混合托管/开核模型。值得注意的是，托管对于这些企业而言通常是一笔可观的收入（超过 1 亿美元），但通常是次要的收入来源，而不是主要的收入来源。

限制性授权模型为开源软件的用户付款提供了合法的理由。它通过提供带有稍微繁重条款的开源许可证来做到这一点，从而使在生产环境中使用该软件的用户都被鼓励与供应商达成商业交易。GPL 和 AGPL 授权以及新的 Commons Clause（被某些Redis 模块采用）是该模型的示例。特别是，AGPL 和 Commons Clause（以及 MongoDB 新推出的 SSPL）也是旨在抵御公有云提供商。

局限

但是这种方法有局限性：基于 GPL 的授权模式不限制未修改的用法，仅在进行了修改并且不希望开源的情况下适用；普通条款的措词含糊不清，这种方法的最大缺点是这些许可证损害了采用率，经常会劝退潜在用户。特别是当有相当多的大型公司制定了明确的政策，禁止使用限制性授权。由于这种方法的局限，许多人都选择了其他的业务模型而将其放弃。

混合授权模式是此列表中最新的一种。混合授权最初由 CockroachDB 推广（2017年1月），后来由 Elastic（2018 年 2 月）采用。混合授权采用了开核方法，但在一些关键方面对其进行了改进。

混合授权的作用是将开源代码和专有软件混合在同一代码库中，然后使整个库的代码可用。也就是说，整个代码库都是“开放代码”（或“可用资源”），但并非所有库都有经过 osi 批准的开源授权。用户可以选择使用带有开源代码的源文件（在开源代码授权下），或者选择同时使用带有开源代码和专有源码（在私有许可证下可用）。专有授权的源码通常具有默认情况下处于关闭状态的付费功能，但可以通过购买许可证密钥来解锁。

优点

对于开源公司来说，这种方法的优点包括所有在开核模式下列出的优点，以及：1. 将所有内容都放在同一个代码库中，可以更轻松地管理工程和开发流程；2. 使整个团队能够从事核心项目；3. 允许用户从免费无缝升级到付费版本（也无需通过销售人员）；4. 允许外部社区成员使用通常用于开源功能的同一工作流程（例如，通过GitHub）进行评论、提交代码以及对专有功能做出贡献。

当然，最大的挑战也与开核模式类似：公司需要平衡开源与专有功能的数量和价值。

10 年前，当我们最初在讨论开源软件时，我们满怀希望地梦想看到标志性开源公司的诞生。在只有 Red Hat 模式的时代，我们相信还会有更多模式出现。今天，我们看到了健康的开源业务群体，这非常令人兴奋。我相信这些从开源社区中涌现出的标志性公司才刚刚开始。这些价值数十亿甚至上百亿美元的公司证明了这种模式的强大潜力。显而易见的是，开源不再是软件开发的一种附带手段。在未来的十年中，这些开源公司将持续成长，继续完善和发展他们的产品和组织架构。趋势是不可否认的，我们很荣幸能够在此旅程的早期就开始鉴证未来 10 年中国能有更多 PingCAP 们，理想主义终能结出硕果累累。