Re: XEmacs at a crossroads
Stephen J. Turnbull <stephen <at> xemacs.org> writes:
Several alternative paths
have been suggested:
1. Close up shop and release the resources to other projects.
2. Close up shop and move en masse to GNU Emacs development.
3. Fork current GNU Emacs, and gradually recreate an XEmacs-
flavored GNU-Emacs-compatible language and editor.
4. Maintain infrastructure as a "caretaker" project, for the
benefit of continuing users, and in case somebody wants to
pick up the ball.
There is no consensus on closing up or on what to do if we did, and
therefore options 1 and 2 are off the table. (Individual developers
will (and should) do as they want, of course.) Option 3 has its
attractions[3], but no commitment from developers with a history of
substantial contributions of code.
[...]
Footnotes:
[3] As well as the potential to upset a lot of people in the GNU
Emacs community.
with regard to footnote 3: I doubt it. A concerted replacement of current
XEmacs (regarding distributions, this may mean either 21.5 or even 21.4)
with a current fork of Emacs would result in a sigh of relief from many,
many Emacs developers trying to maintain XEmacs compatibility.
Of course, the sigh of relief would not last as the new XEmacs fork would
likely start trailing behind, at least once merges became non-trivial.
Emacs these days can be extended in packages, and at least the MELPA package
archive does not require copyright assignments from its contributors.
People with strong enough programming-foo to want to hack the core of their
editor and with strong enough no-thanks-Richard-foo to not want to assign
copyright of their work to FSF or see their contributions managed by FSF and
more likely the Emacs developer community will continue to work with either
current XEmacs or such an Emacs fork.
I am pretty certain that this set remains non-empty. But at the current
point of time, I don't see that it is large enough to carry the weight for a
project of Emacs' size.
Free Software is something that gets carried forward by a mixture of
pragmatic and of idealistic developers. The current Emacs development has
changed in categories where either would have considered Emacs less
attractive previously. The course of the current maintainer John Wigley is
still developing, but he comes from a more pragmatic background and has met
RMS in person before agreeing to the role.
So I think there is reason for careful optimism that most of the concerns
that resulted in the fork of Lucid Emacs and the continued upkeep of XEmacs
have abated to a level where it is likely the sanest choice to work with or
on Emacs (possibly on external non-assigned packages) and think about a
fresh fork should enough people start considering the situation untenable again.
I am pretty sure that a fresh fork would aggravate package maintainers much
less (at least initially) than the current XEmacs/Emacs fork does.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta