作者
顾钧
责编
胡巍巍
很多创业公司苦恼于如何设计开源项目的商业模式，以下内容是笔者目前对此问题的摸索，权当抛砖引玉。
开源许可证
既然我们决定了“Milvus向量搜索引擎”（笔者所在公司在GitHub上开源项目）要开源，第一步便是要选择合适的开源许可证。虽然自由软件创始人RMS曾经倡导Copyleft概念，但Copyleft也是一种特殊的Copyright。
那么，什么是开源许可证？简单来说，一个许可证只要经过OSI（OpenSourceInitiative）认证，就可以被称之为开源许可证。OSI有专门的流程来审核一个许可证是否符合开源定义（OpenSourceDefinition）。
比如说，MongoDB新设计的SSPL（SeverSidePublicLicense）在完成OSI认证之前，MongoDB只能说自己的许可证是源码可用（sourceavailable），而不能说自己是开源（当然，这个限制属于行业惯例，没有强制性）。
目前主流的开源许可证，可以在OSI网站上查询到。网上也有很多文章去比较各个许可证之间的不同（可参考阮一峰老师的博客），我就不一一赘述了。
这里主要结合我们的自身情况来谈一下开源许可证的选择。开源许可证简单来说，可以分为三档：
严格，以GPL2.0许可证为代表，典型软件是MySQL
适中，以Apache2.0许可证为代表，目前使用最广泛
宽松，以BSD，MIT，PostgreSQL许可证为代表，典型软件是PostgreSQL
熟悉数据库的朋友一定知道MySQL和PostgreSQL。MySQL是最流行的开源数据库，但PostgreSQL是衍生项目最多的开源数据库。现在的新项目很少使用GPL2.0许可证，它的传染性应该是大家最有顾虑的地方。
对于推广基础技术来说，MIT/BSD类的许可证是一个好选择。可能现在已经很少人使用FreeBSD。但它也还在不断的发展，因为采用非常宽松的2-Clause-BSD许可证，FreeBSD被不少厂商用来开发自己的闭源系统。
比如，Sony的PlayStation3和4的系统都基于FreeBSD，还有任天堂的Swtich游戏机也是。
Redis也采用宽松的3-Clause-BSD许可证（相比2-Clause多了对商标的使用限制）。不过，Redis整个工具链的许可证情况十分复杂。
以至于当Redis切换部分组件的许可证时，引起了业界很大的误解。因此中途将许可证变严格是件有点敏感的事情。
看起来颇为复杂的Redis许可矩阵
如果上策太急，下策太缓。那么就选择中间的Apache2.0。Apache2.0目前是Apache基金会与CNCF基金会推荐的默认开源许可证。
GitHub网站对Apache2.0许可证的简易说明
Apache2.0像其他开源许可证一样不限制商业使用，专利授权也默认包含其中。不过Apache2.0也明确规定了在此开源许可证下软件厂商的免责条款。这也就是开源软件公司提供订阅增值服务的法律基础。
不过即使是Apache2.0这么成熟的开源许可证，大家还是有一个担心：公有云。
需要防范公有云厂商吗？
开源软件与公有云的关系这两年有点紧张，一个比较流行的观点是公有云插管吸血开源软件，而对开源社区没有太多贡献。
不少开源项目开始寻找在公有云面前保护自己的方法。毕竟公有云的出现，一定程度上打乱了原有的开源商业模式。最终用户通过购买云服务，从公有云服务商那里得到了保障，开源厂商被绕开了。
于是，CommonClause应运而生。CommonClause是一种附加条款，开源厂商依然需要选择一个基本的主许可证。最终的形式类似：Apache2.0+CommonClause1.0。
CommonClause比较精炼，全文只有3句话。
CommonClause主要禁止他人在不增加开源软件价值的情况下，利用开源软件牟利。它的限制性主要体现在以下三点：
假设第三方在开源软件的基础上构建了一整套面向用户的应用，这套新应用增加了原开源软件的价值，那么这套新应用不会受到任何限制。这一点保证了开源厂商与合作伙伴之间的合作关系不会受到影响。
不过CommonClause没有经过OSI认证，因此添加了CommonClause以后建议只说自己是源码可用（sourceavailable）。虽然会引起一定的争议，不过初创开源项目选择添加CommonClause看起来正受到越来越多人的理解。
然而，我们的开源项目并不打算加上CommonClause。有两个重要的原因。
MongoDB的启示
MongoDB是开源项目成功的范例。MongoDB一开始就采用AGPL3.0许可证。如果公有云要利用MongoDB提供服务，那么公有云厂商需要公布相关底层服务的源码。因此，AWS，Azure，GoogleCloud等一众美国公有云都选择自行开发文档型数据库。
而在美国以外，MongoDB却很难用法律武器保护自己。年10月MongoDB修改新版本的许可证时，再次抱怨了公有云厂商对MongoDB利益的侵害，主要指的就是美国以外的公有云厂商。
因此，志在全球的开源基础软件厂商其实很难仅靠一个许可证来对自己进行全面的保护。
另一方面，当AWS有了DynamoDB；Azure有了CosmosDB；GoogleCloud有了CloudFirestore之后，文档数据库不再是MongoDB一家独大。在之后的移动互联网浪潮中，移动端的MongoDBMobile没有达到期待中的影响力。
毕竟Realm这样的移动端文档数据库可以直接和多个公有云文档数据库同步，极大的方便了移动开发者。年4月，MongoDB以万美元收购了Realm。
防范别人的同时也部分影响了自己的发展空间，是否值得？答案因人而异，开源项目需要结合自身情况作出一个选择。
四爷的新策略
据咨询公司Gartner的统计，GoogleCloud年占据公有云IaaS市场4.0%的份额，排行全球第四。依然不及老大AWS市场占有率（47.8%）的一个零头。GoogleCloud想迎头赶上，他该怎么办？
在今年的GoogleCloudNext大会上，新上任的GoogleCloudCEO一举请来了RedisLabCEO与MongoDBCEO帮忙站台。
大会上GoogleCloud推出了Redis的托管服务，MongoDB上了GoogleCloudMarketplace。后续MongoDB的Atlas云服务还和GoogleCloud展开了一系列合作。
Redis和MongoDB在开源界与互联网行业有较大的技术影响力。而且他们是开源界对公有云厂商开炮比较多的两家。
近期他们又先后针对公有云厂商修改了自己的许可证。因此GoogleCloudNext大会上传达的信息很有意思。
与成熟的开源厂商合作，看起来正是GoogleCloud的新策略。这条路值得一试。毕竟，老四恐怕很难用老大的方法来战胜老大。
齐白石曾说，“学我者生，似我者死。”GoogleCloud第一个想明白了。我相信会有越来越多的公有云厂商想明白这个问题，选择与成熟的开源厂商合作。所以对开源基础软件来说，当务之急是提升自身的成熟度，防范之心可以暂时放到一边。
商业设计
在文中，我们提到“Apache基金会拥有1.9亿行代码。根据COCOMOII模型估算，这些代码的开发成本超过亿美元（年报）。”如此算来，每一行代码的开发成本超过美元。所以千万别觉得开源软件就该免费使用。
典型的开源商业模式
目前比较成熟的开源软件商业模式有以下几种：
订阅服务：开源许可证免除了厂商对软件质量与软件缺陷修复的责任。而这些都是企业级应用所必须的。因此，最自然的商业模式就是提供软件订阅服务，从而向用户提供生产级的服务支持响应和hotfix修复。
高级功能：比如Redis。核心部分的组件是开源的。但工具类软件，进阶功能（如多租户，无共享分布式架构等）都是收费的。
云服务：比如Databricks。Spark是开源的，但收费版本仅提供Azure和AWS上的云服务。
生态收益（仅限超大型开源厂商）：比如据华尔街分析师估算Google每年要支付近百亿美元给Apple，就为了iPhone上的默认搜索引擎入口。想想Android帮Google省了多少钱？
软件世界里有两个重大难题：一是大型软件系统的项目管理（人月神话），另一个是软件定价。
关于项目管理，已经有了不少的研究与实践，大家多少有个参照物。而软件定价没有什么成熟的公式与模型。
但至少对于开源软件的定价，要避开下面两个坑：
定高价，打1折
不采用订阅模式
这些都是传统商业软件的模式。传统商业软件提供给客户的是资产，开源软件提供给用户的是服务。
如果大型用户要求对软件进行买断怎么办？大型用户倾向于一次性付费，并不是他们喜欢购买一堆软件资产。背后的原因在于大型用户内部的软硬件采购流程，需要采购人员与IT技术人员共同介入。
而采购并不是技术人员的本职工作，以及事后的各种审计。因此技术人员更喜欢一次性买断，以省去未来的麻烦。请提醒他们，开源软件提供的是服务，服务是不能买断的，应该走更便捷的服务采购流程。
向AWS学习
基础软件的商业化是件很有挑战的事情。好在有很多成熟的企业可供我们参考。如果说Oracle是必须研究的传统商业软件公司，那么AWS毫无疑问就是必须好好学习的云服务公司。
刚才说软件定价没有什么成熟的公式与模型？其实AWS帮大家摸索了一个公有云上软件的定价方式。
AWSAurora数据库据称是AWS上增长最快最赚钱的云服务。Aurora在技术上是非常创新的云原生数据库，带出了一众追随者。依据官方宣传：
AmazonAurora的速度最高可以达到标准MySQL数据库的五倍、标准PostgreSQL数据库的三倍。
它可以实现商用数据库的安全性、可用性和可靠性，而成本只有商用数据库的1/10。（引用自