本文来自微信公众号“开源云中文社区”。
AWS、谷歌云平台（GCP）和微软Azure等云提供商长期以来一直与开源社区保持着友好的关系。
一方面，云提供商的平台即服务（PaaS）层成功地将大部分价值从软件维护者重定向到了他们自己身上。然而，大型科技公司也为开源生态系统做出了重大贡献。
一个值得关注的例子是Kubernetes项目，它起源于谷歌。其他例子包括领英的Apache Kafka、脸书的Presto以及爱彼迎的Apache Airflow和Superset。
云提供商和开源维护者之间的紧张关系即将发生巨大变化，我们需要关注目前正在发生的事情。
平台即服务模型
最明显的紧张来源于PaaS作为云提供商的主要收入模式的建立。在AWS的早期，其核心业务是计算和存储。
尽管如此，原始虚拟机和承载重要Web服务所需的完全分布式架构之间仍存在重大技术差距。随着时间的推移，AWS意识到它需要另一层来确保其用户的成功，主要围绕着数据库、队列和作业编排器等复杂软件的供应和生命周期管理。
云依靠开源来实现该软件的久经考验的实现，并利用其许可在之上创建了利润丰厚的业务线。这似乎赤裸裸地剥削了开源开发人员的努力，但不妨理解为什么会这样。
云PaaS解决了两个主要痛点：规模经营经济、服务的分发。
作为一名工程师，笔者可以立即看到规模经营经济的必要性。笔者亲眼目睹了操作这些系统的难度。它需要对工程基础和软件本身的特性有丰富的经验才能可靠地提供和维护它们。
大多数组织将没有内部专业知识，必须向拥有该专业知识的人支付费用。
理论上，像亚马逊或谷歌这样的组织并不是唯一可以提供这类服务的组织，事实证明，许多开源社区已经通过创建自己的PaaS产品将其产品商业化，比如ElasticSearch的Elastic、Kafka的Confluent、MongoDB等。这种商业模式为这些开源项目提供了至关重要的持续资本，也是它们取得成功的重要原因。
分发是云相对于任何其他软件来源的第二大竞争优势。大多数企业的严酷现实是，几乎所有的行动都受到严重的官僚主义限制，任何供应商或开源软件包都必须经过繁琐的审查才能开始使用。
云提供商的优势在于与地球上几乎每一家大型企业都建立了商业关系，因此通过一家公司试用新服务的摩擦要小几个数量级，从而创造了一台强大的销售机器。事实证明，这种竞争风险如此之大，以至于一些开源项目认为这是存在的，并完全改变了许可以应对威胁，尤其是Elastic和MongoDB。
强调这种商业模式的另一个有趣的副作用是代码库本身。AWS和ElasticSearch之间的争吵导致该项目出现分歧，AWS维护OpenSearch，Elastic维护对遗留ElasticSearch代码库的控制。
这种情况也发生在更深层次的层面上，AWS RDS等服务有效地为其Aurora服务重写了Postgres等主要关系数据库（这是数据库设计的一个重大进步），但没有为开源社区贡献这种创新。这是因为软件永远不会离开托管服务的围墙花园，但最终会忽略更广泛的开源生态系统。
云提供商向前迈出一步
当你分解这个问题时，云提供商和开源关系之间有两个主要问题在起作用。
首先，存在着在基础设施提供商和开源维护者之间找到更公平的价值分配的问题，这种分配不会过度补偿克服企业官僚效率低下的能力，并使软件生态系统更加自我维持。
在承认这一问题方面取得了进展，AWS再次领先，与Grafana建立了合作伙伴关系，以分发具有明确收入共享协议的软件。这是一场双赢；Grafana为其产品获得了适当的补偿，企业可以减少繁琐的手续，AWS在其目录中获得了另一项服务。
但是，这一切的根源还在于一个技术挑战：开源软件往往非常复杂，需要第三方基础设施提供商来提供良好的用户体验。如果情况不再如此，这个问题将发生重大变化。
组织不需要仔细分析他们将基础设施外包给谁，就可以利用标准的开源组件，从而获得分发优势，而不是破坏游戏规则。
开发人员可以将软件本身的价值货币化，而不是将其“管理”货币化。而且，用户不必为了依赖最好的开源生态系统而在数据租赁方面做出妥协。
现在有一个强大的工具生态系统，如Kubernetes和Terraform，可以几乎自动化分布式系统管理的所有题，但根本没有充分发挥它们的潜力。因此有一些公司打包主要的开源解决方案，如Airbyte、Airflow、Prefect、ElasticSearch、Kafka、PostHog、Grafana和Argo CD，使开发人员能够在Kubernetes之上使用DevOps最佳实践进行部署。这样的平台为工程师提供了他们在托管产品中获得的所有操作工具，以及经过验证的升级流，所有这些都部署在自己的云中，以实现最大的控制和安全性。
