企业开放源代码的基础上出现了裂缝

我在整个职业生涯中都在开源领域工作过1.要说我担心最近发生的事件对开源生态系统的影响是轻描淡写。

人们可能理所当然地反驳这些陈述，但这些陈述比您想象的要复杂。杀死一个项目并不意味着该项目会在一夜之间消失，但​​是到目前为止，发生在企业开放源代码中的两家非常大的公司空间已经显示出开源软件货币化的弱点。

多年以来，行业内的每个人都将Red Hat视为“如何围绕开放源代码建立公司的光辉典范”。

在过去的十年中，开源的Elasticsearch，Logstash和Kibana日志记录生态系统一落千丈，成为开源云堆栈中的标准。

但是Red Hat在2019年被IBM收购，并在接管社区CentOS项目（于2014年发生，远在收购之前发生）之后，他们基本上结束了以前被人们知道和喜爱的长达十年的支持周期，以绝望的态度。

我也有此帖子的视频版本（以防您视觉上偏斜）：

当Red Hat于2014年接管CentOS项目时，反应是喜忧参半，但大多是积极的。 CentOS维护人员有时很难跟上Red Hat Enterprise Linux（RHEL）的上游变更，而主要版本（如版本7和8）由于需要进行架构更改而具有挑战性。

因此，红帽愿意加入并支持CentOS通常是一件好事，一时间。

上个月，Red Hat遭受了重创：开始采用CentOS 8并希望在2020年代末之前支持稳定版本的CentOS用户将仅获得一年的支持。

他们需要切换到“ CentOS Stream”，这是一种“稳定的beta”。版本的RHEL比Fedora稳定，但不如Enterprise Linux稳定。否则他们将不得不完全放弃CentOS。

这激怒了很多人，诚然，大多数人一直在免费版本的CentOS上构建，多年来却没有为该项目做出任何贡献（但这是整个免费软件的一部分） ;事情-会有freeloader）。

但这也激怒了许多像我这样的人，他们除了在多个发行版上测试其他FOSS软件外，并没有真正使用CentOS，而是将CentOS用作Red Hat Enterprise Linux的1：1代理。

红帽以对我这样的开发人员的限制较少的许可证的形式扩展了一个小的橄榄分支，但是仍然不清楚如果我想在容器中进行CI测试之类的事情我必须做多少工作无需管理订阅和访问密钥。这些事情可能导致我在许多自己的开源项目中取消了对Red Hat Linux的所有支持。

无论如何，整个崩溃的细微之处在于，但这主要是因为尽管通过许可增加收入可能不是Red Hat采取此举的唯一动机，但这无疑是一个主要因素。科学Linux和CentOS的衰落使那些围绕Red Hat兼容性建立自己的职业或公司而又无需支付订阅费的人就感到紧张。

许多人正在等待，看看即将发布的Rocky Linux（旨在成为CentOS的完美替代品）是否会以与CentOS相同的稳定性来发布。

现在转到Elastic和Elasticsearch：再次发生了太多的事情，我可能无法在一篇文章中介绍所有内容，但是基本故事是这样的：

Elasticsearch是在Apache License版本2.0下创建的。它已成长为必不可少的开源云基础架构组件，并且我发现它已在所有地方使用。

鉴于其受欢迎程度以及部署和维护Elasticsearch集群的复杂性，Amazon Web Services（或AWS）决定打包自己的托管Elasticsearch产品。

好吧，由开源项目掌舵的风险投资支持的公司Elastic并不是那样，因为他们通过自己的发展获利并向投资者展示增长的方式是对自己的收费托管Elasticsearch产品。

因此，AWS直接与Elastic竞争，但没有对开源项目承担相同的责任，也没有像Elastic那样投入巨资。

这就造成了许多流行的开源软件包所固有的问题—当像Google，AWS或Microsoft这样的云计算巨头决定将您的免费软件包装在托管产品中并从中获利时，您将如何处理？

好吧，Elastic通过切换到新许可证来处理它，FOSS或自由和开源软件社区中的许多人都认为这不是真正的开源。

SSPL或服务器端公共许可证被吹捧为GPL版本3衍生许可证。它与之类似，但是有一个主要限制，说明您不能在不释放用于构建该服务的所有代码的情况下构建托管服务。

但是Fedora社区公开表示，“将SSPL视为免费”。或“开放源代码”导致在FOSS生态系统中的所有其他许可证上蒙上阴影。＆＃34;

开放源代码计划（Open Source Initiative）则将其称为“ fauxpen”。在他们的文章《 SSPL不是开放源代码许可证》中。他们说这是一种简单明了的欺骗，声称该软件具有开放源代码的所有好处和承诺，而没有开放源代码的话。

那么亚马逊做了什么反应呢？他们分叉了Elasticsearch。自从他们分叉了最后一个真正的开源版本以来，他们的权利范围内就有些东西了。

有趣的是，现在这两个独立项目周围的社区是如何分化的。

因此，就像我说的那样，此职位不能使情况的细微差别伸张正义。而且它不像[IBM | Red Hat]不好那样简单，或者“水ches不适合开放源代码”或者“巨大的AWS正在分叉”弹性的小项目。还有很多，我鼓励您阅读更多有关该新闻的信息。

首先，我们如何确保开发开源软件的开发人员以公正的方式获得报酬？又如何让大型公司和数十亿美元的风投支持的初创公司承担起免费和开放源代码软件的追捧而又不按比例退还的责任？

其次，我该如何减轻使用和喜欢更改许可证并引起头痛的软件和服务？一种方法是对许可进行更严格的限制，只选择最初创建的copyleft许可，其目的是为个人提供比公司更多的保护。

第三，如果我想以开源为生或建立公司，我有什么选择？我们曾经都将Red Hat视为开放源代码的典范，但似乎该公司-尽管他们在开放源代码社区中已经做过并且仍在做着所有伟大的事情-却已经开始通过源代码进行销售。

对企业友好的开源变得越多，对大型巨型公司的控制权就越强。谁该怪？好吧，可悲的是，经过深入的反省之后，我不得不承认我可能是问题的一部分！

无论如何，这些事件导致许多开发人员再次猜测他们对开放源代码许可怪胎的解雇。他们总是大喊选择正确许可证的重要性。但是也许他们正在做某事。也许盲目地采用宽松的开放源代码许可来邀请更多的公司所有权不是正确的答案。

1开源的定义我在这句话中使用的宽松程度包括FOSS和OSS许可的软件。我赖以生存的项目大约有一半是GPLv2或v3，另一半是Apache或MIT。您可以深入探究与学徒争论的兔子洞，以了解术语“开源”的含义。