开源数据库已死了吗 ？

　　作者：Tony Baer 是 IT 外媒 ZDnet 的特约撰稿人（云头条编译）

　　Elasticsearch 将其软件堆栈的核心由 Apache 2 改为一种限制性更强的许可证，再次提出了开源数据库有没有未来这个问题。但是，也许我们不应该太纠结于许可问题。

　　旧梦重温。

　　上周 Elastic 掀起了另一波改换许可证的热潮，这回是针对它上一次改换许可证没有涵盖的其余产品。改换许可证的是其主打产品：Elasticsearch 搜索引擎和 Kibana 可视化平台，它们由开源 Apache 2 许可证换成了服务器端公共许可证（SSPL），而 SSPL 是 MongoDB 早在 2018 年推出的一种伪开源许可证。几天后，AWS 宣布了分支（fork）作为回应，这不足为奇。

　　听到许可证更换后我们的第一反应是，至少 Elastic 并没有发明另一种怪异的新许可证，而是直接拿来一种许可证。客户法务部门尽可放心，它们不必审查另一种奇怪的许可分支。其次，在我们开始上网搜索所有细节之后，cookie 跟踪机制引发了 ChaosSearch 的一大波“节省 Elasticsearch 日志分析成本”方面的广告。

　　这是一出没完没了的好戏的最新进展：

　　开源数据库能否避免成为自己成功的受害者？它的历史可以追溯到 MongoDB 在 2018 年拥抱 SSPL，随后 Redis、CockroachDB 和 Confluent 纷纷宣布了各自的准开源许可证。与此同时，MariaDB 依然保留了经典的 GPL 许可证，以阻挡所谓的云掠夺者。这个领域发生了太多的动荡。但是阿根廷，别为我们哭泣，这些玩家中大多数已经成为独角兽，或已经成功上市。

　　在过去这几年，我们数次回顾了这出好戏。大概五年前，IT 外媒 ZDNet 就提出了这个问题：开源是否正在成为企业软件的新的默认模式。有人称之为较单纯的年代，当时 Black Duck Software 开展的年度《开源未来调查》表明，2010 年至 2015 年，企业中开源代码的使用量翻了一番（Black Duck 如今不再开展这种调查）。

　　开放核心模式

　　就在衍变的开源许可证突然猛增之后，我们想知道开放核心模式是否可以打消业界的忧虑。Grafana 等一些产品继续使用这种模式，其中核心虚拟化引擎采用 Apache 2 许可证，而面向企业数据源的适配件插件不是采用这种许可证。然而，其他人却称开放核心纯属垃圾。

　　尽管存在种种忧虑，开源在一些领域（比如大众化基础架构）的日子仍然过得很滋润。如今，除了 Red Hat、SuSE、Ubuntu 及另外少数几家公司外，没有谁在 Linux 版本的多样性上能竞争。另外，尽管对 Kubernetes 的贡献以谷歌为主，但这种容器编排工具已成为开发新云原生服务的新兴的事实上标准。开源在 AI 框架等迅速创新的领域也搞得有声有色。数据科学家等从业人员渴望自己的简历上有流行的开源项目，以便自己的技能在就业市场上很吃香。

　　但是对于数据库来说，可能忍不住将倒戈投向限制性许可视为对开源敲响了丧钟。几个月前，就在 Snowflake 上市后，Matt Asay 提出了同样这个问题，他早在目前担任 AWS 的开源战略负责人之前就投身于开源领域。他还提出，首先，就连 Snowflake 之类的专有产品也在其产品中利用大量的开源代码。其次，他在谈到与 Cloudera 前负责人 Mike Olson 的交流时称，云服务已经成为产品差异化的新手段。

　　我们完全同意 Olson 的观点。只要看一下 MongoDB。截至最近一个季度即 2021 财年第三季度，该公司报告客户群中 90% 以上使用 Atlas 云服务。Elastic 的 2021 财年第二季度业绩显示，SaaS 收入同比猛增 81%，现在占其业务的近 30%。它们对抢夺其业务的 AWS 很警惕，但是它们做到了 AWS 做不到的一件事：它们的托管数据库云服务在三大云上都可以正常工作，而 Amazon Elasticsearch Service 做不到这点。

