Re: XEmacs at a crossroads

Raymond Toy writes:

 > It would be unfortunate if the mailing list stopped.  That doesn't
 > mean, however, that someone has to continue to handle spam and
 > other maintenance.

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.

 > Does anyone see this as a viable alternative?  XEmacs would be
 > Emacs until someone puts in all of the XEmacs bits back in.

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.

 > And then what?  Won't XEmacs be in the same boat as it is now,

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.

 > except that it's much closer to Emacs than it is now?

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

Regards,
Steve