谁给 crates.io 付账单：Rust 基金会的治理边界与资金通道

Rust in Production 播客（corrode.dev 出品，主持人 Matthias Endler）请到了 Rust 基金会的三位核心人物：Rebecca Rumbul（基金会执行董事兼 CEO）、Lori Lorusso（外联总监）、David Wood（从业 8—9 年的 Rust 核心维护者，同时作为项目代表坐在基金会董事会里）。这期对谈涉及的问题包括：crates.io 挂了找谁修、编译器 CI 流水线的账单谁在付、有人恶意抢注 Rust 商标谁来打官司，以及基金会与项目之间那条“权、钱分离”的红线到底划在哪。

播客原文与音频：https://corrode.dev/podcast/s06e08-rust-foundation/

为什么需要一个独立于 Mozilla 的基金会

Rust 最初孵化于 Mozilla 内部。Rebecca Rumbul 解释独立出来的核心原因：一门语言想要真正“长开”，需要被足够多元的组织共同支持，这要求语言具备厂商中立性。如果 Rust 一直挂在 Mozilla 名下，其他公司几乎不可能心甘情愿地把钱投给 Mozilla 去“帮它养孩子”。企业需要的是一个谁都不隶属、谁都能平等参与的中立空间。这也是绝大多数主流编程语言最终走向基金会化的原因——基金会提供的不只是钱，更是一种让不同商业实体安心协作、不必顾虑 NDA 和法务纠纷的公共场地。

Lori Lorusso 从企业视角补充：如果公司在生产环境重度使用 Rust，却从没关注过基金会，本质上是在给自己的技术选型埋雷。基金会存在的意义之一，是充当确定性的保险——今天能跑通的 CI 任务，明天依然能跑通；今天能用的语言特性，不会因为某个赞助商撤资就突然停摆。用 David Wood 的话说，维护者们某种程度上是在“理所当然地享受”基金会的支撑：PR 有人跑测试，商标遇到纠纷有专业人员处理。

治理边界：基金会管“地基”，项目管“语言”

David Wood 对治理边界的界定是：项目本身仍然完全自治——编译器团队、库团队如何运作，接受什么样的贡献，RFC 是否通过、特性是否 stabilize，全部由项目的贡献者和维护者自己决定。基金会做的，是让这套自治机制顺畅运转下去。Rust 基金会与 Rust 项目之间存在清晰的“权、钱分离”：

• 基金会侧：基础设施（CI、crates.io 托管、发布分发）、资金筹措与分配、法律与商标事务、商业连接（会员网络、培训认证）；
• 项目侧：语言演进（RFC、稳定化）、编译器实现、各技术团队（compiler team、lang team、library team 等）的内部治理。

David Wood 拿 C++ 和 Python 做了对比：C++ 走 ISO 路线，各国家代表投票决定提案是否通过；Python 设有 Steering Council，几乎每个 PEP 都要经过核心委员会审议；Rust 没有单一的“最高决策委员会”，而是把语言不同子系统拆给多个独立团队——编译器团队负责保证编译器质量、每 6 周稳定发版；语言演进团队负责保证语言表面积的连贯性和一致性；此外还有库、crates 生态、cargo 等各自独立的团队。

基金会董事会也不是一个纯商业俱乐部：白金级付费会员可以获得董事会席位，但项目也有独立的代表席位（David Wood 正是其中之一）。企业出钱买不到对语言设计的话语权，买到的是连接与支持；语言怎么演进，最终还是工程师和维护者说了算。

标准化和治理是两件事：Ferrocene、FLS 与 SCRC

Rust 目前不是一个 ISO 标准语言，但这不妨碍它在安全关键场景（医疗设备、汽车、航空航天）里逐步建立可验证的规范。最典型的例子是 Ferrocene——基金会成员之一 Ferrous Systems 开发并捐赠给 Rust 项目的语言规范（FLS，Ferrocene Language Specification），用于满足 ISO 26262（车规）等场景对“编译器行为可追溯、可验证”的合规要求。围绕安全关键场景，业界还成立了 SCRC（Safety Critical Rust Consortium），专门协调这一领域的标准化诉求。

David Wood 特别澄清：Rust 项目本身并不做任何“编译器认证”工作——认证是不同厂商基于开源 Rust 派生出自己的编译器发行版，再自行对照规范做合规声明的商业行为，这和“语言是否被 ISO 标准化”是两条完全独立的路径。

Rust 商业网络（RCN）

Rust Commercial Network（RCN）是 Lori Lorusso 从去年秋天开始主导筹建的项目，源于会员企业的真实诉求：大家想知道彼此在用什么开发框架、什么参考架构，想找到更贴近企业协作习惯的空间，而不是挤在偏工程师文化的项目 Zulip 频道里。特点如下：

• 不需要是付费会员也能加入——通过 GitHub 仓库开 issue 即可申请，门槛很低；
• 治理委员会（Steering Committee）成员结构透明：1 名白金会员、1 名黄金会员、2 名白银会员、1 名准会员代表，外加基金会与项目（David Wood）各一名代表列席；
• 委员会不对具体倡议做强治理，更多是帮各个自发的 initiative（比如 async、Tokio、GUI 相关话题）找到同路人、对接资源；
• 目前维持“一个月一次”的通用例会节奏，避免把会员的日历填满。

