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的策略证明了这点：无论软件是不是开源，重要的依然是产品（或云服务）。
作者Tony Baer是IT外媒ZDnet的特约撰稿人（云头条编译）
猜你喜欢: