Re: [Sheflug] Re: RMS Talk

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

>>>>> "Will" == Will Newton <will [at] misconception.org.uk> writes:

    Will> On Sat, 28 Oct 2000, Richard wrote:
    >> Strangely enough Stephen Turnbull has suggested something
    >> similar to me.  Although, the internal argument over Emacs 21
    >> has been quite intensive.  As RMS said in his talk, this time
    >> around he'll release it when he's good and ready.

    Will> Not really too far away from the Linux model.

Maybe on release dates.

    Will> RMS has final say in the same way as Linus does. In both
    Will> cases I don't think it really matters so much as both are
    Will> fairly mature and rather complex projects with stability
    Will> more important than features.

No, this is _not_ true.  Although Linus does have veto power over just
about everything in Linux, he has made a policy of choosing strong-
minded lieutenants.  If he tried to veto DaveM sparc changes, or many
of the things Alan Cox does, there would be a fork.  But giving
authority to people who will do things differently from him is very
much part of the goal of the "Linus management model".  Furthermore,
there are no private Linux mailing lists AFAIK.  I doubt there will be
a Linux fork as long as Linus runs things.

By contrast, rms has historically used his veto power heavily.  That
has been responsible for several forks (GCC and Emacs), and even the
Emacs LISP repository has long been somewhere _other_ than inside the
GNU project, because RMS has a long history of burying contributed
LISP applications that he doesn't like.  Maintainers of GNU projects,
especially Emacs and GCC, have normally been expected to cede final
authority on all design decisions to RMS.  GNU devel mailing lists are
generally "by invitation only," and lurkers (especially potential
XEmacs spies on Emacs lists) are not welcome.

As for stability, RMS has many times made gratuitous backward
incompatible changes in Emacs at the UI level, and continuously does
so at the API level---in the stable series of releases.  Fixing this
annoyance is precisely why the kernel is developed in two branches
simultaneously.

This may be changing now that RMS has finally delegated Emacs
development to someone else, namely Gerd Moellmann.  Gerd even seems
capable of being polite to XEmacs maintainers.  :-)  At this point, I
don't think RMS directly runs any crucial GNU projects (I think he
maintains substantial input into Make, and of course he still works on
Emacs a lot).

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.