外部人员以内部视角观察 AWS 的开放源

随着 AWS 持续加强投身于各种开放源社区，我们很荣幸有机会与众多才华横溢的开发人员开展合作。Colin Percival 博士即是其中一名杰出的贡献者，他长期从事 FreeBSD 开发工作，而可能最为人所熟知的就是他在 FreeBSD 更新和 Portsnap 方面的突出表现。Colin 还是 Tarsnap 的创办人，该公司将自己包装为“面向偏执狂的在线备份”。

不过，在 AWS 客户当中，Colin 更出名的举动可能是，他在过去的十年里一手创建并维持着 FreeBSD AMI 的运转。在很大程度上归功于此，他一直被视为 AWS 社区的精英。

Colin 说道，在那段时间里，自己与 AWS 的开放源合作从分散的 AWS 员工合作过渡到协调的公司支持。虽说“在 AWS 的每一天都是新的开始”，包括我们的开放源工作，不过，Colin 的观点在某种程度上见证了 AWS 对开放源社区的参与在过去十年间的发展历程。用他的话说，AWS 采用开放源“对我来说更像一个循序渐进的过程，从众多 AWS 客户希望使用 FreeBSD，Amazon 在内部使用 FreeBSD，到 Amazon逐渐意识到开放源软件的重要性”。

AWS 始终都是运行全球最出色开放源软件的绝佳平台。即便如此，我们对如何为最佳客户提供服务的理解也悄然发生着变化，至少对于 Colin 来说绝对是这样。在 AWS，最佳客户不一定是最大的客户。从长远来看，我们的最佳客户应该能够帮助 AWS 改善我们的产品，毫无疑问，Colin 做到了。为了更清楚地阐述这一点，我们有必要回顾一下 Colin 和 AWS 的合作经历，并走到幕后，了解 AWS 服务团队如何看待他的请求。

在陌生的 AWS 探索的 FreeBSD 局外人

Colin 对于 FreeBSD 的热情可以追溯到 15 年甚至更久之前。他认为，“FreeBSD 是对[有] Sane Defaults 的 UNIX 情有独钟的用户量身定制的 UNIX 系统，它在最大合理程度上压缩基础系统…，并且内置有大量便利的工具。” 但 FreeBSD 唯独缺了它理应拥有的市场占有率。

当 AWS 在 2006 年首次推出时，Colin 几乎立即就开始使用。回忆起那个时候，他同时需要存储和计算以便 Tarsnap 运行。他认为：“当时，S3 + EC2 的组合和其他竞争对手提供的任何产品或服务都不一样。”他还希望 FreeBSD 能够兼容 EC2，因为 FreeBSD 已能在 Xen 中运行。“我以为在 EC2 中运行 FreeBSD 相对会更简单些”，他补充说。（剧透警告：其实并非如此。）

但重要的是，他可以尝试。制作 EC2 映像的“自助式”特点，结合其构建和运行自身内核的功能，在早期就让 Amazon EC2 的特性脱颖而出，帮助 Colin 这样的开发人员可以“自力更生，丰衣足食”。 有充分证据说明，这也是开发人员青睐 Amazon EC2 的原因之一：它被设计成能够处理尽可能多的用例，并在可行的情况下尽量减少限制。 就在这样的背景条件下，Colin 持续地钻研 FreeBSD AMI。

与此同时，AWS 背后的情形也在发生着改变。我们在 2010 年 7 月发布了 PV-GRUB 映像，因为我们希望使 Amazon EC2 的功能变得更全面。在这以前，只有一小部分的合作伙伴可以上传 Linux 内核映像，以便在 AMI 中使用。正如 AWS 的 Jeff Barr 在 2010 年所呼吁的那样，我们知道 PV-GRUB 让精通开放源的开发人员可以启动其他操作系统—“您可以（如果您足够熟练）利用此工具启动我们不直接支持的操作系统（如 FreeBSD）”。

PV-GRUB 对于其他操作系统非常有用，但却不能为 Colin 带来好处，他说道。“针对 FreeBSD 本身，它既非充分条件（还有其他问题），也不是必要条件（作为内核映像发布者，我已经就如何加入白名单与相关人员展开过对话）。” 在这一点上，Percival 强调虽然 AWS 没在其工作时给予他正式的支持，但在幕后，有不少 AWS 员工向他伸出了援手：

FreeBSD 习惯于：“如果你希望它成功，就得想办法让它成功。”在早期，Amazon 管理团队并没有给我我所定义的“支持”；但 Amazon 工程师却始终乐于为我提供帮助。我可能和 Amazon 内部的超过 50 名工程师进行过电子邮件交流，讨论了包括即将发布的功能、AWS 服务中的错误、AWS 功能的内部文档、FreeBSD 中的错误，以及 FreeBSD 补丁等在内的各种话题。

