在多年免费搭乘开源项目便车后，亚马逊（AWS）与开源的关系正在悄悄改变。尽管如《纽约时报》的 Daisuke Wakabayashi 所报道的那样，抨击AWS“剥夺”开源并非正确，但这种“剥夺”的指控多少是有迹可循的。

为何会这样说呢？在 Cloud Native Computing Foundation、Apache Software Foundation 或几乎任何地方浏览顶级开源项目都会发现：Google 常位居开源榜首，紧随其后的是微软，前列很少出现 AWS 的身影。

如今，局面似乎在扭转。AWS 服务产品团队意识到，要实现“客户至上”这一条 AWS 最重要的领导原则（包括其他原则如所有权、交付结果等），他们需要致力于开源。

过去 vs 现在

在过去，基于 AWS 的第二条领导原则， AWS 服务团队误认为，要想真正做到关心客户必须让他们拥有全方面的体验。当时，一些 AWS 服务团队并不愿意做出贡献，担心可能会透露过多关于其系统运行方式的信息，或者会通过修复错误或添加功能为竞争对手提供差异化的优势，影响到亚马逊的服务。因此，这导致整个过程中，AWS 背负了很多技术债务，很难提供满足客户需求的服务，例如：运行 Apache Spark、MySQL 或其他开源项目的简单方法。

如今，AWS 正加速拥抱开源。以 PostgreSQL 为例，曾经 AWS 靠 PostgreSQL 赚了很多钱，但基本不回报，现在 PostgreSQL 项目的代码递交的页面充斥着 AWS 员工，其中部分人员是从 PostgreSQL 代码贡献者转变成受雇于 AWS 专门开发 PostgreSQL 的企业开发者。今天， AWS 是 PostgreSQL 项目排名第三的企业贡献者。

开源之路任重而道远

虽然 AWS 靠 Kubernetes 服务赚了很多钱，但在过去一年开源贡献中，AWS 却只能勉强进入前十。类似地，AWS 托管的其他开源项目（如 OpenTelemetry）或客户所依赖的项目（如 Knative，AWS 排名第 12）也是如此。即便是 AWS Elastic MapReduce 的基础 Apache Hadoop 项目，AWS 也只有一个提交者。

如今，项目提交者的数量发生了很大变化，从几年前的零开始转变为一个或多个。

AWS 一直擅长将开源项目作为服务提供给其客户。大多数时候，客户想要一个有效的解决方案，但如果想要其以满足用户需求的方式“工作”（即开源项目的原版，而不是某个分支或“高级”版本），AWS 需要更深入地涉足项目的开源。

总而言之，这些改变对 AWS、对其客户包括对开源都是有益的。鉴于 AWS 的规模，很难重点强调出 AWS 的运行方式有多不同。在规模上，AWS 已经学会了如何解决问题。如果能够把更多专业知识渗透到开源项目中，每个人都将受益，这将为 AWS 销售其服务创造更大的市场。