上篇文章写了被 Canonical 捐款 这件事，有读者问：你怎么就被选中了？
一开始我也没搞清楚。后来认真研究了一下 thanks.dev 的运作机制，才把整件事的底层逻辑想明白了——以及，什么样的项目更容易被下游厂商的钱砸到。
thanks.dev 是怎么分钱的#
thanks.dev 的核心玩法，本质上是一套自动化的依赖树扫描 + 按比例分配系统。
下游厂商接入之后，thanks.dev 会扫描他们所有 GitHub 仓库的依赖关系，往下追踪三层，然后按照"被依赖的频率"把捐款分配出去。你的项目出现在越多仓库里，分到的比例就越高。
整个过程是全自动的，不需要人工挑选——算法替他们做决定。
这就解释了我的情况：badgepy 被 Canonical 某个仓库用到了，进了他们的依赖树，钱就自动流过来了。不是因为项目有多出名，只是因为"不小心被用了"。
谁在往里面砸钱#
目前 thanks.dev 上最活跃的几个大捐赠方：
Sentry 是平台迄今最大的企业捐赠者，过去几年累计捐出超过 $500,000，覆盖 500 多个开源项目。他们内部有一条规则：每位工程师每年对应 $2,000 的开源捐赠预算。
Canonical（做 Ubuntu 的那家）2025 年承诺 12 个月内捐出 $120,000，每月 $10,000，目前已覆盖超过 350 个 GitHub 项目——从 linter 到 coverage 工具，从 Pallets Project 到 Sindre Sorhus 的个人项目，都在名单里。
Codecov 排名第二，累计捐赠额 $86,000+。
但算一下就会发现，这三家最大的加起来也不过百来万美元，这点钱放在硅谷，顶多够付 2 到 3 个资深架构师的年薪。
所以分给成千上万个项目之后，每个项目能拿到的其实很有限。跟开源维护者付出的时间相比，这点钱根本不成正比。
不过话说回来，有人掏钱了总比那些拿了项目一分不回馈的公司要强多了。（这里就不点名了，反正大家心里都有数。）
什么样的项目容易被选中#
这是最关键的问题。
thanks.dev 的算法不看 star 数，不看知名度，只看一件事：你的项目是否真实地出现在下游厂商的依赖树里。
这意味着，最容易拿到钱的项目，往往是那种"默默无闻但不可或缺"的基础工具：
- 语言生态里的基础库：比如 Python 的 coverage.py、TypeScript 的 ts-loader，几乎每个项目都会用，自然频繁出现在依赖树里
- 开发工具链：linter、formatter、test runner、CI 相关工具，工程师日常都在用，大型仓库里大概率有
- 特定问题的解决方案：不需要大而全，但要解决一个真实存在的具体问题，而且解决得足够好
反过来说，纯粹面向终端用户的应用类项目、或者没有被任何大型代码库依赖的项目，基本上不在算法的覆盖范围内。
被选中还需要一个前提#
有一点容易被忽略：thanks.dev 要求项目维护者主动注册，才能接收资金。
算法可以扫到你，但如果你没注册，钱就流不过来。
所以如果你维护着某个开源项目，哪怕规模不大，只要它有可能出现在别人的依赖树里，注册一下 thanks.dev 没什么损失——说不定哪天 Sentry 或者 Canonical 就扫到你了。
最后说一句#
Tidelift 2024 年的调研数据显示：六成的开源维护者从未因为维护项目拿到过一分钱。
这是开源生态的现实。大多数人靠热情和业余时间撑着一个项目，但热情撑不了多久，项目也会因此停更、烂尾、消失。
thanks.dev 这类机制的价值，不只是"给维护者发点钱"，更是在尝试建立一种让开源生态可以持续运转的资金流动方式。
它规模还很小，但方向是对的。
那些真正从开源项目中获益的大公司，你们知道自己该做什么。别吃相太难看了。
