AWS高管：“我们对开源的理解正在改变”

从日前召开的re:Invent发布会上可以看到，云服务巨头AWS对于供应商驱动的开源项目仍持谨慎态度，主张对所有开源依赖项进行业务健康检查。这也可以理解，毕竟极具影响力的CentOS停止开发之后，AWS对于Amazon Linux的计划也被意外打乱。

David Nalley是AWS开源战略与营销总监兼Apache软件基金会总裁。“我的职责范围几乎涵盖AWS的所有开源项目。”

与EC2（Elastic Compute Cloud）虚拟机的其他发行版相比，Amazon Linux用起来到底有什么优势？Nalley解释道，“长期以来，Ubuntu都是人们首选的主要发行版。我们也与许多不同发行版保持合作，以确保其运行良好。”

FreeBSD也是一个选项。“我跟FreeBSD发布经理直接交流，讨论为FreeBSD开发AMI（Amazon Machine Images）。我有种直觉，Amazon Linux应该会得到更好的支持，毕竟它的开发团队就是亚马逊的内部员工。”

Amazon Linux 2023（最终也在AWS之外发布）面对的一大障碍，就是无法支持EPEL（Extra Packages for Enterprise Linux），但其前代版本Amazon Linux 2却能够支持。考虑到EPEL软件包的重要性，为什么会有此变化？

Nalley解释道，“不同之处，在于Amazon Linux之前基于CentOS。CentOS拥有一个充满活力的社区，贡献者们会打包大量软件。但在Amazon Linux的最新版本中，我们通过重构将Fedora设为新的基础。”

而原因很简单，CentOS已经停止开发。“这就很尴尬了。其实打包工作本身并不困难，对大多数贡献者来说，只要能获得源rpm，就能轻松把它构建到别的发行版当中。我自己就曾经帮Fedora做打包工作。”虽然偶尔也会出现问题，但“对于绝大多数软件包来说，保证源rpm还在更新就足够了。”

另一个障碍在于，如果需要加装安全补丁，则必须重复整个过程，而且发行方往往不会解释到底为什么需要更新软件包。“没错，维护负担需要由下游承担。”

为什么不能让Amazon Linux从一种发行版就地升级成另一种？Nalley表示，“我们一直致力于打造一套稳定的平台，而就地升级在本质上就不够稳定。要想升级glibc或者llvm的底层版本、同时在各个版本之间保持稳定和安全，其实是非常困难的。”

但这个问题影响的主要是那些小体量客户。“掌握完善架构的客户已经在使用基础设施即代码来定义这些实例的外观，因此可以轻松启动新实例，转移原本部署在旧实例上的软件，检查是否能正常运行，最后把实际工作负载迁移过来。就这么简单。”

那么，Linux 2023为什么花了这么长时间才发布？毕竟Amazon Linux 2已经相当陈旧、严重过时，而继任者却迟迟没有出现。Nalley称“这当然是有理由的。”

 “我们不想发布还没准备好的东西。我们正在对底层发行版进行根本性的重新调整。Amazon Linux 2维持着良好的安全补丁和支持，这对较旧的产品来说无疑是个挑战。而且受架构问题影响，Linux 2023的发布时间晚于预期，我们曾先后多次宣布推迟。”

但众所周知，Fedora是个快速发展的发行版，而Amazon Linux则向来以稳健著称。这会让双方的合作关系发生冲突吗？Nalley提到“肯定会有影响，跟我们以往使用CentOS时的情况不同。”

“但我们喜爱Fedora的原因之一，就是它始终在以极快的速度推动创新。我们认为Fedora为我们提供了一个更好的平台，而且我们会将支持周期延长到远超Fedora官方支持的水平。Fedora的发展速度确实很快，当初新发布的CentOS版本都跟不上它的节奏。”

AWS与开源

考虑到催生出OpenSearch的Elastic等项目，AWS与开源社区之间的关系正在走向何方？

Nalley认为，“每一家使用开源软件的公司所获得的收益，都远远超出他们所付出的资源。这已经是个普遍真理了。”

每一家使用开源软件的公司所获得的收益，都远远超出他们所付出的资源。

“我确实认为AWS对于开源的理解和双边关系正在发生变化，而其中一些变化源自我们对开源发展的深刻理解。以往，大多数开源项目都完全由社区主导，包括Apache Web服务器以及Linux内核，人们出于共同的使命感而走到了一起。但如今许多创新产品的出现，正逐渐转向由厂商控制的开源软件项目。对于这两种形式，我们当然不能以同样的方式看待，也不能指望以同样的方式享受这两类成果并期望获得类似的效果。”

“我们对开源的理解已经开始转变，并意识到一切依赖关系都必须匹配相应的风险衡量与评估。我们要如何确保所依赖的开源项目还能继续存在、长期发展？Apache Web服务器或者Apache Tomcat当然值得托付，但其他厂商主导的软件包则可能各有不同的考量因素。问题的实质，在于社区的多样性与健康状态。我们正在积极研究这个问题，希望建立起更加稳定可靠的依赖关系。”

AWS本身也掌握着不少开源项目，比如SDK，这些项目主要由内部工程师推动、而非由社区所主导。Nalley解释称，“当我们发布软件时，AWS会出于多种考量而使用开源成果。”

 “其中之一在于，从知识产权（IP）的角度来看，开源许可证确实更容易理解。如果采用了基于Apache许可证或者MIT许可证的某些成果，公司的律师会觉得比较容易把控，而且可以预先批准引入这些许可证。我们已经在开源许可之下发布了很多项目，也并不指望能由此建立起相应的社区。”

但也有一些例外情况，比如现在已经被贡献给云原生计算基金会（CNCF）的AWS Karpenter项目。Nalley提到，“微软就曾表示他们很喜欢Karpenter。”

“但微软喜欢Karpenter的前提，就是该项目不能由亚马逊一手控制。所以我们开展了内部对话，讨论如何把Karpenter捐赠给CNCF会怎么样。现在它已经是个孵化项目，并且正在培育自己的社区。”

David Nalley，AWS开源战略总监兼Apache软件基金会主席

根据Nalley的介绍，另一个被他人以“意外但却令人满意的方式”接纳的AWS开源项目是Bottlerocket，一款轻量级容器Linux发行版。“我们之所以开发这个项目，是为了在其之上构建Lambda。但也有一些客户正利用它尝试一些我们从未想到过的绝妙点子。”

面对众多开源项目那糟糕的商业模式，AWS是否会感到担忧？Nalley叹了口气，强调“其实每个服务团队在审视自己的依赖项目时，都会考虑这个问题。”

“在AWS内部，我们建立了明确的战略开源项目概念。我们要求服务团队内的部门负责人每季度上报这些项目的运行状况。这样做，当然是为了确保项目所有者仍然关注自己的成果。我们不希望看到某些特别重要的技术要由住在地下室里、领着低保救济的人来维护，这不符合我们客户的最佳利益。”

AWS在消费公共开源项目时，要如何防范代码篡改风险？Nalley表示“我们的创作者体验团队维护着一套内部软件包repo”，同时也会审查软件来源和许可证等内容。

他最后总结道，“这样我们就能在出现安全问题迅速响应，跟踪所有使用到该软件的场景。”