开源软件商业模式的探讨

声明：咱们的开源项目“ Milvus 向量搜索引擎”还处在社会主义初级阶段。如下内容是咱们目前对开源工做的摸索，并不是最佳实践。

开源许可证

既然咱们决定了要开源，第一步即是要选择合适的开源许可证。虽然自由软件创始人 RMS 曾经倡导 Copyleft 概念，但 Copyleft 也是一种特殊的 Copyright 。

那么，什么是开源许可证？简单来讲，一个许可证只要通过 OSI （ Open Source Initiative ）认证，就能够被称之为开源许可证。 OSI 有专门的流程来审核一个许可证是否符合开源定义（ Open Source Definition ）。好比说， MongoDB 新设计的 SSPL （ Sever Side Public License ）在完成 OSI 认证以前， MongoDB 只能说本身的许可证是源码可用（ source available ），而不能说本身是开源（固然，这个限制属于行业惯例，没有强制性）。

目前主流的开源许可证，能够在 OSI 网站上查询到。网上也有不少文章去比较各个许可证之间的不一样（可参考阮一峰老师的博客），我就不一一赘述了。这里主要结合咱们的自身状况来谈一下开源许可证的选择。开源许可证简单来讲，能够分为三档：

• 严格，以 GPL 2.0 许可证为表明，典型软件是 MySQL
• 适中，以 Apache 2.0 许可证为表明，目前使用最普遍
• 宽松，以 BSD，MIT ， PostgreSQL 许可证为表明，典型软件是 PostgreSQL

熟悉数据库的朋友必定知道 MySQL 和 PostgreSQL 。 MySQL 是最流行的开源数据库，但 PostgreSQL 是衍生项目最多的开源数据库。如今的新项目不多使用 GPL 2.0 许可证，它的传染性应该是你们最有顾虑的地方。

对于推广基础技术来讲，MIT/BSD 类的许可证是一个好选择。可能如今已经不多人使用 FreeBSD 。但它也还在不断的发展，由于采用很是宽松的 2-Clause-BSD 许可证， FreeBSD 被很多厂商用来开发本身的闭源系统。好比， Sony 的 Play Station 3 和 4 的系统都基于 FreeBSD ， 还有任天堂的 Swtich 游戏机也是。

Redis 也采用宽松的 3-Clause-BSD 许可证（相比 2-Clause 多了对商标的使用限制）。不过， Redis 整个工具链的许可证状况十分复杂。以致于当 Redis 切换部分组件的许可证时，引发了业界很大的误解。所以中途将许可证变严格是件有点敏感的事情。

看起来颇为复杂的 Redis 许可矩阵。

若是上策太急，下策太缓。那么就选择中间的 Apache 2.0 。Apache 2.0 目前是 Apache 基金会与 CNCF 基金会推荐的默认开源许可证。

Github 网站对 Apache 2.0 许可证的简易说明

Apache 2.0 像其余开源许可证同样不限制商业使用，专利受权也默认包含其中。不过 Apache 2.0 也明确规定了在此开源许可证下软件厂商的免责条款。这也就是开源软件公司提供订阅增值服务的法律基础。

不过即便是 Apache 2.0 这么成熟的开源许可证，你们仍是有一个担忧：公有云。

须要防范公有云厂商吗

开源软件与公有云的关系这两年有点紧张，一个比较流行的观点是公有云插管吸血开源软件，而对开源社区没有太多贡献。很多开源项目开始寻找在公有云面前保护本身的方法。毕竟公有云的出现，必定程度上打乱了原有的开源商业模式。最终用户经过购买云服务，从公有云服务商那里的到了保障，开源厂商被绕开了。

因而， Common Clause 应运而生。 Common Clause 是一种附加条款，开源厂商依然须要选择一个基本的主许可证。最终的形式相似： Apache 2.0 + Common Clause 1.0 。

Common Clause 比较精炼，全文只有 3 句话，以下：

The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.

Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.

For purposes of the foregoing, "Sell" means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.

Common Clause 主要禁止他人在不增长开源软件价值的状况下，利用开源软件牟利。它的限制性主要体如今如下三点：

