开源成长的痛苦：Open Core会是答案吗？

上周，AWS公布了Open Distro for Elasticsearch之后，引发了口水战，这是开源公司日益增长的痛苦的最新例证。虽然过去一年中，新的开源许可证数量激增，但这个陈旧的开放核心模型真的能证明保持开源是一个可行的更好选择吗？

几年前，在我们一篇文章中，我们提出了一个问题：开源是否能够成为企业软件领域新的默认商业模式？现在仅仅过去了几年，但是回顾过去，考虑到Redis、MongoDB、Confluent最近的行动，这个问题现在已经看起来有点古怪了，现在Elastic担心亚马逊这样的云巨头，MariaDB的首席执行官Michael Howard表示，要“条带式”开源。

最新一轮的截击发生在上周。正如Steven J. Vaughan-Nichols报道的那样，在激烈的口水战中，Elastic和亚马逊都试图占领高地。

这真是无风不起浪。

很少有人质疑开源是如何改变软件环境的。在我们所在的纽约地区，我们已经看到了开源技术是如何开辟技术“疆土”的。感谢华尔街，纽约一直是一个技术城市，但是在开放源代码之前，很多技术都是锁定的，每一家企业都不得不自己为IT软件基础架构开发基础支柱，从高性能消息传递到计算网格和数据库，都是如此，因为现成的软件无法被破解。没有人和别人讨论。

华尔街公司越来越多地寻求开源，因为他们不想重新发明轮子，尤其是核心基础设施软件或机器学习算法；他们独特的知识产权在价值链上的地位要高得多。而且他们不想失去那些喜欢开源的优秀人才，因为他们希望让自己的技能变得更加便携。而华尔街的公司不介意他们的员工是否出去公开谈论他们的见解，甚至创立他们自己的开源项目；城里几乎没有哪个晚上没有聚会，从业者在这些聚会上分享他们的创新。

开源公司今天所感受到的成长痛苦与他们的开源项目受欢迎的程度直接相关。MongoDB不希望看到其他人从它所赚取的3亿美元中获利。正如我们上周所说，模仿可能是最真诚的奉承形式，但对于开源公司而言，它也是对未来收益的威胁。开源参与者希望避免成为他们自己成功的牺牲品。

这就是为什么像MongoDB和Redis这样的公司，其项目吸引了大量的粉丝社区，感到受到威胁，而像Cloudera这样的项目吸引力较小的公司却没有的原因。这也就是为什么Cloudera将AWS和Azure视为竞合对手而不是吸血鬼的原因。

Matt Asay经常评论正在展开的传奇故事。在他最近的帖子中，他认为大多数下载或使用开源的开发人员都不会花时间搞乱代码或者为它做贡献，因为他们还有日常工作要做。因此，许可证的变化——特别是禁止第三方运行SaaS服务——对他们来说无关紧要。这是非常有道理的。

在当前的争吵中，亚马逊通过与Netflix和Expedia等客户共同推出新的Open Distro for Elasticsearch项目，开辟了一条新战线，这些客户将把所有这些内容回馈给这个开源项目。它这样做的理由是Elastic正在搅浑水，模糊开放源代码和专有代码的界限。而Elastic则坚持表示自己反对的是亚马逊，而不是所有的云供应商。

从一开始，Elastics的商业模式的基础就是开源和专有软件的结合。核心Elastic堆栈包括Elasticsearch，Kibana、Logstash和Beats都采用了Apache 2.0开源许可。争论在于Elastic Stack Features（扩展或插件），以前被称为X-Pack，可以处理安全性、警报、监控、报告、图形分析和机器学习。它们以前被当作封闭式专有软件，这种做法最初使该组合成为经典的开放核心产品，其中一些功能是免费提供的，而另一些功能只能通过付费订阅获得。专有软件部分不开放代码供查看，我们相信这是他们留了一手的地方。而且，由于这些功能是专有的，毫不奇怪，它催生了第三方生态系统的替代品。

