Re: [Gnu-arch-users] Re: arch roadmap 1 (and "what's tom up to")

[Stephen J. Turnbull]

>>>>> "James" == James Blackwell <address@hidden> writes:

    James> I think that forks usually happen for one of two reasons:
    James> either mainline development stalls (or at least goes too
    James> slowly for comfort), or the leader makes a series of
    James> decisions in a row without getting others to buy into it
    James> first.

I think you are overemphasizing the role of the leader.  Yes, there
are many cases where the leaders' lack of leadership or oversupply :-)
thereof drives a fork.  But in many cases technical issues drive the
fork.  Eg, the BSDs---there are plenty of stories about the egos
involved, but the different forks have very clear technical
identities.  There's more there than ego, and probably there always
was.

    James> Stephen, this would be a good time for you to jump in. I
    James> know the emacs/xemacs fork was a pretty big one, but that's
    James> about _all_ I know.  Would you have any illuminating
    James> anecdoctal evidence?

Not really.  I wasn't there for it.  The best bet is to read the
primary material (which Tom gave references to; there is also a long
statement by rms quoted in
http://www.xemacs.org/About/XEmacsVsGNUemacs.html).  But I would say
that the Emacs/XEmacs fork is a singularity.

FWIW my read on what happened is that Emacs development _had_ stalled,
and when rms went to kick-start it he was clearly somewhere between
not interested and definitely opposed to many of the features that
Lucid decided it absolutely needed in its business plan.  Some of the
people involved with Lucid expected conflicts with rms, and they took
the easy way out: a fork more or less behind his back (this is reading
between the lines, I don't have primary material).  I have to wonder
if they were hoping to present him with a fait accompli that he would
have to accept, and the FSF (perhaps with substantial ex post help
from Lucid) would do the work of adapting to what rms considered sane
without interfering with Lucid's market timing.

rms was understandably peeved by Lucid pushing its own agenda in
private rather than contributing to the work he thought was high
priority, not to mention that Lucid paid a lot of money to Joe
Arceneaux, who was also on the FSF's payroll, supposedly the lead
developer on GNU Emacs 19.[1]  Although Lucid contributed all its code
to the FSF, which was their intention from the first (I think this is
plausible), rms refused to put it into the mainline.  He gave
precedence to supporting existing users on TTY and raw Xlib, while
Lucid required Xt in order provide a more powerful, consistent GUI as
part of its "Lucid Energize" product to development houses (which
evidently could afford more powerful workstations).  There was a lot
of other disruptive technology in Lucid Emacs, and rms wanted to redo
a lot of it, feature by feature.

There were personalities, money issues, bizarre misunderstandings,
other stuff, which just ensured that everybody would have really bad
feelings about the whole thing.

But the main issue was that at the time of the actual decision to
fork, Lucid had a fully operational Emacs 19 and an ongoing business
dependent on that product, while rms insisted that Lucid must
basically rewrite the whole thing to his spec[2] or it wasn't fit for
the mainline.  Given the stated goals of the two organizations, I'd
say there really were "irreconcilable technical differences", and the
fork was inevitable, at least in the short term.

Of course, there remains the weird feature of the Emacs schism that
sharing is unidirectional.  But that wasn't true before Lucid teamed
up with Sun (Arceneaux said that GNU adopted the Lucid event-stream
model, and of course even today the lwlib widget set bears the Lucid
copyright notice).  And I don't see what that has to with the process
of forking, so I'll just leave it at that.

Is this fork unique?  I tend to think it is.

(1) The divergence between rms's assessment of the general interest
and Lucid's assessment of its interest is stark.

If you compare the gcc fork(s) (egcs/pgcc), the divergence is tiny and
easily "marketized": Intel wants Itanium code generation improved, so
they pay for that, while Motorola pays for PPC64-specific development,
but the vast majority of code is not architecture specific and Cygnus
"taxes" all the arch-specific contracts to help pay for generic
development.  So the public interest (represented by the GNU Project
gcc team) and the private interest of the various clients is pretty
well aligned.  This is the other extreme, but not so much so compared
to the BSDs which share most OS utilities and drivers.

On the other hand, I suppose any big app could generate similar
divergence.  YMMV, but I think the Lucid/GNU divergence was unsually
strong.

(2) As one of the lead negotiators, rms is unique in his approach.
Does that matter all that much?  I could argue it either way, so I'm
not going to say; you decide.



Footnotes: 
[1]  Lucid claimed that they didn't see a problem with this, as they
provided Arceneaux with a development environment that the FSF
couldn't afford and expected him to produce GNU Emacs 19, which would
be close enough to what they needed that a permanent fork would be
unnecessary.

[2]  That was an honest bargaining position, not an attempt to torpedo
talks.  rms usually accepts patches more or less as they are if he's
going to accept at all, but when he accepts the idea but not the
implementation, he invariably requires that the contributor do the
revisions.  If not, and he really likes the idea, as a last resort he
or one of the core people will reimplement, as often as not from
scratch.

The extreme example (the negotiation of which lasted 10 years!) was
the "NEmacs patch" (Japanese Emacs) which eventually became "MULE".

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.