包注册机构是否将开源软件扣为人质？

几天前，我收到了一封来自多克的电子邮件，内容是我已经知道即将发生的变化：‍。

对许多人来说，这并不令人意外。多年来，Docker Hub一直提供免费托管容器图像的服务，这些图像的大小通常从几兆字节到几千兆字节不等。因此，Docker工作流使用了大量带宽，而这些带宽是要花钱的。

我们OSS(开源软件)和开发者是否应该考虑我们托管软件的平台的商业和财务模式？在一个完美的世界里，我们不需要这样做--但在现实世界里，我们非常需要这样做。开放源码软件的维护者和他们使用的注册表之间的激励往往是不一致的。

Docker Hub、NPM和其他类似的注册机构被鼓励创建锁定，即使这会让他们的用户和客户的产品体验变得更糟。注册背后的营利性公司尤其如此，但我们在许多非营利性注册机构中看到了类似的问题。

另一方面，维护者受到激励，以最低的成本选择最适合他们需求的最佳产品，这取决于当更好的服务上市时是否能够更换供应商。

这种情况从根本上与当今的套餐管理生态系统不符，在这种生态系统中，为了实现稳定，不变性是至高无上的。原则上，我们会不惜一切代价避免破坏东西，因为OSS包是软件生态系统、互联网乃至整个社会的支柱。

您托管包和容器的注册表今天可能是免费的，但如果以后发生变化，就像Docker现在的情况一样，您和您的用户可能会被迫支付供应商选择的任何价格。你的用户甚至可能同意在没有费率限制的情况下访问你的套餐，但你不会看到任何收入。你的开源软件的使用权实际上是为了盈利而出售的，而你，这个软件的作者，却被排除在交易之外。

虽然理论上你可以把你的软件托管在其他地方，但你真的能做到这一点而不破坏你现在的用户吗？如果您维护和分发一个流行的Docker镜像，切换包注册表可能会很困难。

‍如果您稍后决定确实要将托管容器移动到其他地方--比如本例中的Google Container Registry--那么Docker客户端是合理的，它可以让您通过图片的url下载图片：

‍这里的问题是，一旦你更改了图片的网址，你现有的所有用户都将停止获取更新！更糟糕的是，每当用户达到新的速率限制(这不在您的控制之下)时，这可能会中断构建或管道。

当您的容器有相当大的用户群都通过现有的容器注册中心之一时，您的锁定是很大的。移动平台将是痛苦的。问题的症结在于你并不拥有分销渠道。注册表是Web流量的第一个去向，之后发生的任何事情都由注册表供应商自行决定，对他们有利，而不是您的。

有些人可能会回答：这看起来更像是一个理论问题，而不是一个实际问题。

错位的激励结构对开源包托管有几个实际的下游影响。注册表锁定的一个主要影响是维护人员无法访问他们的使用数据。注册表从包下载中自然收集的数据在许多方面对维护人员非常有用，但注册表通常不会共享下载计数以外的任何内容。

注册表知道下载的来源、设备、包版本、与哪些其他包一起安装，等等。与维护人员共享的信息很少，甚至没有。因此，维护人员实际上被禁止观察使用流量。

为甚麽会这样呢？这并不是因为开发人员没有提出要求(https://github.com/npm/npm/issues/279).。这是因为注册机构没有这样做的动机。建立和维护提供这些数据的功能将花费登记处的资金。一些注册机构甚至声称，公开这些数据会激励维护者玩弄系统。与此同时，软件分发中的极端惰性将维护人员锁在了门外。

在一个有机会合作的领域，注册表显示出对维护人员的不信任似乎适得其反。例如，如果登记处的激励措施相应调整，像NPM这样的登记处将处于有利地位，使维护人员能够利用他们自己的分发数据提供尽可能好的软件。

让NPM的特殊情况变得更糟的是，他们让使用非NPM的注册表变得如此困难。在不切换到该注册表的情况下，无法从备用注册表中提取单个包。这使得不把广泛使用的JavaScript包放到NPM上就不可能真正发布它。

将此场景与Docker进行对比：Docker Hub创建了不同的折衷方案，既对OSS维护者有利，也对其不利。他们已经放松了对开放源码软件维护人员的控制，使得从除了Docker Hub之外的其他注册表中取出容器变得用户友好。然而，即使你离开了Docker Hub，你仍然是在从一家公司跳槽到另一家公司。这是因为，归根结底，拥有分发URL的是注册中心，而不是维护人员。权力失衡仍在继续。

我的论点并不是要否定注册处的整体努力。包注册表在软件分发中起着至关重要的作用，总共为数十亿的包下载提供了服务。它们让世界上任何人都可以轻松地与开源互动，并因此帮助推动了开源的发展。令人惊讶的是，它们在很大程度上仍然可以免费使用！但随着软件继续吞噬世界，软件的分发变得越来越重要，这一领域的利益冲突变得越来越成问题。

我们怎么解决这个问题？最终，包注册中心需要将他们的激励措施与维护人员的激励措施保持一致。注册中心应该创建维护人员想要使用的产品，而不是他们必须使用的产品。整个开放源码软件社区都能从中受益。

这在一定程度上意味着注册中心必须更有意识地让维护员重新控制他们自己的软件的分发，即使这意味着维护员可能会把他们的包带到其他地方。作为一个社区，我们应该授权维护人员做好他们最好的工作，而不是强迫他们在特定的平台或框架内工作。

为了开源生态系统的健康，确保维护人员不被阻止访问他们自己的软件分发的数据是至关重要的。维护人员必须能够在了解数据的情况下做出决策，并将分发数据视为理所当然属于他们的东西，而不仅仅是注册表提供商。

不幸的是，当前的软件分发模型将维护员排除在外，使得所有下游操作更加困难，信息也更少。当我们作为一个社区决定更好地与开源维护者结盟并构建平台来增强他们的能力时，结果将是为整个生态系统提供更好的软件。

SCARF正在开发新的工具来解决这些问题，敬请关注！在Twitter上关注@scarf_oss或订阅下面的定期更新。