数年前，在科技网站ZDnet的一篇文章中，作者提出了一个问题：开源是否增长成为企业软件默认的全新业务模式。虽然仅过去了几年时间，但现在回头看来，这个问题似乎有点奇怪，因为Redis、MongoDB与Confluent等公司正在蓬勃发展，没有人再怀疑开源的价值。
但是，如今的开源中具有诸多的争议，比如MariaDB CEO Michael Howard就批评这些云计算巨头会通过“露天开采”来掠夺各种开源资源。无风不起浪，最近一波争议起于上周，引爆点便是AWS宣布它推出了增强的Elasticsearch开源发行版，正如ZDnet 记者 Steven J. Vaughan-Nichols 报道的那样，在竞争激烈的文字大战中，Elastic和亚马逊都试图占据舆论制高点。
对于开源如何改变了软件领域，我们不必在此进行赘述。比如纽约，虽然凭借着华尔街，“大苹果”一直被视为是一座“科技之城”，但在开源出现之前，由于技术的被封锁，各家公司都必须去独立开发包括从高性能的信息传递到计算网格与数据库在内的IT基础设施及软件，没有人愿意与别人进行互动。
而后，华尔街公司们意识到必须要将开源放在首位，因为它们不想重新再去自我创建各种独立的系统，尤其是在核心基础设施软件或机器学习算法方面，它们独有的知识产权其实具有更高的价值。它们不再会失去那些使用开源软件的优秀人才，因为它们希望自己的技术能够更加便于移植。至此，华尔街公司不再介意员工公开讨论他们的开源见解，甚至鼓励他们去创造自己的开源项目：几乎每晚该城市中都会举办各类聚会，开源从业者们会在那里分享他们的创新成果。
但是，开源公司会发现：他们的项目越受欢迎，自己就面临着更多的“成长烦恼”，就像MongoDB不会希望有人分走它获得的3亿美元投资。对于这些开源公司而言，别人的模仿可能是一种真正地学习与致敬，但这也是对它们未来收益的极大威胁。没有哪个开源玩家希望自己成为别人的垫脚石或牺牲品。
这就是像MongoDB和Redis这样的公司感到威胁的原因，因为它们的项目吸引了大量的追随者;而Cloudera这样的公司则完全没有这种感觉，因为它们的项目吸引力较小。因此Cloudera会认为AWS和Azure更像是合作伙伴，而不是吸血鬼。
Adobe开发者生态主管Matt Asay经常对近期热点事件进行评论，在他最近的帖子中，他表示，大多数下载或使用开源的开发者都不会花时间搞乱代码或者为它做贡献，因为他们已经有了日常工作。因此，许可证的变化 ，特别是那些禁止运行第三方SaaS服务的许可证 ， 对他们来说无关紧要。
在当前的争夺中，亚马逊开辟了一条新的战线，它与Netflix和Expedia等客户共同为Elasticsearch项目开发了一个新的开放发行版，这将为这个开源项目贡献所有的资源。它这样做是基于它的论点，即Elastic正在通过引入开放源代码和专有代码来混淆视听。Elastic则坚称，它与亚马逊存在分歧，而不是与所有云提供商都存在分歧。
从一开始，Elastics的商业模式就基于开源和专有软件的结合。其核心的产品，包括Elasticsearch、Kibana、Logstash和Beats都是基于Apache 2.0开源许可的。争论的焦点是以前称之为X-Pack的Elastic Stack Features(扩展或插件)，这些功能负责处理安全、警报、监视、报告、图形分析和机器学习。在过去，它们会被被视为是封闭的专有软件，最初的目的旨在使程序集成为一个经典的开放核心产品，其中一些功能可以免费获得，而其他功能只能通过付费订阅获得。而由于这些功能都是专有的，因此催生出了一个第三方生态系统来替代这些功能，这并不奇怪。
去年Elastic做出了一些改变，因为它发现开放核心(Open Core)模式存在分歧。一年前，Elastic CEO Shay Banon在一篇博客文章中表示，如果将开放时间延长一倍，那么明确有偿与免费的分界线将会破坏社区。他指出连接的断开不仅会出现在在功能广度上，也在测试中带来不连贯性。他有一个观点 - 如果这些特征交织在一起，那么分割的代码就像分开的城市一样难以想象。
挑战在于，通往混乱的道路是由良好的，或者更恰当地说，是高度理想主义的意图铺成的。Elastic的做法令人钦佩，它将Elastic特有的源代码公开并提供下载，这限制了其他第三方将其作为商业SaaS服务提供的可能性。但是，正如AWS所主张的那样，可下载文件夹中的文件混合了Apache 2.0和Elastic的许可代码，这会让事情变得很复杂。
Elastic坚称Elastic许可证和Apache许可证代码位于不同的文件夹中，并且差异非常明显。但在我们看来，差异是非常微妙的。而且，即使Elastic在Apache和Elastic授权代码之间建立了一堵长城以制造明显差异，也不能保证亚马逊会止步不前。
在此期间，MongoDB和Confluent也加紧实施自己的计划。由于双方无法达成一致意见，MongoDB退出了开源倡议，之后开始推进SSPL，它涵盖了4.0平台的所有方面。 而Confluent正在推进Confluent社区的许可，其中包括触及(但不包括)Apache Kafka的组件：KSQL，Confluent连接器，REST代理，控制中心和其他几个部分。
此外，Redis去年夏天发布了Redis Modules中的Commons Clause(不是数据库本身)，后来又在一个名为Redis Source Available License(RSAL)的新条款下对其放宽了限制。这里的好消息是，Redis直言不讳：它并没有假装宣称RSAL是一个开源许可证。
这些都是开源玩家们面临的挑战。与传统的专有软件相比，开源软件或项目拓宽了人们的目标市场的宽度，并为构建关键的大众社区提供了***机会，并使得用户得以使用它建立安装基础。但是这把双刃剑的另一面就是这些项目太受欢迎了。开源提供商面临的永恒挑战是如何保持竞争优势。如果他们有一个更快的新版本发布通道，情况可能尚不糟糕，但但一旦竞争对手赶上来，那就是另一回事了。例如，过去AWS在支持Hadoop版本方面常常滞后，但之后，在***的稳定Apache版本发布30后，AWS就会采取行动。这时，时间不再会是开源供应商的朋友。
另一个风险是分叉(forking)，借助它，厂商要划分出能够给予自身项目支持的社区。对于那些非社区控制的开源项目特别是供应商来说，这是一个很大的挑战，MongoDB就是***的例子。它会在***版本项目的基础上构建新功能，而Amazon和Percona等第三方会在不受SSPL约束的早期版本的基础上开发新功能。代码将会被分叉，问题是这是否会导致社区分裂。毫无疑问，Elastic的Banon所关心的正是如何将使用免费开源版本的用户与使用付费企业版本的用户隔离开来。
开源公司需要可用于防御的IP。不过，到目前为止，Red Hat(很快将成为IBM的一部分)仍然是一个例外，即纯开源公司的产品基于社区主导的项目可以获得成功。与此同时，Cloudera也在寻求突破，成为另一个特例。
那么，对于生态系统的其他部分，新的变体开源许可证是解决方案吗? 这里危险之处在于，客户一方的法律和合同履行人员可能会对许可证感到厌倦，因此可能会对许可证产生抵触。
或许对于开源厂商来说，要做的就是不要做任何事情来使用户对它们产生怀疑，并坚持使用著名的开源许可证。之后围绕它，开发独特的内容，为开源项目增加价值。同时保持增值组件的抽象也需要是独特的，并针对开源内容进行了优化。继续发布有限制的专有代码，但不要假装它是开源的。当然这不会是一件容易的事，毕竟开放核心模型太老了，也许它会再次进行转变与更新。
