开源仓库遭遇万亿级下载压力
ZDNET AI··作者 Steven Vaughan-Nichols
关键信息
Sonatype 表示，82% 的需求来自仅占 1% 的 IP，说明少量自动化消费者制造了极不成比例的流量。文章还指出，构建流程、CI 流水线、AI 系统、机器人流量和滥用行为暴露出了一个既涉及运维又涉及安全的“可持续性缺口”。
资讯摘要
ZDNET 报道称，开源软件包仓库每年要承受约 10 万亿次下载，这一规模正在把主要仓库推向极限。负责 Maven Central 的 Sonatype CTO Brian Fox 表示，问题不仅在于流量总量大，还在于很多组织把仓库当作 CDN 来使用，以机器速度反复下载同样的制品。Fox 提到一个非常集中的流量特征：82% 的需求来自仅 1% 的 IP 地址。文章认为，公共仓库已经成为软件供应链的重要组成部分，几乎所有现代构建流程都会经过这些系统。
正因为如此，仓库一旦失灵，影响就不会只停留在开源社区，还会波及银行、医院、云平台和政府机构。为此，各大仓库运营方正准备在 Linux Foundation 旗下成立 Sustaining Package Registries Working Group。这个工作组的目标是找到可行的资金、治理和安全方案，让这些基础设施在需求持续增长的情况下保持韧性。报道将这一问题定义为供应链韧性风险，而不只是简单的托管成本问题。
资讯正文
开源仓库正承受着每年 10 万亿次下载的重压。
所有主要仓库都在联手解决这一问题。
虽然资金短缺是问题的重要组成部分，但还有其他问题也需要应对。
世界运行在开源软件之上，这我们都知道。但你知道吗，企业每年会下载超过 10 万亿（是 trillion，不是 billion）个开源代码文件？据软件安全提供商 Sonatype 称，确实如此——而提供这些代码的文件仓库网站，正因这种需求而不堪重负。
正如 Sonatype 首席技术官 Brian Fox 此前今年告诉我的那样，他负责的 Maven Central Java 注册表正面临被持续下载压垮的风险。Fox 和他的团队发现，82% 的需求来自仅 1% 的 IP。这是因为企业把开源仓库当成内容分发网络（CDN）来使用。
例如：一家企业可能在一天之内把同一份代码下载几十万次，第二天还会如此，接着第三天仍然如此。一个非营利的开源代码仓库该怎么办？
我们正面临供应链韧性风险。
运营这些仓库的人终于开始集体表示：“这不能永远靠慈善维持下去。”如今，在 Linux Foundation 的框架下，一个新的 Sustaining Package Registries Working Group 将寻求确定切实可行的资金、治理和安全实践，以便在下载量不断增长的情况下保持代码流动。
这一切始于一个扩展问题。在过去几年里，公共软件包注册表上的使用和发布量已经增长到惊人的程度。那 10 万亿次下载？这相当于 Google 年度搜索查询量的两倍，而且不同于 Google，这些开源站点是在极其有限的资源下完成这一切的。
问题在于：由于软件构建、持续集成流水线和 AI 系统以机器速度而非人工速度轰击这些注册表，网站根本无法跟上。这种增长带来了机器人流量、自动化发布、安全报告以及直接滥用的激增，暴露出工作组直言不讳所称的“可持续性缺口”。换句话说，我们如今面对的是供应链韧性风险，而不仅仅是一张托管账单。
正如 Fox 所解释的那样：“开源注册表已经不再只是被动的分发点。它们是运行在几乎每一次现代软件构建路径中的运营和安全关键系统。如果我们希望软件供应链保持韧性，就必须严肃讨论如何在全球范围内为这些平台提供资金、治理并维持其运转。现在是时候把注册表可持续性视为整个软件行业的共同责任了。”
注册表网站不只是下载镜像
他说得对。开源注册表网站已经不再是简单的下载镜像。它们是安全关键系统，直接处在几乎每一次现代软件构建的路径中。
如果任何核心注册中心出现故障，无论是由于成本、倦怠，还是一次成功的攻击，其冲击范围都将远远超出开源社区，波及银行、医院、云服务和政府——这些机构很少会去思考自己的代码依赖究竟来自哪里。Open Source Security Foundation（OpenSSF）的 CTO 兼首席安全架构师 Christopher Robinson 补充说：“软件包注册中心位于软件供应链安全与韧性的最前线。随着消费、发布和攻击活动的速度加快，这些系统背后的治理也必须随之演进。这个倡议将为注册中心领导者和生态系统利益相关方提供一个重要平台，使他们能够就切实可行、以社区为导向的方式达成一致，从而支撑现代软件所依赖的基础设施。”
还有：Microsoft 终于开源了 DOS 1.0——而且它远不只是那段代码
Fox 指出：“这比任何一个注册中心都更大。最初在 Maven Central 上呈现为一种运营现实的事情，如今已不再适合仅仅被理解为 Maven Central 的故事。相同的模式正在各个生态系统中出现。机器流量更多了。自动化更多了。扫描更多了。人们对正常运行时间、完整性、来源证明和策略执行的期望也更高了。成本更高了。支持负担更重了。对基础设施的依赖更深了，而这个行业仍然把这些基础设施说得仿佛它们是靠善意和业余时间运转的。” 透露一下：并不是这样。
为应对这一问题，Sonatype 已与 Linux Foundation 以及其他软件包注册中心领导者联手合作，其中包括 Alpha-Omega、Eclipse Foundation（OpenVSX）、OpenJS Foundation、OpenSSF、Packagist、Python Software Foundation、Ruby Central（RubyGems）和 Rust Foundation（Crates）。其想法是为运营方提供一个中立论坛，公开讨论资金、治理以及共同的运营负担。一旦这些问题得到处理，他们还将协调整体对外的解释方式，向那些长期以为注册中心是“免费的”公司和组织说明现实情况。并不是。它们从来都不是。
正如 Linux Foundation 所指出的那样：“如今的注册中心主要运行在两样东西上：（1）基础设施捐赠和额度；以及（2）由少数带薪团队——这些团队本身由捐款和资助提供资金——以及无偿志愿者所付出的英雄式努力，他们负责运营和维护注册中心服务。大部分捐款和资助来自少数捐赠者，而且这种模式并不会随着注册中心需求的增长而扩展。”
仓库需要的不只是资金
该工作组被明确定位为一个场所，在这里注册中心领导者和生态系统利益相关方可以就“切实可行、以社区为导向”的方式达成一致，以维持这些基础设施，而不是让每个运营者都孤立地自行琢磨各自的生存方案。
尽管开源仓库迫切需要更多资金来满足需求，但问题并不只是钱。还有许多其他要求也需要得到解决。
这些问题包括：
此外：AI是如何突然变得对开源开发者有用得多的
经济可持续性：制定融资模式，真正能够覆盖基础设施、运营、维护者和治理，而不是依赖英雄式的志愿主义加上少数几家公司的标志。
集体防御：在各个代码仓库之间协调安全实践和信息共享，使它们能够更快地发现并应对威胁，因为攻击者也在自动化并扩大自己的活动规模。
治理赋能：制定共享的政策框架和标准化条款，使引入可持续融资模式在政治和法律上成为可能，而不会撕裂社区。
生态系统教育与透明度：统一信息传达和教育内容，让开发者、企业和政策制定者最终理解运营这些服务到底需要多少成本，以及为什么“无限免费永远下载”从来就不是一个现实的计划。
一些组织已经在处理这些问题，但没有任何一家同时为所有这些问题建立好相应的政策和人员配置。希望通过协作，他们能够制定出一套所有代码仓库都能使用的框架，而不必让每个人都重新发明轮子。
此外：我试用了新的 Linux Mint 22.3——它堪称打磨和易用性修复方面的典范。
支持开源代码仓库已经成为软件行业每个人都必须面对的关键任务。然而，直到最近，这件事一直都不为人所见。我们再也没有奢侈去假设志愿者会一直把开源代码库的大门敞开。这些网站必须得到我们的支持，否则当我们在开发、构建和运行公司所需的程序时，我们都会陷入麻烦，而这些程序正是让业务持续运转的关键。
来源与参考
收录于 2026-05-07