最偉大的 Emacs Bzr 史詩：意識形態與務實之間的教訓

軟體開發的歷史常常以技術突破為視角敘述，但有時最具啟發性的故事卻是技術停滯的案例。GNU Emacs 的「Bzr 史詩」正是一個典型範例，說明當對專案生態系的意識形態承諾與工具效能及社群採用的實際情況相衝突時會發生什麼事。

六年之久，Emacs 開發社群被困在一個客觀上較慢且不如競爭者受歡迎的版本控制系統中。這個故事說明了政治決策如何凌駕技術基準，以及回歸務實的漫長且痛苦的道路。

2008：政治抉擇

2008 年 3 月，Emacs 開始從老舊的 CVS（Concurrent Versions System）遷移。社群在兩個主要候選者之間分裂：由 Linus Torvalds 為 Linux 核心打造的 Git，與由 Canonical 維護的 GNU 專案 Bazaar（Bzr）。

從技術角度看，這場競爭根本不是比賽。emacs-devel 郵件列表上的開發者執行了基準測試，結果顯示出驚人的效能差距。一位核心開發者 Andreas Schwab 指出 bzr log 慢到「完全無法使用」，而 David Kastrup 則觀察到 git log 幾乎是即時的。

數據相當明顯：

儘管有這些結果，Richard Stallman（RMS）仍決定使用 Bazaar。他的理由不是技術層面，而是哲學層面：「這個問題已經結束並且決定了。我們將使用 GNU Bzr，因為它是 GNU 套件。」

Stallman 主張 GNU 專案必須支援自己的工具，以維持自給自足的自由軟體生態系。當批評者指出此決策忽視了所有技術論點時，Stallman 堅持 GNU 套件相互支援的規則能讓整個系統運作得更好。決策已成定局，社群被迫適應。

當其他軟體世界陸續遷移到 Git，且 GitHub 爆炸式成長時，Emacs 貢獻者仍被孤立。他們被迫學習 Bazaar——一個在其他地方根本不會使用的工具——僅僅是為了對 Emacs 做出貢獻。

這段期間充斥著不斷的摩擦。郵件列表上充斥著求助訊息，請求「解除」 Bazaar 的卡住狀況，或是報告疑似記憶體洩漏。決策所帶來的技術債務每日累積，最終在 2012 年 Canonical 裁撤了 Bazaar 開發團隊，實質上使專案的進展陷入停滯。

到 2013 年 3 月，情況已無法持續。John Wiegley 正式請求重新審視此決策，指出影響 Emacs 開發的重大錯誤——尤其是 ELPA 套件庫——已被忽視多年。

在隨後的 200 篇訊息討論串中，「Emacs 大帝」與維護者之間的緊張關係達到沸點。Stallman 承認他期待得到關於 Bazaar 維護狀態的「是」答案，但他沒有時間實際監控 Bazaar 的郵件列表以驗證此事。

資深開源開發者 Karl Fogel 對此做出了尖銳批評：

"好吧，說真的，你根本沒時間仔細關注 Bzr 的開發，以至於無法勝任判斷它是否仍是 Emacs 的好選擇… 那麼你為什麼還認為自己有時間與精神容量來做好這個決策呢？"

Stallman 的回應——「因為不只是 Emacs 本身」——凸顯了他的世界觀。對他而言，拋棄 GNU 工具所發出的訊號比工具本身的低效更具危險性。

僵局最終在實務失敗與悄悄的準備下崩解。2013 年底，Stefan Monnier 將 ELPA 分支遷移至 Git，因為 Bazaar 完全無法處理。這創造了一個混合狀態，專案同時使用兩種工具，但也證明 Git 是唯一可行的道路。

到 2014 年 8 月，Eric S. Raymond（ESR）已悄悄開發出必要的轉換腳本。2014 年 11 月，史詩以 ESR 的七字宣告結束，而非再度展開 200 篇的辯論：

"Commits are open. Have at it."

遷移揭示了六年繞路的真實代價。許多核心貢獻者——他們一直在開發全球最具影響力的文字編輯器——從未使用過 Git。emacs-devel 列表瞬間被基礎問題淹沒："Git 好書推薦？"、"合併衝突怎麼會發生？"，以及一個長達 124 篇的討論串，討論一個鮮為人知的 git pull 錯誤。

「Bzr 史詩」成為專案領導者的警示故事。雖然意識形態的一致性是社群建設的強大動力，但忽視壓倒性的技術證據與活躍貢獻者的偏好，會導致長時間的停滯，且需要多年才能彌補。