RCN 和已经存在多年的技术工作组（比如 Embedded Working Group）之间会不会打架？David Wood 和 Lori Lorusso 的答案是：基本不会。工作组保留自己独立的治理权和 crate 所有权，RCN 更多扮演“引流入口”的角色——把原本不知道某个工作组存在的企业带进来。RCN 目前正在跟进的一个具体案例是 Rust / C++ 互操作（Interop）倡议：技术团队正在推进“函数重载”的实验性支持，让开发者能够在 Rust/C++ 边界上直接声明并调用重载的 C/C++ 函数。该倡议同时也被列为一项正式的 Project Goal。

钱从哪来，花到哪去

基础设施与全职维护者

基金会成立之初（大约五年前）就明确了最优先要投入的方向：基础设施。没有基础设施，Rust 对任何人都无法使用。因此基金会最早的招聘之一就是一名全职基础设施工程师。同理，crates.io 本质上就是 Rust 的一部分，基金会为其配备了全职维护者，避免这类关键但枯燥的工作长期压在无偿志愿者身上。安全维护则受益于外部资金——包括来自美国政府和多家大型科技公司共同发起的 Alpha-Omega 基金，这笔钱让基金会得以聘请专职安全工程师。

维护者基金（Maintainers Fund）与驻场维护者

除全职员工外，基金会设有 Rust Foundation Maintainers Fund，接受企业捐赠，与项目紧密协作决定资金分配。其中一个机制是 Maintainer-in-Residence（驻场维护者）：先以 1—2 年的周期资助某位维护者深耕某个核心方向，一旦证明该工作确实是项目的核心刚需，就有机会把这个人转为基金会正式雇员——腾出的“驻场”名额再滚动资助下一位维护者。这是一套让资助持续“造血”而不是一次性发钱的循环机制。

生态基金（Ecosystem Fund）与定向捐赠

如果企业只是想捐钱，但希望资金精准投向某个具体方向（比如 async 或 embedded），基金会提供生态基金这一通道，通过合同形式定向资助相关方向的维护者。

Project Goals：从“要饭”到“报价”

Lori Lorusso 讲述了一个治理层面的转变：维护者基金启动后，基金会开始反问项目——“你们真正需要什么、想做什么？”于是有了 Project Goals 机制：由项目方主动提出具体的工作目标（需要全职还是兼职、是否需要开发者协作、大概需要多久），并为这些目标标注资金价值。这把过去那种“开源者伸手求赞助”的被动姿态，转变成了“这是我们要交付的成果，需要多少投入”的主动报价。

“开源不是免费啤酒，而是免费小狗”

Lori Lorusso 的表述是：开源的自由（free）从来不是“啤酒免费”（free as in beer）那种零成本，而更像是“免费的小狗”（free as in puppy）——领养不花钱，但你要为它的吃喝拉撒和终身健康持续负责。Rebecca Rumbul 进一步给出一个具体的商业主张：支持 Rust 基金会不应该被当作慈善，而应该是企业的常规经营成本，就像交水电费、付律师费一样，写进公司预算的固定项。

培训与认证：Trusted Trainer

企业采用 Rust 之后，几乎必然会遇到“学习曲线陡峭”的抱怨。基金会没有选择再造一门课程——市面上已经有大量高质量的开源课程（例如 Google 开源的 Rust 课程）——而是发现真正的空白在于“该信谁”。于是基金会推出了 Trusted Trainer（可信培训师）认证计划：审核培训师的教学材料与表达能力，为其提供官方认证的“信任标签”。该计划已于播客录制前一周正式开放申请，首批已有三到四家培训机构获得认证。至于“有了 AI，还需要培训师吗”，Rebecca Rumbul 的回答很实在：目前还没到“AI 可以整体替代优质培训”的阶段。至于“基金会如何看待 AI 生成的 Rust 代码”，她的立场是基金会不预设立场。

Rust 与 Go 的治理结构对比

Go 由 Google 内部工程师于 2007 年设计，2009 年开源，至今没有一个独立于 Google 的语言基金会。Go 的核心决策团队（“Go 团队”）事实上全部由 Google 员工组成，提案流程（Go Proposal Process）虽然公开透明，但最终决策权集中在这个内部团队手中；Go 的域名、部分商标与关键基础设施（如模块代理 proxy.golang.org）也由 Google 直接运营和把控。2023 年，有社区成员在 golang/go 的 issue 中公开提议：Go 应该效仿 Rust 当年脱离 Mozilla 独立成立基金会的路径。对比维度如下：

短期看，Go 依托 Google 单一实体的治理模式效率很高——决策链条短、资源投入稳定。但拉长到十年、二十年来看，脆弱性显而易见：语言的命运本质上绑定在一家公司的战略优先级上。Rust 这套“基金会管钱管地基、项目管语言”的分权结构，看似增加了协调成本，但恰与 Rust“渐进演进、社区共识驱动、强调长期正确性”的工程哲学同构。这套结构能否在语言规模继续增长后保持同样的响应速度，是接下来要观察的。

参考资料：

• 播客原文与音频：Rust in Production - S06E08: Rust Foundation - https://corrode.dev/podcast/s06e08-rust-foundation/
• 本文永久链接：https://tonybai.com/2026/08/12/rust-foundation-explained-governance-and-funding