禁止他人	对软件生态构建的影响
利用原软件进行 license 销售	很是小。目前主流观点是开源软件不收取 license 费用，软件收费以按年支付的订阅模式进行。
提供软件支持服务	比较小。尤为是产品初期，你们都不了解，须要依靠官方支持。官方提供订阅模式，你们比较容易接受。产品的订阅收费模式可以获得保障。不过未来等产品成熟之后，须要考虑参照 Oracle 的 OCP 方式，提供一些针对专业人士的产品能力认证，以缓和这一点可能的影响。
提供软件托管服务	防范云厂商。限制云厂商不能经过托管云服务（ hosting ）的方式，利用原软件进行盈利。但不表明用户不能在云环境里使用该软件。Apache 2.0 + Common Clause 1.0 不会限制用户运行软件的硬件环境，只要用户购买订阅服务，产品方同样会提供支持服务。

假设第三方在开源软件的基础上构建了一整套面向用户的应用，这套新应用增长了原开源软件的价值，那么这套新应用不会受到任何限制。这一点保证了开源厂商与合做伙伴之间的合做关系不会受到影响。

不过 Common Clause 没有通过 OSI 认证，所以添加了 Common Clause 之后建议只说本身是源码可用（ source available ）。虽然会引发必定的争议，不过初创开源项目选择添加 Common Clause 看起来正受到愈来愈多人的理解。

然而，咱们的开源项目并不打算加上 Common Clause 。有两个重要的缘由。

MongoDB 的启示

MongoDB 是开源项目成功的范例。 MongoDB 一开始就采用 AGPL 3.0 许可证。若是公有云要利用 MongoDB 提供服务，那么公有云厂商须要公布相关底层服务的源码。所以， AWS ， Azure， Google Cloud 等一众美国公有云都选择自行开发文档型数据库。而在美国之外， MongoDB 却很难用法律武器保护本身。 2018 年 10 月 MongoDB 修改新版本的许可证时，再次抱怨了公有云厂商对 MongoDB 利益的侵害，主要指的就是美国之外的公有云厂商。所以，志在全球的开源基础软件厂商其实很难仅靠一个许可证来对本身进行全面的保护。

另外一方面，当 AWS 有了 DynamoDB ； Azure 有了 Cosmos DB ； Google Cloud 有了 Cloud Firestore 以后，文档数据库再也不是 MongoDB 一家独大。在以后的移动互联网浪潮中，移动端的 MongoDB Mobile 没有达到期待中的影响力。毕竟 Realm 这样的移动端文档数据库能够直接和多个公有云文档数据库同步，极大的方便了移动开发者。2019 年 4 月， MongoDB 以 3900 万美圆收购了 Realm 。

防范别人的同时也部分影响了本身的发展空间，是否值得？答案因人而异，开源项目须要结合自身状况做出一个选择。

四爷的新策略

据咨询公司 Gartner 的统计， Google Cloud 2018 年占据公有云 IaaS 市场 4.0% 的份额，排行全球第四。依然不及老大 AWS 市场占有率（ 47.8% ）的一个零头。 Google Cloud 想迎头遇上，他该怎么办？

在今年的 Google Cloud Next 大会上，新上任的 Google Cloud CEO 一举请来了 Redis Lab CEO 与 MongoDB CEO 帮忙站台。大会上 Google Cloud 推出了 Redis 的托管服务， MongoDB 上了 Google Cloud Marketplace 。后续 MongoDB 的 Atlas 云服务还和 Google Cloud 展开了一系列合做。

Redis 和 MongoDB 在开源界与互联网行业有较大的技术影响力。并且他们是开源界对公有云厂商开炮比较多的两家。近期他们又前后针对公有云厂商修改了本身的许可证。所以 Google Cloud Next 大会上传达的信息颇有意思。 与成熟的开源厂商合做，看起来正是 Google Cloud 的新策略。这条路值得一试。毕竟，老四恐怕很难用老大的方法来打败老大。

“学我者生，似我者死。” —— 齐白石

Google Cloud 第一个想明白了。我相信会有愈来愈多的公有云厂商想明白这个问题，选择与成熟的开源厂商合做。因此对开源基础软件来讲，当务之急是提高自身的成熟度，防范之心能够暂时放到一边。

商业设计

在上一篇文中，咱们提到“ Apache 基金会拥有 1.9 亿行代码。根据 COCOMO II 模型估算，这些代码的开发成本超过 200 亿美圆（ 2019 年报）。”如此算来，每一行代码的开发成本超过 200 美圆。因此千万别以为开源软件就该无偿使用。

典型的开源商业模式

目前比较成熟的开源软件商业模式有如下几种：

