最も Emacs Bzr サガ：イデオロギー vs. 実用主義の教訓

ソフトウェア開発の歴史はしばしば技術的ブレークスルーの観点から語られますが、最も示唆に富む物語は技術的停滞のケースです。GNU Emacs の「Bzr サガ」は、プロジェクトのエコシステムへのイデオロギー的コミットメントがツールの性能やコミュニティの受容という実務的現実と衝突したときに何が起こるかを示す典型的な例です。

6 年間にわたり、Emacs 開発コミュニティは客観的に見て競合他者よりも遅く、人気も低いバージョン管理システムに閉じ込められていました。これは政治的決定が技術的ベンチマークを上回り、実用主義へ戻るまでの長く苦しい道のりを描いた物語です。

2008: 政治的選択

2008 年 3 月、Emacs は老朽化した CVS（Concurrent Versions System）からの移行を開始しました。コミュニティは二つの主要候補、Linux カーネルのために Linus Torvalds が作ったパワフルな Git と、Canonical がメンテナンスする GNU プロジェクトの Bazaar (Bzr) の間で分かれました。

技術的観点から見ると、競争はほとんど意味がありませんでした。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 の貢献者は孤立したままでした。彼らは Emacs に貢献するためだけに、他では使われないツールである Bazaar を学ばなければなりませんでした。

この期間は絶え間ない摩擦に満ちていました。メーリングリストは Bazaar を「解除」する助けを求める呼びかけや、メモリリークの疑いに関する報告で溢れました。決定による技術的負債は日々増大し、2012 年に Canonical が Bazaar 開発チームを解雇したことで、プロジェクトの進行は事実上停止しました。

2013: 限界点

2013 年 3 月までに状況は耐え難いものとなりました。John Wiegley は正式に決定の再検討を要求し、Emacs 開発に影響を与える重大なバグ（特に ELPA リポジトリ内）が何年も放置されてきたことを指摘しました。

続く 200 件近いメッセージのスレッドで、「Emacs の皇帝」と保守者たちの緊張は沸点に達しました。Stallman は Bazaar の保守状態について「Yes」の答えを期待していたと認めましたが、実際に Bazaar のメーリングリストを監視して確認する時間がなかったと述べました。

ベテラン OSS 開発者 Karl Fogel はこのアプローチに対し鋭い批判を投げかけました:

"実際のところ、Bzr の開発を十分に注意深く追いかけて、Emacs にとってまだ良い選択肢かどうかを適切に判断する時間がない… では、なぜ今でもこの決定をしっかり行う時間と精神的余裕があると思うのか？"

Stallman の返答は「Emacs 以上のものがここにかかっているからだ」でした。この言葉は、GNU ツールを放棄することがツール自体の非効率性よりも危険なシグナルになるという彼の世界観を浮き彫りにしました。

2014: 移行

デッドロックは実務的失敗と静かな準備の組み合わせで最終的に破られました。2013 年後半、Stefan Monnier は Bazaar が処理できないことから ELPA ブランチを Git に移行しました。これによりプロジェクトは二つのツールを併用するハイブリッド状態となりましたが、Git が唯一の実行可能な道であることが証明されました。

2014 年 8 月、Eric S. Raymond（ESR）は必要な変換スクリプトを静かに開発し、同年 11 月に 200 件の議論ではなく、ESR からの七語のアナウンスでサガは幕を閉じました:

"Commits are open. Have at it."

（訳: 「コミットはオープンです。どうぞ。」）

余波: 時間に追われたコミュニティ

移行は 6 年間の迂回路の真のコストを露呈させました。世界で最も影響力のあるテキストエディタの一つを開発していた多くのコア貢献者は、Git を一度も使ったことがありませんでした。emacs-devel リストは突如として基本的な質問で溢れました: 「Git の良い本は？」、「マージコンフリクトはどうやって起きるのか？」、そして 124 件に及ぶ git pull エラーに関するスレッドなどです。

「Bzr サガ」はプロジェクトリーダーへの警鐘です。イデオロギー的一貫性はコミュニティ構築の強力な動機付けとなりますが、圧倒的な技術的証拠とアクティブな貢献者の嗜好を無視すると、数年かけてしか元に戻せない停滞を招くことになります。