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

[Thomas Lord]

   Thomas> When you come across an expert in some topic that
   Thomas> interests you, you act with respect towards that expert.

   Stephen> They offered you money, did they not?

Not to work on GNU Arch.  Not in any way to continue working on the
project.  Indeed, to spend 40hrs/wk specifically *not* working on GNU
Arch.  It was "conceded" (for it could not be legally prohibited, at
least in California) that if Canonical happened to release GPLed
software that would be useful in GNU Arch, I would be free, after
hours, to contribute a merge of that to GNU Arch.  I would, though, be
required to write code for Canonical which would not be released.  I
was, in my view, offered money to create a hostile fork of my own
project and, in that fork, cede a technical direction role for (at
best) a technical advisory role.

Giving up "control" is not in and of itself a bad thing.  What matters
is what the intentions are of those to whom control is ceded.  See next:



   Stephen> (Don't say "they should have listened to me when I told
   Stephen> them what they were doing was dumb."  Argument from
   Stephen> authority is a logical fallacy.)

At the time I interviewed with them, I came away with the strong
impression that the Canonical goal would be to optimize arch for
centralizing development within a single organization -- the very
antithesis of what Arch is about.   Subsequent development at
Canonical has only strengthened my belief in that opinion.

As time passed, I saw the promiscuity of their fork for user
interface, core algorithm, and core data structure changes that were
too often half-baked.  I came to have the opinion that this
short-sighted promiscuity was in large part aimed at centralizing
development in another way: by creating a shaggy dog story based on
the theme that "Tom is just being stubborn.  See, we're happy to make
that change!  So switch to our fork!"  Like all good shaggy dog
stories, their fork simply peters out at the end.

"Dumb" is probably not the first adjective I'd now apply to what
Canonical was doing.  It might be on the list of adjectives, of
course, but only after we'd reached agreement on some of the others.



   Thomas> They left me in a state of discredit based on highly
   Thomas> misleading rumours about why I had made certain decisions.

   Stephen> If you're referring (at least in part) to my
   Stephen> speculations, you are wrong.  Speaking only for myself:
   Stephen> My speculations are mostly based on your public
   Stephen> statements, and in part on your private communications to
   Stephen> me.

I am referring mostly to that "shaggy dog story."   See the next,
regarding that.


   Stephen> Here's an important, interesting, 100% unsupported claim:
   Thomas>> there were plenty of same-cost alternatives that would
   Thomas>> almost certainly have led to a better outcome *for both
   Thomas>> sides*.

   Stephen> Indeed?  What were they?  Specifically, what did you
   Stephen> propose to Canonical?  And, for comparison, what did they
   Stephen> offer you that was so self-defeating?  In detail, except
   Stephen> for salary, which isn't relevant (if there's a win-win
   Stephen> solution, the salary can adjust to cover net costs on
   Stephen> both sides).


My memory of the initial conversations with Mr. Shuttleworth can not
be perfect, I'm sure.  I will try my best to reconstruct the
essentials you are asking about and to be fair to Mr. Shuttleworth
and Canonical.

Before I was contacted by Canonical, you may remember, I began to
elaborate publicly on the "vision" behind arch.  I spoke about
decentralizing the development and maintenance of the GNU/Linux stack
and about how that decentralized pattern can be run as a business.

By "decentralize" I do not mean that "developers from all over the
world, from many different organizations, can contribute."  That is
not, in and of itself decentralization.

By "decentralize" I did mean that there should not be just one or even
just a small number of closely controlled release branches.  Instead,
there should be closely controlled release branches at a ratio of
something closer to 1 branch per 10,000 users.  Each of these many
release branches of the stack should be capable of standing alone, in
a pinch.  Each should involve a complete production pipeline including
an R&D contribution, basic support, patch introduction, review and
testing, release management, and distribution.

To achieve that level of decentralization requires significant but
quite possible increases in efficiency.

To have achieved that level of decentralization will be to have made
a stunning contribution to both public safety and software freedom.

