gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] top posting and flame


From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] top posting and flame
Date: Sat, 01 Apr 2006 17:03:46 +0900
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (linux)

>>>>> "Daniel" == Daniel Stone <address@hidden> writes:

    Daniel> Did Canonical somehow interrupt your work on GNU Arch?  Do
    Daniel> you feel they are responsible for your not having been an
    Daniel> active Arch developer for well over a year now?  If so,
    Daniel> can you please list how?  Be specific.

I hope you have better luck than I have had in getting an
authoritative answer to those questions.  I'd like to know the
answers, too.

To the best of my understanding, your questions have the wrong slant.
Canonical didn't act to prevent Tom from doing what he wanted.
Rather, they provided a sink for resources that would otherwise have
flowed to GNU Arch.  The story AIUI basically comes down to

(1) Tom generously abdicated all claim to his legal monopoly over the
    Arch code base (Tom would probably prefer to scratch "generous"
    and simply call it the only ethical path, but you'll have to ask
    him).

(2) Tom's excellent design and high levels of productivity ensured
    that no personal fork (eg, ArX) would attract harmful amounts of
    developer effort away from GNU Arch, despite the absence of any
    coercive monopoly.  All is well with the world; the world gets an
    excellent free SCM in the short run, and Tom is free to pursue his
    long-run goals in and out of the GNU Arch project, with great
    prospects for more great stuff.  The "satellite" developers
    conform to Tom's guidance since Tom's the only one who can manage
    the project.  Financial contributions trickle in since Tom can and
    does fix bugs/add features to the extent that the changes are
    consonant with his vision for the project.

(3) Canonical realizes that there is a short-term cost-reduction
    opportunity in using Arch, but they could get even more cost
    reduction for their specific short-run uses by changing the design
    in ways that Tom considered detrimental.  They projected a
    sufficiently large benefit to this deviation that they were
    willing to pay something like 1-2 FTEs (my back-of-the-envelope
    estimate) to work on their branch.  Those FTEs were spread over
    several developers, not all highly active in GNU Arch, but at
    least one large contributor was attracted to Canonical, as well as
    a former release engineer for Arch (but AIUI he was a volunteer
    for Canonical, too).

(4) This provided a stable nucleus around which a number of Arch
    developers whose instincts aligned with the Canonical design more
    than GNU Arch's gathered, providing the necessary support for a
    commercial fork.

(5) Negotiations to get Tom to work for Canonical fell through.  I've
    not seen the details, maybe they were on the the developers' list.
    My conjecture is that Tom refused to work on the Canonical version
    without a promise of a substantial change of direction because he
    considered it wrongheaded and poorly coded, while Canonical was
    unwilling to pay for "whatever Tom happens to produce, it'll be
    great!" since that was unlikely to serve their short-term goals at
    all, and wasn't clear it would serve their medium-term objectives,
    either.

(6) The fork is now established, and contributors start to choose
    their primary allegiance.  This time the fork has robust
    prospects, so the level of interest in GNU Arch falls perceptibly,
    reducing both code and money contributions to the mainline.
    Financial distress forces Tom to reduce work on Arch, etc, at a
    time when other resources for the project are also being reduced.

So the issue is not that *Tom* was "prevented" from working on Arch;
it's that the GNU Arch project would have done great things, requiring
only general guidance and occasional direct effort from Tom, had it
not been starved of resources by the presence of the "false SCM" baz.
In the meantime, Tom could continue work on other pieces of the grand
puzzle.

It's the same story with any fork.  By the nature of a fork, the
projects are similar and will compete for the same resources.

-- 
School of Systems and Information Engineering 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]