每名 AWS 员工为 Colin 提供的特别支持彰显了 AWS 所秉持更为中心的行事方式：客户至上。就这样，正如 AWS 的优秀工程师 Matt Wilson 提到我时所说，“我们知道，开放源开发人员是全世界最棒的客户群体之一。他们富有合作精神，容易沟通，而且出奇地聪明。他们还有非常高的质量标准和‘品位’”。 Colin 所谓的“个别工程师[站]出来帮助我”，对于 AWS 来说却是我们为最佳客户提供服务的方式。

Colin，作为一名“出奇聪明”的开发人员，也帮助我们打造更完美的 EC2 服务。随着时间的发展，他也注意到 AWS 的开放源支持也在不断地进化：

在 AWS 的早期那些年，我依赖个别工程师从繁忙工作中抽出点时间来帮助我解决 FreeBSD 问题；那时候完全没有明确的管理层支持。到了 2016 年，这种情况发生了彻底转变，我不仅可以得到关于新的弹性网络适配器硬件的提前通知，Amazon 还会给我提供 FreeBSD 驱动程序。很多硬件公司根本不会给我提供任何东西，还有些硬件公司会对我说“这是 Linux 驱动程序；你可以随便用”，这就是他们所谓对 FreeBSD 的“支持”。 提供可用的驱动程序，从而在最大程度上减轻 FreeBSD 团队的工作负担，这很明显地标示着 Amazon 意识到反馈社区的重要性。

不过，这样的变化并不是突然发生的：“对我来说，它更像一个循序渐进的过程，从众多 AWS 客户希望使用 FreeBSD，Amazon 在内部使用 FreeBSD，到 Amazon逐渐意识到开放源软件的重要性。”

虽然 Colin 无从得知他的 AMI 被多么广泛地使用（唯一的线索来自那些“给我发电子邮件的用户，以及为我的 FreeBSD/EC2 Patreon 提供赞助的用户”），不过，还是存在一些蛛丝马迹证明不少大型组织都在使用 FreeBSD。他表示：“有些大公司基于 FreeBSD 构建设备，而且在 EC2 内提供产品或服务。” 不过，他补充说：“我没有与此有关的任何内部消息，但我假定他们在其虚拟化设备和物理设备中都使用了 FreeBSD。”

是什么让我们开始关注开放源，以及 Colin 是否对这些公司可能“利用”他所贡献的代码感到不快？

开放源是什么样子的？

Colin 不断地说，虽然没有公司（或人员）在参与开放源社区互动时是尽善尽美的，但在他看来，AWS 在过去与他合作的十多年里有了长足的进步。即便如此，他还是认为，我们还可以提供更多帮助，例如，推出某种机制来负担 Amazon EC2 AMI 公共映像发布者的存储成本。

同时，他表示有太多人对开放源的运行原理存在误解：

我永远无法理解为什么会有人发布开放源代码，然后抱怨它被如何使用，随意使用开放源代码的自由难道不就是开放源世界最基本的自由吗？当我看到他们拆分项目，更改许可证，就因为他们不认同别人如何使用它，我能想到的就是，这些人从一开始就没弄明白开放源软件的意义是什么。

而且，他继续说道，很少有任何一家特定的公司只会拿而不会给：

我们发现在 FreeBSD 中，使用 FreeBSD 的公司几乎全部都会在最后回馈我们的社区，不是他们被迫这么做，而是因为如果他们的非核心功能一直处在上游，就能减轻他们自己的工程负担。我敢肯定，未事先宣布就发送到我的收件箱中的很多补丁都属于这样的情况：“工程师在构建产品时遇到问题，而他们不想在接下来的十年里一直通过本地补丁来解决这些问题。”

人们从开放源受益，然后以富有重要意义的方式回馈开放源社区，这样的看法非常体贴。正如 Colin 所说：“每家公司（每个个人）都要自行决定他们对维护工作的关心程度，推动自己所使用的代码的发展方向，保留专利的知识产权，等等。” 而对于 AWS 来说，我们已经逐步加大力度，帮助减轻他在为 Amazon EC2 构建和维护 FreeBSD AMI 过程中的负担，就像我们也从他和其他开放源开发人员那里学到了如何为他们，以及为下游客户优化我们的服务。

更新（太平洋标准时间 2019 年 11 月 8 日周五 3:12）：本文经过更新以反映 Colin 的反馈（见此处和此处）。很抱歉在本应关注 Colin 观点的文章中过度强调 AWS 的想法。

如果您希望帮助支持 Colin Percival 在 FreeBSD AMI 上所付出的努力，请在此处访问他的 Patreon 网站。