Re: XEmacs at a crossroads

>>>>> "Stephen" == Stephen J Turnbull <[email protected]> writes:

    Stephen> Raymond Toy writes:
    Stephen> Richard certainly recognizes that sense of "compete", and so do many
    Stephen> GNU Emacs contributors.  Richard has always discouraged GNU Emacs
    Stephen> developers from even looking at XEmacs code (for several reasons, the
    Stephen> most important of which is copyright paranoia), and actively solicited
    Stephen> our contributors and users to work on Emacs because "GNU's work is so
    Stephen> important" (he claims to believe that that would have no impact on
    Stephen> contributions to XEmacs, I'm an economist and know better).

That seems self-evident, even if you're not an economist.

    Stephen> 1.  Close up shop and release the resources to other projects.
    >> 
    >> What does that really mean, since XEmacs is open source?

    Stephen> Of course XEmacs source code would continue to exist.  AFAIK Bitbucket
    Stephen> has no policy to shut down inactive repos.  But the project could shut
    Stephen> down.  That is, no infrastructure support for users and would-be
    Stephen> developers.  No MLs, no central archives, no binary packages.  This

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.

    Stephen> And thre are proactive tasks that need to be done.  The Tux
    Stephen> infrastructure is creaking (and so is their administration; the most
    Stephen> active admin there claims he isn't an admin and is more interested in
    Stephen> preventing spam than in delivering mail).  We have an alternative host
    Stephen> in mind, but I need to free up some "round tuits" and implement it
    Stephen> (and that task gets more daunting all the time with each newsclip on
    Stephen> yet another exploit of some major site).

    >> I don't have any suggestions on the way forward, but [3] seems like
    >> not such a good idea.

    Stephen> Yeah, we know that.  But it's the only way we've thought of so far to
    Stephen> get back to feature parity.

Does anyone see this as a viable alternative?  XEmacs would be Emacs
until someone puts in all of the XEmacs bits back in.  That seems like
a fair bit of work.  And then what?  Won't XEmacs be in the same boat
as it is now, except that it's much closer to Emacs than it is now?

--
Ray