4. The XEmacs Split

Author: Ben Wing

Ben Wing’s attempts

Nota bene: The following is a highly opinionated piece written by one of the main authors of XEmacs. This reflects his opinions, and his only! It is included here because it may help to clarify some of the issues that are keeping the two versions of Emacs separate.

Many people look at the split between GNU Emacs and XEmacs and are convinced that the XEmacs team is being needlessly divisive and just needs to cooperate a bit with RMS, and the two versions of Emacs will merge. In fact there have been six to seven major attempts at merging, each running hundreds of messages long and all of them coming from the XEmacs side. All have failed because they have eventually come to the same conclusion, which is that RMS has no real interest in cooperation at all. If you work with him, you have to do it his way – “my way or the highway”. Specifically:

1. RMS insists on having legal papers signed for every bit of code that goes into GNU Emacs. RMS’s lawyers have told him that every contribution over ten lines long requires legal papers. These papers cannot be filled out over to the web but must be done so in person and mailed to the FSF. Obviously this by itself has a tendency to inhibit contributions because of the hassle factor. Furthermore, many people (and especially organizations) are either hesitant to or refuse to sign legal papers, for reasons mentioned below. Because of these reasons, XEmacs has never enforced legal signed papers for the code in it. Such papers are not a part of the GPL and are not required by any projects other than those of the FSF (for example, Linux does not require such papers). Since we do not know exactly who is the author of every bit of code that has been contributed to XEmacs in the last nine years, we would essentially have to rewrite large sections of the code. The situation however, is worse than that because many of the large copyright holders of XEmacs (for example Sun Microsystems) refuse to sign legal papers. Although they have not stated their reasons, there are quite a number of reasons not to sign legal papers:
   • By doing so you essentially give up all control over your code. You can no longer release your code under a different license. If you want to use your code that you’ve contributed to the FSF in a project of your own, and that project is not released under the GPL, you are not allowed to do this. (This is supposed to be avoided by the standard assignment contract used by the FSF, which either automatically relicenses the code to the author for any purpose under any license, or promises to do so, depending on the version – stephen.) Obviously, large companies tend to want to reuse their code in many different projects and as a result feel very uncomfortable about signing legal papers.
   • One of the dangers of assigning copyright to the FSF is that if the FSF happens to be taken over by some evil corporate identity or anyone with different ideas than RMS, they will own all copyright-assigned code, and can revoke the GPL and enforce any license they please. (This is false, according to RMS; the FSF’s covenants and the assignment contracts require that it or any successors may release the code only under copyleft. Thus, the only real loophole is if the FSF goes bankrupt, somehow leaving the code in the public domain – stephen.) If the code has many different copyright holders, this is much less likely of a scenario.
2. RMS does not like abstract data structures. Abstract data structures are the foundation of XEmacs and most other modern programming projects. In my opinion, is difficult to impossible to write maintainable and expandable code without using abstract data structures. In merging talks with RMS he has said we can have any abstract data structures we want in a merged version but must allow direct access to the implementation as well, which defeats the primary purpose of having abstract data structures.
3. RMS is very unwilling to compromise when it comes to divergent implementations of the same functionality, which is very common between XEmacs and GNU Emacs. Rather than taking the better interface on technical grounds, RMS insists that both interfaces must be implemented in C at the same level (rather than implementing one in C and the other on top if it), so that code that uses either interface is just as fast. This means that the resulting merged Emacs would be filled with a lot of very complicated code to simultaneously support two divergent interfaces, and would be difficult to maintain in this state.
4. RMS’s idea of compromise and cooperation is almost purely political rather than technical. The XEmacs maintainers would like to have issues resolved by examining them technically and deciding what makes the most sense from a technical prospective. RMS however, wants to proceed on a tit for tat kind of basis, which is to say, “If we support this feature of yours, we also get to support this other feature of mine.” The result of such a process is typically a big mess, because there is no overarching design but instead a great deal of incompatible things hodgepodged together.

If only some of the above differences were firmly held by RMS, and if he were willing to compromise effectively on the others and to demonstrate willingness to work with us on the issues that he is less willing to compromise on, we might go ahead with the merge despite misgivings. However RMS has shown no real interest at all in compromising. He has never stated how all of the redundant work that would be required to support his preconditions would get done. It’s unlikely that he would do it all and it’s certainly not clear that the XEmacs project would be willing to do it all, given that it is a tremendous amount of extra work and the XEmacs project is already strapped for coding resources. (Not to mention the inherent difficulty in convincing people to redo existing work for primarily political reasons.) In general the free software community is quite strapped as a whole for coding resources; duplicative efforts amount to very little positively and have a lot of negative effects in that they take away what few resources we do have from projects that would actually be useful.

RMS however, does not seem to be bothered by this. He is more interested in sticking firm to his principles, though the heavens may fall down, than in working forward to create genuinely useful software. It is abundantly clear that RMS has no real interest in unity except if it happens to be on his own terms and allows him ultimate control over the result. He would rather see nothing happen at all than something that is not exactly according to his principles. The fact that few if any people share his principles is meaningless to him.

Jamie Zawinski’s attempts

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 at NCSA, which 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 Lucid Emacs Split.

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

– jwz, 11-Feb-2000.

This document was generated by Aidan Kehoe on December 27, 2016 using texi2html 1.82.