At such small ratios, no one stand-alone branch of the stack can
realistically take on 100% of ordinary day-to-day R&D and critical
maintenance duties.  It's stand-alone "in a pinch", not absolutely.
On the other hand, any subset of a few 10 stand-alone branches at
those ratios *can* take on 100% of R&D and critical maintenance
duties.  Cooperation among those branches is essential but, with so
many, branches, many fluid confederations can coexist.  Cooperation at
larger scales, akin to today's global projects, is just icing on the
cake (although one must be on guard against creating and then relying
upon software stacks whose complexity becomes intractable -- a
situation we aggressively flirt with today).

Of course, in a more or less stable world, cooperation at larger
scales would be the rule, not the exception.  We would still have
thousands or 10s of thousands of significant contributors to a shared
stack.  The differences would be the capability of severability, an
increase in review and testing, and a localization of support.

As you may recall, mere weeks before Canonical arrived on the scene,
we began work on distributed bug databases, patch queues, review
queues, testing queues, etc.  This was, in fact, the first work to be
hopelessly disrupted by the move of initial employees to Canonical.

As I recall, Mark began our interview by paraphrasing that idea back
to me and expressing excitement about it.  He proceeded in a kind of
non-sequitor to talk about Canonical.  Canonical would be a
brain-drain, hiring a few big project leaders.  Canonical would invest
in creating some centralized servers in which to house a
commercialized downstream of Debian.  Canonical would obtain advantage
over competitors by closely holding much of the infrastructure it used
to create a commercial pipeline off Debian.  It would be keen if
isolated developers around the world could use Arch on their own
machines -- so long as it would be uniquely convenient for them to
make their contributions via Canonical instead of, say, via Debian.
Directing individual contributors to Canonical seemed to be his
interest in me.

I tried to explain the difference between what he was proposing and
what Arch was for but got nowhere.

I do recall a lot of concern from Mr. S. that I be willing to write an
unspecified "some" amount of code which I would not be permitted to
modify (other than under direction of Canonical) or redistribute.  I
do not recall specific discussions about restrictions on my personal
use of software I'd create for Canonical but I think it is a safe
presumption that I would not be permitted to set up my own private
instance of Canonical's web services using that code.

I don't know what "some" would have turned into but I did come away
with the distinct impression of the camel who asks first if, since it
is such a cold night, may he please stick his nose in my tent.  Ok,
really, the camel's neck is cold too and that won't take up that much
more space, right?  ....

The differences between the infrastructure I was proposing and what
Canonical wanted are subtle.  It is a question of design, not of the
amount of work it takes.

Moreover, Canonical could have achieved the same work-flow they
exhibit today using my infrastructure ideas rather than theirs
and using public rather than private code.   Ubuntu would still
exist in much the same as the current form.  There would just be a
more thoughtful infrastructure in the production pipeline.

While with my infrastructure Canonical would not have a *permanently*
exclusive capability they (a) don't anyway, even with what they've
built; (b) would have a huge head start and attendant advantages;
(c) would grow by growing their market by enabling true franchising
instead of the support-partners thing they now have;  (d) wouldn't
have wasted money on a now-dead fork of Arch;  (e) and anyway, only
advertise support-contract products which are completely orthogonal
to this infrastructure choice.

What a waste.



    Stephen> Here's one that's a little subtle, it tugs at the
    heartstrings of even Stephen> a Dismal Scientist:

   Thomas> [Canonical] exploited my labor.

    Stephen> What happened was that Canonical accepted your gift (of
    Stephen> the product of labor you had long since contributed), on
    Stephen> the terms you published (the GPL).  They returned to you
    Stephen> *in kind* as specified in the GPL, but it so happened
    Stephen> you didn't like, and rejected, their code.  Exactly
    Stephen> reciprocal---you wrote code that you liked, Canonical
    Stephen> wrote code that they liked, both published and licensed
    Stephen> under the GPL.  Where is there exploitation?


I think you are conflating bits with projects, law with the ethics
of responsibility, and over-simplified economic models with reality.

The exploitation can be observed in the relative benefits received
in the complex interactions that took place, compared to the many
alternatives that were available and in light of intentions and
actions.


-t