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.