Subject: on "human nature" (Re: improving project maintainership)
From: Tom Lord <lord@regexps.com>
Date: Fri, 8 Feb 2002 13:55:20 -0800 (PST)


There's an interesting juxtaposition that can be made between
Tiemann's comments about the 2.4 kernel, Bob Young's comments about
the value of collaboration, and Bob Young's comments about the
practical impossibility of taking desktop markets with Linux-based
solutions.

I'd paraphrase Tiemann as saying: "The community hasn't learned to
collaborate on testing.  Red Hat buys a lot of in-house testing and
does it better than some of our competitors.  That's apparent in both
our technical and financial results -- it's a competitive advantage.
We get some of that advantage by having, in-house, some of those
maintainers that best know the kernel."

Bob Young has said (again, my paraphrase): "Collaboration is what
let's us exist at all;  we couldn't have gotten this far without the
multiplying of our efforts that collaboration yields."

Putting these pieces together, I think the conclusion is that there is
a tactical advantage to being able to make-up-for, in-house, the areas
in which collaboration is weak and a strategic advantage to always
pushing the boundaries of what collaboration can do.

What does this have to do with the desktop?  The desktop, and other
areas in which the proposed solutions are inadequate are largely
resource starved.  I disagree with Bob: FSBs most certainly *can* win
in those markets, but to get there, they need to be able to redirect
resources they've already got.  That redirection can happen if
collaboration starts solving more problems.  Improving collaboration
is something that FSBs can invest in at tactical spending levels,
aiming for tactical victories.

If collaboration dies -- if FSBs cling to the tactical advantage that
Tiemann points out -- then the market expansion of FSBs is necessarily
slow if not stalled and, therefore, is vulnerable to regression.
Remember that FSBs are competing against "the big machines" at Sun,
MS, et al.  If the collaborative infrastructure gets stuck at some
level of evolution, the big machines will win.

Tiemann points out the competitive advantages of having maintainers
in-house and Turnbull calls this "hoarding competence" presuming that
that means I won't like it (that its "precisely what Tom wants to
avoid").

What I want is to improve the _processes_ and _mechanisms_ by which
public projects are administered, taking into account the reality of
divergent distributions and the problems of, nevertheless,
coordinating the development done by developers whose loyalty most
naturally aligns with just a subset of those distributions.

Using technical means, for example, yes, distributed revision control
or automated distributed testing, I want to reduce the number of ways
in which human nature can bring down a project and increase the
bang-for-buck return on maintainer effort.  Then human nature can turn
its cunning and competitive aspects to the *next* round of problems.

-t