In 1991, I was working at Lucid Inc., and our newest product, Energize, was an integrated development environment for C and C++ on Unix. The design of this development environment involved very tight integration between the various tools: compilers, linkers, debuggers, graphers, and editors. So of course we needed a powerful editor to tie the whole thing together, and it was obvious to all of us that there was only one editor that would do: Emacs.

At the time, the current version of GNU Emacs from the FSF was Emacs 18. There was another version of GNU Emacs called Epoch, that had been developed by Alan M. Carroll (and later by NCSA). Epoch was a set of patches to Emacs 18 that gave it much better GUI support (Emacs 18 was very much a tty program, with GUI support crudely grafted on as an afterthought.)

For the last few years, Emacs 19 had been due to be released ``real soon now,'' and was expected to integrate the various features of Epoch in a cleaner way. The Epoch maintainers themselves saw Epoch as an interim measure, awaiting the release of Emacs 19.

So, at Lucid we didn't want to tie ourselves to Emacs 18 or on Epoch, because those code bases were considered obsolete by their maintainers. We wanted to use Emacs 19 with our product: the idea was that our product would operate with the off-the-shelf version of Emacs 19, which most people would already have pre-installed on their system anyway. That way, Energize would make use, to some extent, of tools you already had and were already using.

The only problem was, Emacs 19 wasn't done yet. So, we decided we could help solve that problem, by providing money and resources to get Emacs 19 finished.

Even though Energize was a proprietary, commercial product, all of our work on Emacs (and on GCC and GDB) was released under the GPL. We even assigned the copyright on all of our work back to the FSF, because we had no proprietary interest in Emacs per se: it was just a tool that we wanted to use, and we wanted it to work well, and that was best achieved by making our modifications to it be as freely available as possible. (This was one of the earliest, if not the earliest, example of a commercial product being built to a significant extent out of open source software.)

Well, our attempts to help the FSF complete their Emacs 19 project were pretty much a disaster, and we reached the point where we just couldn't wait any longer: we needed to ship our product to customers, and our product needed to have an editor in it. So we bundled up our work on GNU Emacs 19, called it Lucid Emacs, and released it to the world.

This incident has become famous as one of the most significant ``forks'' in a free software code base.

When Lucid went out of business in 1994, and I came to Netscape, I passed the torch for the maintenance of Lucid Emacs to Chuck Thompson (at NCSA) and Ben Wing (at Sun), who renamed it from ``Lucid Emacs'' to `` XEmacs .''

To this day, XEmacs is as popular as FSFmacs, because it still provides features and a design that many people find superior to the FSF's version.

I attribute Lucid Emacs's success to two things, primarily:

First, that my focus was on user interface, and an attempt to both make Emacs be a good citizen of modern GUI desktops, and to make it as easy for new users to pick up Emacs as any other GUI editor;
Second, that I ran the Lucid Emacs project in a much more open, inclusive way than RMS ran his project. I was not just willing, but eager , to delegate significant and critical pieces of the project to other hackers once they had shown that they knew what they were doing. RMS was basically never willing to do this with anybody.

Other things that helped Lucid Emacs's success, but were probably less important than the above:

We gave the users what they wanted first. People had been anticipating Emacs 19 for years, and we stopped dragging our feet and finished it. So this got us a lot of users up front. However, XEmacs's current popularity can't be attributed to this, not since 1993, anyway.
Lucid Emacs was technically superior in many ways. This won us the mindshare of many good developers, who preferred working with Lucid Emacs to FSF Emacs. It would be nice if technical superiority was all that mattered, but realistically, the other factors were probably more important than this one, as far as number of users is concerned.

The following messages, from the Lucid Emacs mailing lists in 1992 and 1993, comprise the bulk (if not the entirety) of the public discussions between the Lucid and FSF camps on why the split happened and why a merger never did.

The current XEmacs maintainers have a much more pusillanimous summary of this history on their XEmacs versus GNU Emacs page.

-- jwz, 11-Feb-2000.

Dramatis Personae:

Richard Stallman: creator of Emacs, founder of the FSF.

Jamie Zawinski: that's me, I did most of the hacking on Lucid Emacs and managed the project. Near the end of my tenure, dozens of people were working on Lucid Emacs on a regular basis, and I reviewed and tested all the code they emailed me, as well as stewarding all the mailing lists. (This was in the days before public CVS servers...)

Richard Mlynarik: prolific contributor to Lucid Emacs: he did almost all of the work of merging changes that were made to the FSF version back into the Lucid version. He was the largest contributor to Lucid Emacs who wasn't actually getting paid to work on it.

Marc Andreessen: you've probably heard of this guy, but you probably didn't know that he used to be one of the maintainers of Epoch at NCSA.

Joseph Arceneaux: the fellow initially employed by both the FSF and by Lucid to hack on Emacs 19, before I started working on it.

Jim Blandy: employed by FSF to hack on their version of Emacs 19, after Arceneaux.

Kyle Jones: author of VM, one of the Emacs mail readers.

Dave Gillespie: author of ``calc,'' a scientific calculator application that runs inside of emacs; calc was hit harder by Lucid Emacs compatibility problems than most other Emacs packages.

I've rearranged the lisp directory so that there are only a handful of files at top-level; everything has been moved to subdirectories. This should speed up the automatic generation of load-path, since it will have to stat() 10x fewer f