最具争议的 Emacs Bzr 传奇：意识形态 vs. 实用主义

软件开发的历史常常通过技术突破的视角来叙述，但有时最具启发性的故事恰恰是技术停滞的案例。GNU Emacs 的 “Bzr 传奇” 正是一个典型示例，展示了对项目生态系统的意识形态坚持如何与工具性能和社区采纳的实际情况冲突。

在长达六年的时间里，Emacs 开发社区被困在一个客观上比竞争对手更慢、更不流行的版本控制系统中。这是一个政治决定压倒技术基准、以及漫长而痛苦的回归实用主义之路的故事。

2008: 政治选择

2008 年 3 月，Emacs 开始从老旧的 CVS（Concurrent Versions System）迁移。社区在两个主要竞争者之间出现分歧：Git——由 Linus Torvalds 为 Linux 内核创建的强大工具，以及 Bazaar（Bzr），一个由 Canonical 维护的 GNU 项目。

从技术角度来看，竞争几乎没有悬念。emacs-devel 邮件列表上的开发者进行的基准测试显示出惊人的性能差距。一位核心开发者 Andreas Schwab 指出，bzr log 慢得“完全不可用”，而 David Kastrup 则观察到 git log 几乎是瞬时完成的。

数据十分直观：

• git log | head -1：0.012 秒 vs. Bazaar：21.5 秒。
• 单文件提交：Git 为 0.08 秒，Bazaar 为 17 秒。

尽管结果如此，Richard Stallman（RMS）仍决定使用 Bazaar。他的理由并非技术层面，而是哲学层面：“这个问题已经决定。我们将使用 GNU Bzr，因为它是 GNU 包。”

Stallman 认为 GNU 项目必须支持自己的工具，以维持一个自给自足的自由软件生态系统。当批评者指出此决定忽视了所有技术论据时，Stallman 坚持认为 GNU 包相互支持的规则有助于整体系统更好地运作。决定已成定局，社区被迫适应。

2008–2012: 摩擦的漫长尾巴

当整个软件世界迁移到 Git，GitHub 的人气爆炸式增长时，Emacs 贡献者仍被孤立。他们被迫学习 Bazaar——一个在其他地方根本用不到的工具，仅仅是为了为 Emacs 做贡献。

这段时期充斥着持续的摩擦。邮件列表里充斥着求助信息，要求“解卡” Bazaar，或报告疑似内存泄漏。技术债务日益累积，直至 2012 年 Canonical 裁员 Bazaar 开发团队，项目进展基本停滞。

2013: 临界点

到 2013 年 3 月，局面已不可持续。John Wiegley 正式请求重新审视这一决定，指出影响 Emacs 开发的重大 bug——尤其是 ELPA 仓库中的 bug——已被忽视多年。

在随后长达 200 条信息的讨论中，“Emacs 大帝”与维护者之间的紧张关系达到了沸点。Stallman 承认他希望得到关于 Bazaar 维护状态的“是”答复，但他没有时间实际监控 Bazaar 邮件列表以验证这一点。

资深开源开发者 Karl Fogel 对此做出了尖锐批评：

“说真的，你根本没有时间足够关注 Bzr 的开发，以便胜任地判断它是否仍然是 Emacs 的好选择……那你为什么还认为自己有时间和精力做出这个决定？”

Stallman 的回应——“因为不仅仅是 Emacs 的利益受到影响”——凸显了他的世界观。对他而言，放弃 GNU 工具所发出的信号比工具本身的低效更具危害性。

2014: 迁移

僵局最终在实际失败与悄然准备的双重作用下被打破。2013 年后期，Stefan Monnier 将 ELPA 分支迁移到 Git，因为 Bazaar 根本无法胜任。这导致项目出现了使用两种不同工具的混合状态，但也证明 Git 是唯一可行的道路。

到 2014 年 8 月，Eric S. Raymond（ESR）悄悄完成了必要的转换脚本。2014 年 11 月，这段传奇没有以另一场 200 条信息的辩论收场，而是以 ESR 的七字声明结束：

“Commits are open. Have at it.”

余波：一个失去时间的社区

迁移揭示了六年绕行的真实代价。许多核心贡献者——他们一直在开发世界上最具影响力的文本编辑器之一——从未使用过 Git。emacs-devel 列表瞬间被基础问题淹没：“Git 的好书推荐？”、“合并冲突怎么会出现？”以及一条长达 124 条信息的关于罕见 git pull 错误的讨论。

“Bzr 传奇”为项目负责人敲响了警钟。意识形态的一致性固然是社区建设的强大动力，但忽视压倒性的技术证据和活跃贡献者的偏好，会导致停滞，且需要多年才能恢复。