新选技术委员会、提交权限移交通常会被视为治理变动；R 在 2026 年给出的最强信号，却是一项有资金支持的尝试：让更多人有能力完成一次提交发生前的必要工作，包括重现 bug、准备一份目标明确的补丁、完成跨平台测试、审查他人的改动，并把讨论推进到足以让 R Core 开发者作出可靠判断的位置。

英国 Research Software Maintenance Fund（研究软件维护基金）向一项为期 24 个月、名为 Enabling the Next Generation of Contributors to R（“助力 R 的新一代贡献者”）的项目拨款 £499,981.21。计划内容包括由导师带领一批有专长的贡献者、更新开发基础设施、扩大参与范围、改善沟通、制定适用于整个项目的行为准则，以及就 R Foundation 的组织与选举提出改革方案。[1][2]

这些目标之所以同处一项计划，是因为 R 的延续难题远比“再找一位维护者”复杂。权力与工作分散在彼此交叠的群体中。R Core 掌控官方 base-R 源码；R Foundation 提供法律、财务与公共事务上的归属；CRAN 团队管理软件包仓库，而多数用户正是通过这个仓库接触整个 R 软件体系。不少人跨组任职，各机构承担的工作仍然不同。接班计划若把这些界线抹平，R 的治理会更难读懂。这项计划值得关注之处，正在于它拓宽贡献者通道，同时把既有权责界线留在明处。

配图说明：封面记录 useR! 2013 与会者在卡斯蒂利亚-拉曼恰大学外的合影。它以纪实影像呈现 R 周围聚集的人群规模，比用一个标志代指社区更具体。治理问题在于，如何让这群庞大的用户与软件包开发者中的一部分人，积累审查和维护规模小得多的 base 系统所需的经验。[8]

写入权限是最后一步，起点在此前

base R 仍保留着一条刻意收窄的写入边界。R 于 2026 年 3 月发布的软件开发生命周期文件说明，官方 Subversion 仓库实施访问控制，只有 R Core 成员可以写入。文件把 release branch 与 development branch 分开：前者接收 bug 修复和小幅功能增强，主要功能则进入后者。指定发布经理在测试完成后批准版本发布。文件范围仅涵盖 base R 及其随附的推荐软件包，CRAN 托管的其他附加软件包位于范围之外。[4]

公开贡献通道覆盖更多人，GitHub pull request 仍需经过人工流程。《R Development Guide》要求外部贡献者基于当前开发源码工作，运行 make check-devel，生成目标明确的 svn diff，再通过 Bugzilla 提交补丁。GitHub 镜像可以在多种配置与操作系统上检查拟议改动；由此产生的 diff 仍要回到补丁流程接受审查，最后由核心开发者决定接受或拒绝。[3]

这种设计具有合理的安全特性。在取得生产写入权限以前，贡献者已经可以提供证据。重现故障、增加回归测试、检查可移植性或审查补丁，都能减少合并者面对的不确定性。只按新增提交者人数衡量接班进展，会把问题危险地简化。即使提交者名单变长，项目仍会缺少愿意或有能力审查解释器、内存管理、平台、数值计算或兼容性边界变更的人。

R 自己的指南直接点出眼前约束：代码审查不足构成瓶颈，许多 issue 已经附有拟议修复，现有人员中却没有人仅受雇于审查工作。指南鼓励贡献者测试补丁并留下意见，即使他们还给不出完整审查；这样一来，经验丰富的开发者便能把稀缺注意力留给只有他们才能判断的细节。[3]

三套机构共同塑造一种用户体验

“R 治理”很容易被误读，因为用户通常只看到一条下载命令和一个软件包名称。在其下方，至少有三套责任体系彼此交会。

R Core 负责 base-R 的整合与发布。其成员持有写入权限，维护 release 与 development 两条分支，并决定外部补丁能否进入源码。新一代贡献者队伍可以为这条技术信任边界分担工作，队伍成员身份本身不会自动带来这项权限。[3][4]

R Foundation 治理一个协会。基金会章程规定，其职责包括支持 R 持续开发、运营通信与分发基础设施、持有并管理版权、组织活动，以及充当正式的公共发声机构。普通会员组成基金会最高权力机构，缴费的支持会员不列入其中；普通会员选举理事会、批准账目、确定会费并修订章程。[5] 基金会由此成为实质治理机构，base R 的合并权限仍归 R Core，不能把会员大会随手写成这项权限的持有者。

CRAN 负责仓库准入与持续分发。其政策说明，这是一个由志愿者运营、同时得到 R Foundation 与雇主资源支持的软件包仓库。政策要求软件包达到发布品质、代码必须可移植、具名维护者能够取得联系，并要求软件包接受当前 R 的检查，妥善处理反向依赖。新 R 版本发布后检查失败的软件包，或长期无人维护的软件包，都可由团队归档；CRAN 还自行构建所分发的 Windows 与 macOS 二进制文件。[6] 软件包作者面对这道关口时的关系，与贡献者面对 base-R 源码树时的关系属于两套流程。

这些群体在人员上互有重叠，相关背景也随人员在群体间流动。重叠同时带来 bus factor 风险：同一个人会以不同身份承担核心开发、平台工作、CRAN 检查和基金会事务。机构数量若脱离任务归属来统计，韧性就会被高估。

旧模型擅长日常运转，人员更新留下难题

这里有一则有用的历史警示。社会学家 John Fox 在 2009 年发表了一项研究，访谈对象覆盖当时 R Core 团队的大多数成员。他笔下的正式组织较为扁平，分工大体自然生长。常规发布、渐进改进和 bug 修复，可以依靠专业知识与“修正式共识”推进；争议较大的新方向更难处理，共识未能形成时，有时便没有行动。[7]

