展示我们的工作：econyste.ms Python 基金独立基准测试Showing Our Work

本周，来自 fortiss 和慕尼黑工业大学的 Alexandros Tsakpinis、Emil Schwenger 和 Alexander Pretschner 在 arXiv 上发表了一篇预印本论文：《建模维护活动变更对依赖传播型生态系统的影响》。他们构建了一个模型，用于分析 Python 依赖关系图中维护变更的传播路径，并基于该模型分析了 PyPI 上的 718,750 个包及其之间的两百万条依赖边。随后，他们将三种现实世界中的支持机制与该模型进行对比，评估每种机制所选择的包是否与模型预测的支持效果最佳区域相匹配。

这三种机制分别是 Tidelift 的“提升”（lifted）包、GitHub Sponsors 以及 ecosyste.ms 的 Python 基金。该基金由我们与 Open Source Collective 共同运营：组织向某个语言生态整体注资，而非单独资助特定项目，资金将根据我们的依赖数据分析结果，分配给那些被认为最关键的项目，并通过各维护者已设置的资助渠道发放。

在全部 PyPI 包的模型评估中，这仅包含 97 个包的 ecosyste.ms 选择，却覆盖了 25.9% 的总改进影响和 38.0% 的总回归影响。正如论文所述：“尽管规模较小，ecosyste.ms 仍显示出与高影响力包的高度一致性。”在所有测试机制中，其单位包效率遥遥领先。

我负责运营 ecosyste.ms，因此并非该结果的客观读者，通常也不在此博客中推广自家项目。但此次测试的设计、指标选取及执行过程均非我所为。一个独立团队利用原始 PyPI 数据构建了自身模型，发现我们的选择与其他任何可测量机制相比都更为契合。这种外部验证并不常见，我认为值得分享。

十年的依赖图谱研究

我和 Ben Nickolls 在过去十年中一直致力于此项工作，始于 2015 年的 Libraries.io。从一开始，我们的核心理念就是：相较于下载量或星标数，依赖图谱才是判断哪些开源项目真正重要的正确结构。下载量主要反映 CI 系统重复安装环境的行为，而星标则体现的是拥有 GitHub 账户并会点击按钮的人群中的可见度。

声明的依赖方（declared dependents）是我们目前最接近实际使用情况的直接度量方式。与前述两者不同，它既能上升也能下降：当用户迁移至其他库时，依赖计数会减少；而星标保持不变，下载量仍因历史 CI 运行持续累积。这种双向变化的信号，使我们在无需额外测量的前提下，就能推断出项目的真实地位。

ecosyste.ms 正是这项工作的成果，早已远超最初的项目范畴。目前，它索引了数十个注册中心共计超过 1400 万个包和 1.57 亿个版本，包含近 20 亿条版本级依赖声明，并关联了安全公告、提交者、资助链接及发布历史等信息。仅 PyPI 就涵盖 86 万个包和 890 万个版本。本文所用图谱基于每个包的最新版构建；而我们则保留了历史上所有版本的依赖关系，这正是实现动态追踪图谱随时间变化所需的条件，而非仅取某一时刻的快照。

在此基础上，还有一个更大的图，包含2.92亿个源代码仓库和240亿条边，这些边指向它们所安装的包，从而可以了解某个库在自身注册范围之外还有哪些依赖。所有数据均为开源，数据采用开放许可，API每月处理约16亿次请求。

论文的核心公式是：你间接依赖的包的数量乘以你的维护状态可能发生的变化程度。这是一个基于与基金选择相同类型数据的依赖图指标。两个独立团队基于同一前提得出高度重叠的名单，这大致就是验证的过程。

作者于二月在GitHub和注册表的速率限制下，花了五天时间构建了他们的PyPI快照。同样的图已经在ecosyste.ms上为npm、RubyGems、Maven、Cargo、Go、Packagist、Hex等数十种语言提供，持续更新并可随时查询。明天早上，这种方法就可以应用于每一个主要编程语言生态，而无需任何人再写爬虫，我非常希望有人能去做这件事。

论文中的最优选择是730个包，可实现80%的建模影响。ecosyste.ms为PyPI选定的关键集（critical set）目前有523个，是通过不同方法、出于不同目的挑选的。我拉取了复现包，并将我们的523个包运行了相同的模型：它们覆盖了总改进影响的约64%和总回归影响的76%，与论文的最优结果相差无几，远超其对比表中的任何方案。他们的730个中有333个已在我们列表中，特别是在回归方面——“如果停止维护，什么影响最大”这一问题中，他们的204个中有165个也包含在内。

识别关键包是几乎所有认真支持开源的第一步，而大多数尝试仍从零开始，按每个生态系统分别进行，仅利用注册表API在下午就能获取的数据。通过Open Collective的资金、签署开源承诺的公司、Alpha-Omega带来的安全工程、政府试图枚举数字基础设施的努力——这一切都需要一个站得住脚的答案：“哪些包是关键包，为什么是这些包。”依赖图是我所知给出这一答案的最佳基础，而ecosyste.ms的存在就是为了让人不必重建它，就能直接开始使用。

它无法衡量的内容

维护信号是作者自己指出的一项局限：即OpenSSF Scorecard的Maintained检查——要求GitHub仓库在九十天内保持提交和问题活动。上周我写过，随着机器人和定时代理不断让项目贡献图保持活跃，而实际上无人阅读，基于活动的信号正变得越来越不可靠。论文自身的改进排名前列的是idna、colorama、six、python-dateutil、zipp和pyyaml，它们的Maintained得分为零，但分别有9万到20万个PyPI包间接依赖于它们。这些包实际上是已完成而非被废弃，而90天的活动窗口无法区分这一点。该研究还仅限于PyPI和GitHub，少数高影响力包因缺少仓库URL而被完全排除分析，但由于每种机制都以相同方式评分，因此不影响比较结果。

回归结果的一半表明，如果这97个包全部降至零维护分数，仅此一项就占PyPI总可能维护崩溃的38%。论文将其视为一个可模拟的假设，但上周我尝试测量这一假设在十六个生态系统的关键集合中实际有多“假设”，发现其中约12%的仓库已不复存在，另有20%只需一人之力即可放弃，还有19%因无人测试而处于未验证状态。如今我们已有非常充分的数据来判断哪些包在结构上是关键的。但这些包背后的人处于什么状态，则是另一个更难回答的问题——而这正是未来十年需要解决的核心所在。