Rust 项目宣布了首批 Maintainers in Residence（MiR）和 Maintainer Grant 获得者。六位长期贡献者将在未来至少 12 个月获得稳定资助，专注于 rustup、标准库、编译器、Clippy 和 rustdoc 等关键项目的维护工作。
这项计划的意义不只是“给开源贡献者发工资”。它试图解决一个长期存在的问题：用户依赖的是稳定的工具链，但维护者通常只能在工作、学习和生活之余处理 issue、审查代码、修复回归并指导新人。
从临时贡献到稳定维护
Maintainer in Residence 计划由 RFC 3931 建立，当前提供三种支持形式：
- 全职 MiR：每周 5 天从事 Rust Project 工作
- 半职 MiR：每周约 2.5 天从事 Rust Project 工作
- Maintainer Grant：每周约 1 天从事 Rust Project 工作
资金来自 Rust Foundation Maintainers Fund（RFMF），支持方包括 Google、AWS、OpenAI、Rust Project Leadership Council 以及个人捐助者。
稳定资金改变的是维护工作的连续性。维护者可以更完整地处理收件箱，持续推进复杂重构，及时审查 pull request，并为新贡献者保留足够的指导时间。这些任务往往不会立刻产生醒目的新功能，却直接影响项目的可靠性和贡献体验。
资助对象如何确定
Rust Funding team 采用了相对系统化的筛选方式。团队先评估每个项目维持长期健康所需的最低维护人数，再比较当前实际维护力量与这一基线之间的差距。
随后，项目优先考虑两个因素：
- 当前资金支持严重不足；
- 对 Rust 语言和用户具有较高影响力。
进入重点范围的团队包括 rustdoc、rustup、cargo、compiler、libs、clippy、rustfmt、rust-analyzer 和 mods。
不过，需求和可用维护者并不能简单一一对应。部分维护者已经有工作，部分人不希望接受资助，也有人虽然需要资金支持，却没有主动提出申请。一些团队甚至几乎没有活跃成员，这会让新贡献者的入门和授权变得更加困难。
因此，首轮计划选择了六位可以立即开始工作的贡献者。这是一个起点，而不是一次性解决所有维护资金问题的方案。Rust Project 表示，后续资助工作仍会继续。
六位维护者分别负责什么
Gen Li：让 rustup 的基础工作持续推进
Gen Li 是全职 MiR，主要负责 rustup。他自 2023 年加入 rustup team，并在 2025 年成为负责人。资助将帮助他处理复杂问题、继续指导贡献者，并推进重要的 rustup 功能。
他特别提到，稳定的时间预算让自己能够更仔细地处理收件箱和社区交流，而不是在匆忙回复中担心遗漏关键信息。
Chris Denton：补强 Windows 和跨平台支持
Chris Denton 是半职 MiR，关注标准库、编译器、rustup 以及 Windows 相关工作。他过去五年持续利用 Windows 领域的经验，帮助 Rust 改善跨平台支持。
他的工作包括解除 Windows 场景下的贡献阻塞、重构、代码审查，以及在多个 Rust Project 区域实现新功能。
Alejandra González：降低 Clippy 的维护压力
Alejandra González 是半职 MiR，主要负责 Clippy。她将关注性能优化、pull request 审查，以及积压请求的处理。当时 Clippy 约有 300 个 pull request backlog，维护者资助能够为清理积压和改进流程提供连续投入。
她还计划指导 Rust for Linux 项目的贡献者参与 Clippy，并继续完善 Clippy 已开始采用的开放式同行评审机制。
León Liehr：推进 rustdoc 和编译器的复杂问题
León Liehr 是半职 MiR，关注 rustdoc 和编译器，长期参与 Rust 类型系统、解析以及相关复杂功能的开发。
除了继续推进已经开始的功能，他还会投入一般维护、代码审查、重构和贡献者指导。这类工作通常跨越多个版本周期，更需要稳定而非碎片化的时间。
Jonas Böttiger：维护标准库在不同平台上的行为
Jonas Böttiger 获得 Maintainer Grant，主要负责标准库。他会利用自己在研究工作中培养的分析能力，帮助确保 Rust 程序在不同平台，尤其是行为较为特殊的操作系统上，能够快速且正确地运行。
他也重视帮助其他贡献者写出自己能够长期维护、并且值得自豪的代码。
Jason Newcomb：修复 Clippy 问题并改善贡献流程
Jason Newcomb 获得 Maintainer Grant，主要负责 Clippy。他关注 bug 修复、降低 Clippy 的开发和贡献门槛，以及让代码审查流程更加顺畅。
可以怎样实践：把维护工作写进项目机制
资金是维护工作的基础，但项目也需要把维护职责显式化。下面是一个可以直接改造的 GitHub 配置示例。假设项目使用 GitHub，并且希望把维护基金、贡献入口和日常维护职责放在仓库中公开说明。
在仓库中创建 .github/FUNDING.yml：
# 根据实际账户替换下面的占位符。
# GitHub 支持的字段以平台当前文档为准。
github: [example-maintainer]
# 也可以保留项目自己的长期资助入口。
custom:
- https://funding.example.org/project
再创建一个简单的维护职责清单，例如 MAINTAINERS.md：
# Maintainers
| Area | Owner | Review target | Backup |
| --- | --- | --- | --- |
| compiler | @compiler-owner | 7 days | @compiler-backup |
| docs | @docs-owner | 5 days | @docs-backup |
| lint | @lint-owner | 7 days | @lint-backup |
## Weekly maintenance
- Triage new issues and label regressions.
- Review pull requests older than seven days.
- Record blocked items and request help from the relevant team.
- Reserve time for mentoring new contributors.
如果项目需要快速查看待处理请求，也可以先用 GitHub CLI 做一个轻量统计。下面的命令只依赖 gh，需要提前完成 gh auth login：
#!/usr/bin/env bash
set -euo pipefail
repo="${1:-owner/project}"
printf 'Open pull requests for %s:\n' "$repo"
gh pr list --repo "$repo" --state open --limit 100 \
--json number,title,createdAt,author \
--template '{{range .}}#{{.number}} {{.title}} | {{.author.login}} | {{.createdAt}}\n{{end}}'
这类自动化不能替代判断，但可以把“没人知道积压了多少”变成可观测数据。结合维护者时间预算，项目可以进一步设定审查目标、升级规则和新人指导安排。
这项计划带来的启示
对 Rust Project 来说，首批 MiR 计划体现了一个重要判断：成熟开源项目的风险不只来自代码缺陷，也来自维护能力不足。
一个编译器、包管理器或代码检查工具，即使功能已经很丰富，也需要持续处理平台变化、回归问题、文档更新、代码审查和生态反馈。如果这些工作长期依赖少数志愿者的碎片时间，项目的总负担会逐步集中到个人身上，贡献者流失也会变得更难逆转。
但资助计划也有边界：
- 12 个月的支持不等于永久预算，项目仍需要建立长期筹资能力；
- 资金不能自动生成维护者，低活跃团队仍需要培养新人和完善授权流程；
- 受资助者需要清晰的职责、公开的工作范围和可持续的协作方式；
- 维护指标不能只看关闭了多少 issue，还应关注回归处理、审查延迟、文档质量和新人留存。
结语：维护本身就是核心工程
Rust 的首轮计划支持 Gen Li、Chris Denton、Alejandra González、León Liehr、Jason Newcomb 和 Jonas Böttiger，覆盖 rustup、标准库、编译器、Clippy 与 rustdoc 等关键区域。
这次公告最值得关注的，不只是六位受资助者的名单，而是 Rust Project 开始把维护活动当作一项需要长期投入、明确预算和组织设计的工程工作。对于其他开源项目，值得参考的实践清单包括：
- 统计每个关键组件的最低维护基线；
- 公开 issue、pull request 和审查延迟等维护信号；
- 为全职、半职和小额 grant 设计不同支持档位；
- 为受资助者定义可调整但清晰的工作范围；
- 给新人指导、代码审查和社区响应预留正式时间；
- 同时建设项目基金和个人赞助渠道。
当维护者不必持续在贡献和生计之间做选择时，项目才更有机会把可靠性、兼容性和社区传承真正做长久。