1999 年 4 月，自由软件基金会（FSF）将 GCC 的维护职责交给了一个从 GCC 分出去的项目的指导委员会。这个项目叫 EGCS，未来的开发流程、CVS 代码仓库和版本发布团队都将由它带回 GCC。[5] 这次交接在开源治理史上格外耐人寻味：贡献者在别处建立了一套工作方式，原项目最终将其接纳。

值得追问的是，EGCS 如何赢得了足够的信任，得以接下这份职责。历史记录里有编译器的新功能，也有一些较少引人注目的变化：补丁有了提交的去处，合入过程可以追踪，谁有权作出决定也有了公开说明。

为汇合各个分支而生的分支

1997 年 8 月 15 日的公告用了一个出人意料的标题：“一个合并现有 GCC 分支的新项目”。David Henkel-Wallace 在文中描述，一些开发者经过多年努力，改进代码依然留在 GCC2 代码树之外。他承认 FSF 对稳定性的重视，同时指出，各条开发线越走越远，协作也日益困难。[1]

这份声明呈现了发起者如何理解这场争议，对遭拒补丁的评价也应放在这一立场下理解。声明提出的具体做法很清楚：将各方工作汇入一个更具实验性的项目，同时保留与 GCC2 的联系。代码版权仍将转让给 FSF，代码也会提交给 GCC2 的维护者。两个社区的人员会有交集，其中一些人将同时为两边维护语言前端。[1]

EGCS 起步时面对的，首先是整合问题。贡献者手里已经有了代码，他们需要一个能将这些代码汇到一起的地方。独立的开发树为他们留出了另行安排优先事项的空间，GCC2 也可以按自身节奏决定何时接纳各项实验。

发布版本，让承诺接受检验

EGCS 1.0 于 1997 年 12 月 3 日发布。它整合了 GNU Fortran 编译器、包括 SGI 标准模板库（Standard Template Library）在内的 C++ 运行时库、新的指令调度器，以及新的别名分析代码。这个版本基于 GCC 2.8 的一个开发快照。[2]

这些成果让项目的吸引力变得具体。开发者下载一个版本，就能试用汇集了多个社区成果的编译器。项目也明确将实验性功能的广泛测试列为目标。[2]

同一份版本记录也留下了代价。libgcc 中异常处理接口的变化，给分别使用 EGCS 1.0 和 GCC 2.8.0 编译的 C++ 共享库带来了潜在的兼容性问题。EGCS 1.0.1 改用新接口生成代码，同时为新旧两种接口配备了支持例程；项目敦促共享库发行者升级。[2]

这段经历为成功的故事划出了重要的限度。即便源码同出一脉，各自演进的二进制程序能否协同运行，仍要经过检验。分支项目要赢得信任，除了开发功能，还得修复问题、做好兼容。

让工作过程公开可见

随着版本陆续发布，EGCS 的公共基础设施也逐渐完善。项目的新闻档案记载，1998 年 1 月，CVS 源码已可远程访问。5 月，项目宣布设立两个邮件列表：gcc-cvs 用于自动发送代码提交通知，egcs-patches 用于接收补丁。设立后者的明确原因，是防止补丁淹没在主邮件列表的大量消息中。同年 11 月，在线测试结果数据库也投入使用。[3]

这些变化分别补上了协作中的不同缺口。开放仓库访问，让参与者拿到持续更新的代码；自动通知，让每次改动有迹可循；专门的补丁提交渠道，将待审改动与一般讨论分开；测试结果则为协作者提供了判断依据，让他们看清不断演进的代码究竟能做到什么。

在我看来，这些日常服务也是 EGCS 治理成果的一部分。贡献者能看见一项改动正在哪个环节等待、被接纳后又发生了什么，参与规则才更有用处。

一个职责明确的委员会

1998 年 11 月 10 日，EGCS 公开确立了指导委员会的正式地位。公告介绍，此前已有一个由不同背景、不同社区的成员组成的非正式小组，设立委员会的用意，是防止任何个人或公司独自控制项目。委员会负责重大决策，并维护项目原则。[4]

GCC 的指导委员会页面至今仍保留着这一身份区分：成员以个人身份任职，页面列出的雇主并无相应席位。该页面还说明，委员会设立时希望涵盖 Fortran 用户、嵌入式开发者、内核开发者等群体的利益。[4]

这种安排体现了一项制度设计选择，影响力是否完全均衡，还需实际运作中的证据。个人成员制之下，贡献者是否都能平等参与、争议是否都能得到妥善处理，也仍待考察。不过，它确实提出了一项可以检视的具体承诺：雇主的投入与委员会席位的所有权，在制度上是两回事。

回到 GCC 的是什么

Richard Stallman 在 1999 年 4 月的公告中明确了交接事项。更名后的 GCC 指导委员会以集体身份承担 GNU 维护者职责，负责接纳改动、修复问题和发布版本。委员会任命发布负责人处理日常技术事务，当时担任这一职务的是 Jeff Law。EGCS 的开发流程将大体延续，其 CVS 仓库也将成为 GCC 的仓库。[5]

7 月 31 日发布的 GCC 2.95，是重新合流后的首个版本。发布公告还解释了扩展后的名称：GNU Compiler Collection，即 GNU 编译器集合，体现其支持的语言已经超出 C 语言。[6] 至此，组织层面的交接有了可供下载的成果。

当时的报道也帮助我们看清这次合流的范围。LWN 在 4 月 22 日的开发报道中欢迎双方重新合流，同时提到，专门面向 Pentium 处理器的 pgcc 仍将独立发展。[7] GCC 与 EGCS 走到一起后，专门用途的编译器项目仍然存在。

GCC 日期标为 2021 年 6 月 1 日的使命声明，明确写下了延续至今的承诺：开放的邮件列表、多位维护者、公开可获取的代码，以及按技术价值评估补丁。[8] 这份文件描述了项目希望遵循的流程；实际执行是否始终如一，还需另行考察。

EGCS 的经历给评估分支项目留下了更具体的尺度：看谁在做整合，测试留下了哪些证据，以及谁有权将已经接纳的改动组织成正式版本。1999 年的 GCC 能够接纳 EGCS，是因为 EGCS 已经有了一套运转中的开发组织。随代码一同回归的，还有这套组织积累的工作习惯。

资料来源

1. David Henkel-Wallace，《EGCS 项目最初公告》，1997 年 8 月 15 日——发起者对分歧的解释及合作提议。
2. GCC 项目，《EGCS 1.0》——发布日期、整合的功能，以及 1.0.1 对异常处理兼容性问题的修复。
3. GCC 项目，《GCC 新闻与公告》——1998 年 1 月、5 月和 11 月的基础设施建设记录。
4. GCC 项目，《GCC 指导委员会》——1998 年 11 月 10 日的原始公告，以及成员以个人身份任职的说明。
5. Richard Stallman，《GCC 的新维护团队》，消息日期为 1999 年 4 月 15 日，由 LWN 保存——维护职责、代码仓库及开发流程的移交。
6. GCC 项目，《GCC 2.95》——重新合流后于 1999 年 7 月 31 日发布的版本，以及 GNU Compiler Collection 这一名称。
7. LWN，《开发工具》，1999 年 4 月 22 日——“Gcc/egcs”一节中的同期独立报道与评价。
8. GCC 项目，《GCC 开发使命声明》，2021 年 6 月 1 日——公开发布的参与及开发原则。
9. Bradley M. Kuhn，《Bradley M. Kuhn 照片集》——2001 年 6 月 28 日在 USENIX 与 David Edelsohn 同框的照片。