那篇文章属于历史资料，不能直接当作今天的组织图。不过，其中揭示的运作方式依然解释了贡献者接班为何属于治理工作。依赖默会知识的职责归属，在负责人仍然在岗时效率很高；到了交接阶段，角色从未得到完整说明，转移便会变得困难。相关知识包括某个平台的工具链、纵横交错的软件包依赖、辨别数值回归与有意改动所需的判断力，以及协调一次发布所需的人际关系。

文档可以降低入门成本，判断力仍要在实践中传递。活动创造接触，持续审查要靠长期协作。资金可以买下专注工作的时间，治理正当性则要另行建立。新计划把这些环节接在一起：由有经验的核心开发者指导一支专家型队伍；队伍承担维护和 bug 分类；贡献者活动与指南继续开展；基础设施实验则尝试缩短感兴趣的外部人士与一项可供审查的改动之间的距离。[2]

以队伍为接班单元，胜过“一个人学会一个子系统”。队伍成员可以互相审查，把隐性流程写清，并让多人都能诊断同一类故障。这样，在职位空缺迫使团队仓促移交以前，冗余已经建立。

改革仍是提案，权力交接尚未发生

计划还准备测试范围更广的变化：替代开发平台、讨论功能增强提案的流程、R Core 与更广泛社区之间更强的沟通，以及 R Foundation 的新组织架构与现代化选举程序。[2] 这里的时态不能忽略。这些仍是计划中的实验与提案。拨款本身证明项目已正视延续难题；新章程、选举流程或技术决策体系仍待后续实施。

资金投入扩大的是参与通道，base-R 合并权限仍沿既有信任边界分配。更容易进入的通道为更多补丁创造条件；功能增强提案流程可让大型改动的理由留下可查记录；更广的审查者队伍有助于提高处理量，让专业知识分布到更多人。以上变化与继续受限的写入权限可以并存。CRAN 仓库决策、基金会选举与 R Core 技术权限也仍应各归其位。

资助期限本身构成另一条界线。R 项目发布的公告明确说明，这笔资金属于短期资助，长期可持续性仍需要多元收入来源。[2] 两年可以建立一支队伍并试验流程，却无法证明项目结束以后，审查工作、社区协调与基金会行政仍有经费。

什么样的结果才算持久信号

有意义的结果会显现在交接里，公告本身分量有限。

第一，外部贡献者应当能够依据公开说明，从可复现报告推进到经过测试的补丁与实质审查。衡量时应看能够走完整套兼容性与审查流程的改动，原始 issue 流量只提供背景数据。

第二，审查应被承认为一种贡献，背后还要有足够的资助时间或机构支持。如果队伍产出补丁的速度超过资深审查者的评估速度，队列只是换了位置，瓶颈仍在。

第三，拟议治理流程应当写明一项决定止于何处。功能增强流程需要一条通往技术接纳的明确路线。基金会选举改革需要说明它改变了基金会的哪些权力。行为准则需要指定报告与执行机构。组织图再整洁，也替代不了清楚的职责衔接。

最后，这些工作在资助结束后需要一个持续维护的归属。文档、CI、贡献者活动与导师安排，一旦负责人又只能使用没有报酬的业余时间，都会逐渐失修。持久的成果会为每项新流程配上明确的维护负责人、预算来源，以及更替当前负责人的办法。

对于依赖 R 的工程团队，这项变化的实践含义清楚，也有明确界线。base R 保持保守的整合与发布流程；CRAN 继续在整个仓库范围内执行可移植性与反向依赖规范；基金会可以为共享工作提供资金和组织归属。新的信号在于，R 正把资金直接投向庞大用户社区与狭窄源码写入边界之间的人员。

接班正是从这一层开始。一名新维护者若先用数月重现、测试、审查、记录并积累背景知识，再接手时风险最低；等到空缺突然等着填上一个名字，风险已经集中在交接瞬间。R 的 24 个月计划若能让这些准备性角色更容易加入、可以持续，并在资助结束后继续运转，才称得上治理改革。

来源

1. Software Sustainability Institute，“RSMF Round 1 Projects”——资助金额、24 个月期限、团队、拟议贡献者通道、治理工作与基础设施现代化。
2. Heather Turner，“RSMF: Enabling the Next Generation of Contributors to R”，The R Blog，2025 年 12 月 17 日——计划设计、导师制队伍、贡献基础设施、沟通、基金会改革方案与短期资助界线。
3. R Contribution Working Group，“Lifecycle of a Patch”，R Development Guide——外部补丁流程、测试、审查瓶颈、Git 镜像检查、Bugzilla 提交与核心开发者接纳。
4. R Foundation，R: Software Development Life Cycle，2026 年 3 月 12 日——源码写入权限、分支职责、发布管理、测试、基础设施与文件范围。
5. R Foundation，Statutes of The R Foundation for Statistical Computing，2025 年 11 月 17 日——目标、会员制度、会员大会权力、理事会职责、版权、基础设施与公共代表。
6. CRAN Repository Maintainers，“CRAN Repository Policy”——志愿者运营方式、提交要求、可移植性、检查、反向依赖、归档与二进制分发。
7. John Fox，“Aspects of the Social Organization and Trajectory of the R Project”，The R Journal，2009 年 12 月——基于访谈的独立分析，讨论 R Core 的扁平组织、分工、共识与人员更新风险。
8. useR! 2013 organizers，“The R User Conference 2013”——大会官方记录，以及本文所用 Benno Pütz 集体照的来源说明页。