开源资助平台 thanks.dev 机制解析：依赖树如何决定谁获得资金

上篇文章写了被 Canonical 捐款这件事，有读者好奇：你是如何被选中的？

最初我也有些困惑，直到深入研究了 thanks.dev 的底层运作逻辑，才把整件事的来龙去脉理清楚——更重要的是，明白了什么样的开源项目更容易被下游厂商的资金“砸中”。

thanks.dev 如何分配资金？

thanks.dev 的核心机制，本质上是一套自动化的依赖树扫描与按比例分配系统。

当下游厂商接入该平台后，thanks.dev 会扫描其所有 GitHub 仓库的依赖关系，并向下追踪三层。随后，平台会根据项目“被依赖的频率”将捐款按比例分配出去。简单来说，你的项目出现在越多厂商的仓库依赖树中，最终分到的资金比例就越高。

整个过程完全自动化，无需人工筛选——算法是唯一的决策者。

这也就解释了我的情况：我维护的 badgepy 项目被 Canonical 的某个仓库用到了，因此进入了他们的依赖树，资金就自动流了过来。这并非因为项目知名度有多高，纯粹是因为“被用到了”而已。

谁是主要的捐赠方？

目前，在 thanks.dev 平台上较为活跃的几个大额捐赠方包括：

• Sentry 是该平台迄今为止最大的企业捐赠者，过去几年累计捐赠了超过 200,000 美元。
• Canonical（Ubuntu 背后的公司）在 2025 年承诺，将在 12 个月内捐出 10,000 美元。目前其捐赠已覆盖超过 350 个 GitHub 项目，从各类 linter、代码覆盖率工具，到 Pallets Project 乃至 Sindre Sorhus 的个人项目，都在名单之列。
• Codecov 的累计捐赠额也超过了 86,000 美元，排名第二。

然而，如果我们粗略计算一下便会发现，即便这三家最大的捐赠方加起来，总金额也不过百万美元级别。这笔钱在硅谷，可能只够支付两三位资深架构师的年薪。

因此，当资金被分配给成千上万个开源项目后，每个项目能分到的数额确实非常有限。与维护者们所投入的大量时间和精力相比，这点经济回报几乎不成正比。

但话又说回来，有人愿意掏钱回馈，总比那些只使用、不回馈的公司要强得多。

什么样的项目更容易“中奖”？

这是最关键的问题。thanks.dev 的算法不看重项目的 star 数或知名度，它只关注一件事：你的项目是否真实地出现在下游厂商的依赖树中。

这意味着，最容易获得资金的项目，往往是那些“默默无闻但不可或缺”的基础设施类工具：

• 编程语言生态中的基础库：例如 Python 的 coverage.py、TypeScript 的 ts-loader。由于几乎每个项目都会使用，它们自然频繁出现在依赖树里。
• 开发工具链：各类 linter、代码格式化工具、测试运行器、CI 相关工具等。工程师日常开发离不开它们，大型代码仓库中大概率会包含。
• 针对特定问题的解决方案：项目无需大而全，但需要切实解决一个具体、真实存在的问题，并且解决得足够出色。

反过来说，那些纯粹面向终端用户的应用类项目，或者尚未被任何大型代码库依赖的项目，基本上不在当前算法的覆盖范围内。

一个容易被忽略的前提

还有一个关键点常被忽视：thanks.dev 要求项目维护者主动注册平台，才能接收资金。

算法可以扫描到你的项目，但如果你没有完成注册，资金是无法流转过来的。因此，如果你正在维护某个开源项目，哪怕规模不大，只要它有可能被其他项目或公司所依赖，去 thanks.dev 上注册一下总没有坏处——说不定哪天 Sentry 或 Canonical 的扫描算法就找到你了。这也是参与开源实战的一种务实方式，了解如何让项目被看见并获得支持。

一点现实的思考

Tidelift 在 2024 年的调研数据显示：超过六成的开源维护者从未因其维护工作获得过任何报酬。

这就是开源世界的现实。大多数人依靠热情和业余时间支撑着一个项目，但热情难以持久，许多项目也因此停滞、烂尾乃至消失。

thanks.dev 这类机制的价值，不仅在于“给维护者发点钱”，更在于它尝试建立一种能让开源生态持续运转的资金流动模式。虽然它目前的规模还很小，但方向无疑是正确的。

对于那些真正从开源项目中获得巨大商业利益的大公司而言，应该清楚自己需要做些什么。健康的开源生态需要可持续的支持，而不仅仅是索取。想了解更多开发者之间的见解与讨论，欢迎来云栈社区交流。