Elastic在去年发生了变化，因为它发现开放核心模型具有分裂性。Elastic首席执行官Shay Banon年前在一篇博客文章《Doubling Down on Open》中表示，付费和免费的分裂会破坏社区。他提到了各种分裂，不仅仅是在功能广度方面，还包括测试方面的不连续性。他有一个观点——如果这些功能交织在一起，那么将代码分开就像把城市一分为二一样难以想象。

但是，挑战在于通往混乱的道路是由良好的——更确切地说，是高度理想化的——意图铺就的。在令人钦佩的举动中，Elastic随后开放了Elastic Features的源代码并可供下载，但是限制了第三方将其用于商业SaaS服务。但正如AWS所说的那样，可下载文件夹中的文件最终包含了Apache 2.0和Elastic许可代码的混合体。让事情变得很混乱。Elastic表明存储库中的Elastic许可证和Apache许可证代码位于不同的文件夹中，而且差异非常明显。对我们来说，差异非常微妙。尽管如此，即使Elastic在Apache和Elastic许可代码之间建立了一个更大的长城，也无法保证阻止亚马逊前进。

在此期间，MongoDB和Confluent都在努力推进自己的计划。由于双方无法达成一致意见，MongoDB在退出Open Source Initiative之后正在推进SSPL。它涵盖了4.0平台的所有方面。Confluent正在推进Confluent Community License，其中包括触及（但不包括）Apache Kafka的组件：KSQL、Confluent Connectors、REST Proxy、Control Center和其他几个组件。

同时，Redis去年夏天为Redis Modules发布了Commons Clause（不是数据库本身），后来在一个名为Redis Source Available License（RSAL）的新条款下放松了一些限制。这里的好消息是，Redis实验室非常磊落：它并没有假装RSAL是一个开源许可证。

每一个参与者面临的挑战都是真实的。和传统专有软件相比，开源打开了市场，提供了打造重要大众社区的绝佳机会，并且有望通过它形成自己的安装基础。但是，对于你自己的利益来说，如果你的项目变得太受欢迎，这就成了一把双刃剑。开源提供商面临的经典挑战是如何保持竞争优势。如果你有一个更快的管道升级到新版本是一回事，但是如果你的竞争对手赶上了它就是另一回事了。例如，AWS过去常常会在让EMR支持最新的Hadoop版本方面动作迟缓，但是此后，它已经在最新的Apache稳定版本发布后的30天内就采取行动了。从这个角度看，时间已经不再是你的杀手锏。

另一个风险就是技术分叉，这就会分裂支持项目的社区。这是一个风险，特别是对于由供应商而非社区控制的开源项目来说更是如此，MongoDB就是一个最好的例子。MongoDB将在最新版本之外构建新功能，而亚马逊和Percona等第三方则开发出不受SSPL约束的早期版本。代码将分叉，问题是这是否最终会破坏社区。毫不奇怪，将社区分裂正是Elastic的Banon所关注的问题，他正在呼吁用户放弃使用付费企业版本而使用免费开源版本。

开源公司需要可防御的知识产权。到目前为止，Red Hat（即将成为IBM的一部分）仍然是规则的例外，即基于社区主导项目的、纯粹的开源公司可以成功。与此同时，Cloudera希望突破并成为下一个例外。对于生态系统的其他部分，新的开源变体许可证会是答案吗？危险在于客户方负责法律和合同合规的人员可能会对审核许可证感到压力。

也许是时候认真考虑这件事了。不要一边坚持使用著名的开源许可证，一边又让你的忠诚基础滋生怀疑。绕开它，开发独特的内容为开源项目增加价值。保持增值组件足够抽象，但也是独特的，并针对开源内容进行了优化。你可以继续向前，发布有限制的专有代码，但不要假装它是开源的。没有人说这很容易。开放核心模型太老了，也许它需要做点什么，以便再次焕发青春。