• 订阅服务：开源许可证免除了厂商对软件质量与软件缺陷修复的责任。而这些都是企业级应用所必须的。所以，最天然的商业模式就是提供软件订阅服务，从而向用户提供生产级的服务支持响应和 hotfix 修复。
• 高级功能：好比 Redis 。核心部分的组件是开源的。但工具类软件，进阶功能（如多租户，无共享分布式架构等）都是收费的。
• 云服务：好比 Databricks 。 Spark 是开源的，但收费版本仅提供 Azure 和 AWS 上的云服务。
• 生态收益（仅限超大型开源厂商）：好比据华尔街分析师估算 Google 每一年要支付近百亿美圆给 Apple ，就为了 iPhone 上的默认搜索引擎入口。想一想 Android 帮 Google 省了多少钱？

软件世界里有两个重大难题：一是大型软件系统的项目管理（人月神话），另外一个是软件订价。关于项目管理，已经有了很多的研究与实践，你们多少有个参照物。而软件订价没有什么成熟的公式与模型。

但至少对于开源软件的订价，要避开下面两个坑：

• 定高价，打 1 折
• 不采用订阅模式

这些都是传统商业软件的模式。传统商业软件提供给客户的是资产，开源软件提供给用户的是服务。

若是大型用户要求对软件进行买断怎么办？大型用户倾向于一次性付费，并非他们喜欢购买一堆软件资产。背后的缘由在于大型用户内部的软硬件采购流程，须要采购人员与 IT 技术人员共同介入。而采购并非技术人员的本职工做，以及过后的各类审计。所以技术人员更喜欢一次性买断，以省去将来的麻烦。请提醒他们，开源软件提供的是服务，服务是不能买断的，应该走更便捷的服务采购流程。

向 AWS 学习

基础软件的商业化是件颇有挑战的事情。好在有不少成熟的企业可供咱们参考。若是说 Oracle 是必须研究的传统商业软件公司，那么 AWS 毫无疑问就是必须好好学习的云服务公司。

刚才说软件订价没有什么成熟的公式与模型？其实 AWS 帮你们摸索了一个公有云上软件的订价方式。AWS Aurora 数据库据称是 AWS 上增加最快最赚钱的云服务。 Aurora 在技术上是很是创新的云原生数据库，带出了一众追随者。依据官方宣传：

Amazon Aurora 的速度最高能够达到标准 MySQL 数据库的五倍、标准 PostgreSQL 数据库的三倍。它能够实现商用数据库的安全性、可用性和可靠性，而成本只有商用数据库的 1/10。（引用自 https://aws.amazon.com/cn/rds/aurora/ ）

那么这样一款技术如此先进的云上数据库是怎么订价的呢？如下对比 Aurora MySQL 全部可选的实例规格与 RDS MySQL 之间的订价：

云实例规格	RDS MySQL	Aurora MySQL	Aurora 溢价
db.t3.small	0.034	0.041	20.59%
db.t3.medium	0.068	0.082	20.59%
db.t2.small	0.034	0.041	20.59%
db.t2.medium	0.068	0.082	20.59%
db.r5.large	0.24	0.29	20.83%
db.r5.xlarge	0.48	0.58	20.83%
db.r5.2xlarge	0.96	1.16	20.83%
db.r5.4xlarge	1.92	2.32	20.83%
db.r5.12xlarge	5.76	6.96	20.83%
db.r4.large	0.24	0.29	20.83%
db.r4.xlarge	0.48	0.58	20.83%
db.r4.2xlarge	0.96	1.16	20.83%
db.r4.4xlarge	1.92	2.32	20.83%
db.r4.8xlarge	3.84	4.64	20.83%
db.r4.16xlarge	7.68	9.28	20.83%

单位：美圆/小时

固然 Aurora MySQL 和 RDS MySQL 的技术实现不太同样，一样实例规格须要的硬件也不能简单划上等号。不过考虑到 AWS 自己的体量，二者间硬件差别的成本应该是微乎其微的。能够大体认为 20% 的溢价来自 Aurora MySQL 软件。

基础软件上公有云 Marketplace 的时候怎么订价，总算有个参照物了。

后记

虽然写了两篇文章，但也只是涉及了开源的一小部分。开源模式可一点也不比传统商业软件的模式要简单。

其中比较关键的社区运营和开发者生态构建，咱们也还在不断的摸索。等有一天咱们造成本身的方法与风格，届时必定与你们分享。但愿国内的基础软件同行都能一块儿进步。