GNU Emacs and Xemacs Schism

Perm url with updates: http://xahlee.org/emacs/gnu_emacs_xemacs_schism_Ben_Wing.html

GNU Emacs and Xemacs Schism, by Ben Wing

Ben Wing, 2001?

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. 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. 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.

Ben Wing

Notes from XahLee.org

This article, was orginially at “http://www.666.com/xemacs/xemacs-split-bens-opinion.htm” as of mid 2000, but is gone as of 2010-06-28. The content is retrived from web.archive.org on 2010-06-28.

The article is probably written in 2001. Because web.archive.org's first archived content of the url is dated 2001-12.

Ben Wing was one of the main developer of Xemacs, after Jamie W Zawinski. However, Ben Wing got Repetitive Strain Injury and i think he exited the programing field in early 2000s. For more detail about this, see: Famous Emacs People With Hand Injuries.

For more detail and resources on history, see Wikipedia: XEmacs. Also, Richard Gabriel, the founder of Lucid Inc, wrote a book named Patterns Of Software, published 1996, which accounts some XEmacs vs GNU Emacs history. I wrote a review in 1998, see: Book Review: Patterns of Software.

See also:

  • Emacs Timeline (1999, 2007), by Jamie Zawinski. jwz.org
  • The Lemacs/FSFmacs Schism (2000), by Jamie W Zawinski. jwz.org
  • XEmacs vs. GNU Emacs, edited by Stephen J Turnbull. xemacs.org

After reading them carefully, you'll see that what's called Emacs, starting with TECMAC and TMACS, are really different software with different implementations, by different people, on different operating systems, for about 5 or more years starting in 1976. When reading about these, you need to put your mind on what computers are like at those times. Typically, a monochrome text terminal, which is capable of displaying some 60 by 40 characters. The typical “editor” at the time operate by modes. That is, you type the command to delete a word, then another command to update the screen to see the word deleted. This is where vi's operation method originated, and also why these emacs editors call themselves as “real-time”, and “DISPLAY” editor, meaning what you typed is updated in real time and in a display, a forerunner concept similar to “what you see is what you get” (WYSIWYG).

I'm guessing that Richard Stallman's GNU Emacs didn't become the main emacs till mid 1980s, Then, Xemacs become widely popular and competitor to GNU Emacs in the 1990s.

All these are before my time. I started using a computer only in 1990. I started to use emacs in 1998 and quickly switched to Xemacs as my choice out of practicality. See: My Experience of Emacs vs XEmacs. But since mid 2000s, Xemacs has fallen due to many reasons. (it'd be too much to write on why, but personally, some reasons are: due to the popularity of Internet/Web in the 1990s together with Apache, Perl, Linux, and the whole Open Source and FSF movement with presses from the mainstream media, Richard Stallman and his works the GNU Emacs gets the prime attention than a “derivative” such as Xemacs, so gradually, GNU Emacs gets more developers, got unicode support, etc, and Xemacs, since long de-coupled with a commercial corporation, just gradually declined.)

It is unfortunate, since Xemacs really is ahead of emacs in many technical ways. However, its semi-dead status is well relfected from its website xemacs.org. Pages there haven't been updated for 5 or 10 years. Its current maintainer, Stephen Turnbull, is a regular participant on GNU Emacs dev forum.

Here's a comprehensive document on Multics Emacs, written by Bernard S Greenberg, around the same time GNU Emacs of Richard Stallman was written. Bernard Greenberg is one of the lispers at the time, who is a founder of Symbolics.

Multics Emacs: The History, Design and Implementation (1996), by Bernard S Greenberg. At multicians.org.

Another founder of Symbolics, Dan Weinreb, has also written a article related to history of the time. Dan is also the author of another emacs at the time, called EINE (EINE Is Not Emacs):

Rebuttal to Stallman's Story About The Formation of Symbolics and LMI (2007-11), by Dan Weinreb. At danweinreb.org

Popular posts from this blog

11 Years of Writing About Emacs

does md5 creates more randomness?

Google Code shutting down, future of ErgoEmacs