Re: XEmacs at a crossroads

   > Raymond Toy writes:

   > Unfortunately, it does.  There are moral (and possibly legal) risks to
   > running an unmonitored archived list (X- headers, keywords, and HTML
   > comments are known vectors for communicating stolen credit card
   > numbers and the like).  Somebody has to monitor the postmaster
   > address.  Somebody has to pay for the domain registration.  Etc, etc.

   > In any case, it's not going to stop soon.


   > Oh, it's definitely technically viable.  People fork Emacs all the
   > time, on GitHub etc.  I think some XEmacs features would be added, or
   > replace the GNU equivalents, very quickly.  For example adding native
   > widgets to lwlib.  It wouldn't be the XEmacs we know and love today,
   > but it wouldn't be "Emacs", either.  It doesn't have to be *all* of
   > XEmacs.

   > The question would be social viability.  We can't know until we try
   > it.  I admit the risks are great, the probability of much success not
   > so high.


   > That really depends on a lot of things.  Some of us won't work on
   > Emacs, but would contribute at least occasionally to XEmacs if it
   > continues to exist, for political or personal reasons.  Such
   > contributions would be more frequent if we were closer to the bleeding
   > edge, I am quite sure.  Whether we would attract new blood or not
   > depends on political factors, mostly.  Some things that GNU won't do
   > soon for political reasons, we can do, like proper support for the Mac
   > and Qt in the main distribution, and close interfacing with LLVM for
   > refactoring support.  All of those have attracted attention from many
   > people on emacs-devel, although they might not be willing to devote
   > time to working on them if XEmacs were the only way.


   > "Much" closer changes the equation in a qualitative way.  Technically,
   > XEmacs becomes an attractive (or at least "acceptable") platform for
   > experimentation again.

As I said in an earlier mail, forking GNU emacs, made a lot of sense 20
years ago because of two reasons.

    -  en RMS was not very keen to add X-support to GNU emacs or had
       simply not enough time.

    - But also from another point the situation was very different. The
      starting code base was small and the list of the enthusiastic
      hackers were large. Heck I remember when I had to switch around
      1997/98 for some month to GNU emacs because our Sun workstation
      could not deal with, I think was either Xemacs 19.16 or 20.2. GNU
      emacs was smaller, compiled faster and needed much less RAM. Today
      it is the other way around, the factor is around 3. It took me 3
      times as much CPU to compile GNU than Xemacs, the resulting deb
      pkg was around 3 times larger, and it needs 75 Mega of RAM
      compared to 25 of Xemacs.

That means today we have a huge code base and very little enthusiastic
hackers. I don't think that is a path to success. Take for example BIDI,
it is great that GNU emacs has it, but it is quite complicated so what
if we take the code and then find a bug, who is going to fix it?[1]



Footnotes: 
[1]  which brings me to a bit off topic. From time to time I read D.
     Knuth article about literate programming (basically you write more
     documentation than code) which he claims made LaTeX much easier
     to port to all sort of platforms. However I have never seen that
     style used in any free/open software project I know, but maybe for
     the forking purpose it would be very very useful.