The Emacs Bazaar Saga: A Tale of Principles, Performance, and Persistence

---

Thesis

The prolonged Emacs version‑control saga demonstrates how steadfast adherence to ideological purity can clash with the practical demands of a large, evolving codebase, ultimately forcing a community to prioritize usability and maintainability over symbolic consistency.

---

Key Arguments

1. The initial technical showdown was starkly one‑sided.

Benchmarks posted on emacs-devel in March 2008 showed Git completing a log operation in 0.012 s while Bazaar required 21.5 s; a single‑file commit took 0.08 s with Git versus 17 s with Bazaar. These numbers, repeated across multiple contributors, underscored a performance gap that could not be ignored for a project of Emacs’ size.

2. Ideological considerations overrode the data.

Richard Stallman invoked the “GNU‑packages‑support‑each‑other” principle, arguing that adopting Bazaar, a GNU‑licensed tool, reinforced the self‑sufficient free‑software ecosystem. Even when confronted with concrete speed complaints, he maintained that waiting for Bazaar improvements was preferable to a “temporary” switch to Git.

3. Bazaar’s development stalled, amplifying the problem.

Canonical’s 2012 layoffs effectively halted Bazaar’s active maintenance. Open bugs—most notably the ELPA branch failure—remained unresolved for years, forcing Emacs developers to work around a tool that was both slow and unmaintained.

4. Community fatigue manifested in endless support requests.

Threads such as “Help me unstick my bzr” and “Can NOT bzr the emacs repos” proliferated, consuming volunteer time that could have been spent on feature development. The cost of maintaining expertise in a niche VCS became a measurable barrier to new contributors.

5. Leadership eventually prioritized practicality.

Stefan Monnier’s 2013 decision to move the ELPA branch to Git, despite personal reluctance, highlighted a pragmatic shift: if Git could handle a critical sub‑project, why not the whole repository? Eric S. Raymond’s later migration scripts and his terse “Commits are open. Have at it.” message marked the final, decisive move.

---

Implications

1. Technical debt can outweigh philosophical consistency. The Emacs case shows that prolonged reliance on an underperforming tool can accrue hidden costs—training, debugging, and lost contributor time—that eventually force a break with ideology.
2. Open‑source governance needs delegated evaluation. Stallman’s admission that he lacked the bandwidth to monitor Bazaar’s health underscores the danger of centralized decision‑making without delegated expertise.
3. Migration pathways matter. ESR’s preparation of conversion scripts illustrates the importance of low‑friction migration tooling; without it, even a clear decision can stall.
4. Community health is tied to tooling ergonomics. The flood of Git‑help requests after the switch revealed that many core Emacs contributors had never used Git, yet they adapted quickly once the barrier of Bazaar was removed, suggesting that modern VCS ergonomics can lower entry thresholds for contributors.

---

Counter‑Perspectives

• Principle‑first argument: Some argue that abandoning a GNU‑licensed tool sets a precedent that could weaken the GNU ecosystem’s cohesion. From that view, the symbolic loss of Bazaar may be seen as a concession that could embolden other projects to adopt non‑GNU tools.
• Performance‑only focus: Critics might claim the benchmarks were cherry‑picked or that Bazaar could be tuned to approach Git’s speed, especially given the possibility of hardware improvements or caching strategies.
• Legacy‑maintenance concern: Switching VCS mid‑project introduces migration risk—history integrity, build scripts, and CI pipelines must be updated. For a project as long‑standing as Emacs, that risk is non‑trivial.

---

Conclusion

The Emacs Bazaar saga is a microcosm of a broader tension in free‑software development: the desire to stay ideologically pure versus the imperative to keep the codebase accessible, performant, and maintainable. While the eventual migration to Git was driven by concrete performance failures and a stagnant upstream, the journey also exposed governance shortcomings and highlighted the need for flexible, delegated decision‑making. In the end, the community’s willingness to confront hard trade‑offs ensured that Emacs could continue evolving without being held back by an obsolete tool.

---