Rust 维护者基金进展：已收到 $350K 捐款，MiR 合同先定地理无关的 flat rate

这是 funding team 的进展更新。funding team 由 leadership council 设立，负责管理 Rust Foundation Maintainers Fund。按照 RFC #3931，初期重点放在建立 Maintainer in Residence（MiR）项目。MiR 的目标是为从事维护工作的人提供一种长期、稳定的支持方式。

基金总额与捐款渠道

目前已收到总额 $350K 的捐款。

• 个人可以在 GitHub Sponsors 直接赞助 Rust Foundation Maintainers Fund：
• 公司或较大额捐款，联系 funding@rust-lang.org。

摸底：谁在找钱

funding team 向现有 Rust 团队成员发出消息，邀请有兴趣接受资助的人填写表单。共有 45 人表示希望获得资助，另有 3 个团队给了整体情况更新。

按领域拆分（有重复计数，因为部分人勾选了不止一个领域）：

compiler 21、libs 4、clippy 3、rustdoc 2、a-mir-formality 1、cargo 1、crates.io 1、infra 1、lang 1、mods 1、Rust Analyzer 1、rustup 1、Safety Critical Rust Consortium 1。

在这些回复者中，34 人对通用维护（MiR）角色表示兴趣，13 人希望针对具体项目目标获得资助（有人两者都选）。问卷也问了期望的安排方式与报酬水平：差异很大，很多人倾向全职雇佣，也有不少人接受合同制或兼职。

2025 年调查：需求是真实的

2025 年 11 月，funding team 在活跃的 Rust 维护者中做过一次调查。结果显示：

• 35% 填写问卷的贡献者目前其 Rust 贡献是有资助的（这个统计也包括每月只拿到很小金额的人，比如通过 GitHub Sponsors 获得的赞助）。
• 相近比例（约 35%）从未因上游 Rust 工作获得任何资助。
• 即使很多人完全没有资助，一位 Rust Project 贡献者每月花在改进 Rust 上的平均时间仍约为 40 小时。

MiR 项目的细节敲定

MiR 项目的目标是提供开放式资助来支持 Rust 维护者，并由此间接支持他们所在的 Rust 团队。

关键在于 MiR 要帮助「让其他贡献者能够演进并改进项目」。对一些团队来说，这可能意味着帮忙主持 triage 会议，或清掉积压的 PR review；对另一些团队来说，可能意味着专注做一次大家都知道必要、但没人有时间做的大重构。

合同形态：一年期，预期续签但不保证

MiR 项目起步阶段采用一年期合同，附带逐年续签的预期，但不构成续签保证。项目刚开始，还无法判断资金的稳定程度，因此不能对续签做长期承诺。

flat rate 还是协商费率：选 flat rate

决定先采用 flat rate，不按地域区分。这样做更透明、更好管理，也避免「因为更会谈判、或者住的地方不同就拿得更多」这类公平性争议。代价是：MiR 项目不适合生活在高成本地区的人，也不适合期望薪资高于此标准的人。

费率表

参考了收集到的期望费率数据，也参考了其他基金会的类似做法（例如 Zig）。最终确定如下 flat rate，个别情况可能做小幅调整。这里刻意不写成小时费率，而是「每月费率 + 预期投入强度」，因为不打算要求提交按小时计的工时报告。

这些金额是 Rust Foundation 支付给承接工作的个人或实体的数额，不是税前工资或到手收入。

是否排他：不排他

MiR 合同不排他。MiR 可以在外接其他合同，只要不影响其完成维护工作即可。

讨论中的 off-ramp

funding team 预期 MiR 合同逐年续签，但无法保证。因此在考虑在预算中留出一部分「缓冲」：如果一年后无法续签，可以给 MiR 受助人一个 off-ramp——一笔短期支付，帮助其在寻找新岗位期间覆盖开支。待定的问题包括：

• 是否做 off-ramp？（倾向于做，但意味着 MiR 总数会减少。）
• 对所有人都做吗？（考虑只覆盖 full-time，或 full-time 加 half-time。）
• 时长多长？（初步想法是 25%、3 个月；更短则能资助的工作更多。）

为什么不直接雇佣

对很多人来说雇佣是理想形态，但目前无法提供，因为雇佣需要持续的资金来源。随着 MiR 项目演进，希望未来能为成熟的 Maintainer in Residence 提供长期雇佣。

如何决定资助哪个 MiR 角色

funding team 决定不先从「找钱的个人」出发，而是先看需要资助的团队。确定的公理按优先级排序如下：

1. 终端用户影响优先：优先资助对 Rust 用户体验有真实（直接或间接）影响的领域。
2. 紧急需求优先：先解决需求最大的团队——先把地板抬高，再抬高天花板。
3. 资助别人不会资助的：倾向于维护、review 和 triage：这些工作没有天然的企业赞助方，也没有可指望的定向资助路径。
4. 按需扩展：对于有很大定向资助潜力的领域，仍然资助维护者，以在功能开发之间保持代码健康。
5. Shovel-ready：在优先级相同的需求之间，从能最快启动的那个开始。

团队短名单：rustup、rustfmt、clippy、rustdoc、libs、cargo、mods。

讨论中：如果没有 MiR 申请人怎么办

有些团队希望支持，但其现有成员没有兴趣承担 MiR 角色。可能的做法是联系该团队，看是否有活跃贡献者愿意被其支持成为 MiR；或者公开发出申请征集。

定向资助（restricted funding）

到目前为止所有资金都是不限定用途的。一些赞助方提出定向资助的想法：为某个特定团队（比如 rustfmt 或 cargo）资助一名 MiR，或者资助某个具体个人。决定是：只要被资助者做的是维护工作、并且总体上按与其他 MiR 相同的方式对待，就乐意接受定向资助。

后续路线图

1. Rust Foundation 宣布项目并开始募资；
2. Leadership Council 设立 funding team，并勾勒 MiR 项目框架（RFC #3931）；
3. funding team 收集谁在找资助的信息（本次更新）；
4. funding team 敲定 MiR 细节（本次更新）；
5. funding team 收敛到短名单并开始个别沟通；
6. funding team 公布 MiR 人选；
7. MiR 开始干活。

目标是在 8 月底前公布名单。

相关背景与链接

• Rust Foundation 公告：
• Rust Blog 启动文章：
• RFC #3931：
• 资助页面：；Maintainers in Residence 名单：
• 首批公告（从 Google、AWS、OpenAI、Rust Project Leadership Council 募得 $350,000，目标是以 $120,000 资助一名 Full Time MiR）：
• Rust Project 博客：；funding team Zulip 频道：
• 独立项目：NLnet Rust Maintainer Fund （由 NLnet Foundation 与 RustNL、Commons Caretakers 运营，与 Rust Foundation 无关联）
• GitHub Sponsors：