　　虽然许可证可能会保护产品，但只有客户在购买您所销售的产品，您才有要保护的对象。在云计算加快采用的时代，搞好 SaaS 大概比斟酌所有法律术语都来得重要。这意味着精通这方面的策略：交付合适的服务级别协议（SLA），并提供精心设计的云服务能够提供的操作简化。而这常常意味着搞好 Kubernetes、安全和客户体验之类的方面。云知识产权（Cloud IP）主要不是来自可授予许可证的代码，而是扎根于基础架构和运营专业知识、合理的架构设计以及设计理念。

　　如果更深入地研究，我们可以看到数据库领域出现明显的对照。一方面，诸如 PostgreSQL、Cassandra 以及最近的 Spark 之类的常青项目蓬勃发展；这些项目的共同点是它们都是基于社区的。与此同时，Splice Machine 之类的以前专有的公司正在拥抱开源，而如上所述，独角兽们却在收缩开源力度。那么，到底怎么回事？

　　永远的阶级斗争？

　　一种简单的解释是，如今出现了一种阶级分化。一边是有财产需要保护的富人，另一边是渴望拥有地位的穷人，他们开放其代码，以期一举成名。

　　PostgreSQL 可以说是数据库领域基于社区的开源项目的最成功典范，它已存在了很长时间，具体来说已有 25 年。PostgreSQL 是 Michael Stonebraker 的杰作之一，没有哪家供应商控制大权，贡献的代码明显分散在广泛的社区中，许可证极其宽松：几乎唯一的限制就是项目发源地加利福尼亚大学的安全港条款。

　　因而，数据库生态系统几乎到处都是形形色色的的 PostgreSQL 分支，从 EnterpriseDB 到 Amazon Redshift、Greenplum 和 Netezza，再到 AWS、Azure 和 GCP 等供应商的一大批云服务，不一而足。而 PostgreSQL 开源许可证的灵活性为 AWS 和 Azure 提供了超大规模计算方面进一步创新的机会。在 PostgreSQL 社区，分支（fork）不是什么肮脏的词。这个社区带来了技能基础，技能基础反过来带来了能够将 PostgreSQL 带到他们想去的地方的供应商。难怪，早在几年前，我们提出了关于 PostgreSQL 的时代是否终于到来的问题。

　　至于那些渴望一炮打响的公司，您会发现 Splice Machine、Yugabyte 和 Couchbase 之类的公司将开源视为吸引开发人员关注的一种手段。这也是回应这个问题：对于企业而言，将精力和资源投入到小规模专有供应商实施的系统带来了更大的风险，因为底层技术的成败完全取决于这家供应商。然而，单单一家供应商完全走商业化道路的开源项目可能存在类似的风险。

　　那么，我们是否注定面临永恒的阶级斗争，即有钱人一旦获得成功，就禁止访问其代码，从而阻止云巨头（主要是 AWS）利用其知识产权大发其财，而市场最终迎来新的分支？还是说有第三条出路？

　　Asay 等一些人呼吁重新考虑许可，甚至可能重新考虑共享源代码（shared source）。虽然没有唯一的灵丹妙药，但是大获成功的 Red Hat 却历来是开源界的典范。Red Hat 保护其知识产权的方法是制定了这种策略：保持源代码开源，但是对二进制文件却牢牢控制。

　　Cloudera 照搬了 Red Hat 的方法，与 Hortonworks 合并后采用了该方法。以 Cloudera 为例，许多开源项目仍然是开源的，但是 Cloudera 将它们打包成软件产品（比如共享数据体验即 SDX）的方式却是专有的。自从走这条路以来，Cloudera 已经连续六个季度实现增长，并且在一个被许多人认为奄奄一息的市场实现盈利。Red Hat 和 Cloudera 的策略证明了这点：无论软件是不是开源，重要的依然是产品（或云服务）。