[Gnu-arch-users] details, details

[Thomas Lord]

On Wed, 2005-09-07 at 08:19 +0100, Andrew Suffield wrote:
> On Tue, Sep 06, 2005 at 05:24:22PM -0700, Thomas Lord wrote:
> > From an engineering perspective, I question why we need platform
> > distribution companies *at that scale* *at all*.
> 
> I question who said that we needed them. We get them because people
> with money move in and 'invest' (which means speculatively purchasing
> other people's effort) with the intent of making more money. And
> people without money are willing to sell out to them.

Hence the labor issues that appear in free software:  only a subset
of the effort that goes into the software components needs to be
purchased to control the rest.  It's all about hearts and minds, baby.

One small example from Arch illustrates how this plays out: the "tree
allocator" code Baz added to Hackerlab.   Months prior the code was
discussed with me.   I said I didn't want it added to Hackerlab because
it was too specialized and too much code solving a relative non-problem.
It's very limited range of applicability invited future bugs when it
was misapplied or when people modified code without spotting how it
was being used.   It's performance characteristics are certainly 
nothing to write home about.   I saw no good reason to commit to 
maintaining this code for so little and so dubious gain.

Sure enough, then, it appeared in baz, in hackerlab, with dependencies
on it in Arch itself.   No attempt had been made to format it 
consistently with the rest of Hackerlab code.   No attempt had been
made to integrate it with the alloc_limits API that all of the rest
of hackerlab uses as a layer over malloc.  If it contained non-portable
code I don't remember but certainly other patches from baz did.

How many hours am I supposed to volunteer to fix that code -- either
cleaning it up and making it fit the API conventions or eliminating
it altogether?  How many hours am I then supposed to send working on
getting my repairs to it into Baz itself so that future patches to
overlapping areas of the code don't conflict?   (And isn't it ironic
that I noticed this particular egregiousness while working on patching
tla to be able to read baz archives whose format reflects a design
process in which I was, again, early on asked for input, suggested 
improvements, and then ignored).

And with patches arriving like that at the famously high rate of 
change in baz, and most of those patches of about the same quality -- I
could easily have had more than a full-time job just cleaning up other
people's code which implements yet more bogus design decisions.

The whole time, of course, Canonical is hosting and running around
to conferences, chanting the mantra "Tom is too slow at processing
patches" without mentioning their role in making that so --- and the
final kick in the teeth, treating their newly taken over project as
a provisional hack to be discarded at the earliest possible opportunity.
Of course they wouldn't make the effort to work cleanly: to them,
the whole thing is just a throwaway project.

This appears to be quite similar to the pattern that played out
with GCC and its "friendly, experimental" fork, EGCS.   The 
volunteer-managed FSF GCC progressed "too slowly" for businesses
at the time and through a similar set of maneuvers, it was forked
and then displaced.  It was inconceivable to the commercial hackers
I spoke with back then that what they were doing was wrong.  They
were sold on the idea that "progress" meant their businesses getting
ahead as cheaply and as short-term-oriented as possible.   The resulting
dog-pile-on-the-code approach resulted, predictably, in a bloated 
monolith of a compiler and complete neglect of contemporaneous 
efforts to get compiler construction back on the track of producing
simple, maintainable systems.  Management oriented towards a slower
growth path for those businesses and business units, marketing aimed
at educating customers about why this was desirable -- those ideas
were simply not on the table.

One of the more amusing and clever alternatives I've heard of comes
from Greenspun, who I'll paraphrase.   After initial successes, he
had a small company with plenty in the bank and a tight team of hackers.
Worst case, they reasoned, they could use the banked money to go
into the party equipment rental business for bread and butter while
taking careful next-steps with the software.  Brilliant!  Alas, they
made the usual mistakes of trusting outside investors and through a
series of power plays, lost control of the now trashed company.

> 
> Money corrupts.

I don't accept that.   Money is a very useful tool.  Some markets
function very well, promote economic growth, and create the famous
"rising tide".   Overthrowing the money-system is unlikely to be
helpful.

Stupidity and moral bankruptcy corrupt.   Arrogant wielding of power
corrupts.   When stupid, morally bankrupt, arrogant people dominate
a particular market they tend to attract and favor people like 
themselves.   When the bulk of a given labor force is young, naive,
inexperienced, and politically uncritical, a corrupt leadership
can more or less lead them around by the noses -- that is how the
Tragedy of the Commons is playing out in the free software and open
source volunteer community.

The funny thing is I don't have an image here of a bunch of 
Dr. Evils sitting around a conference room table saying "How
can we best screw as many of these people as possible."  Rather,
it seems to be mostly the result of habits and uncritically
inherited attitudes.   Hence my, as one person put it, "moral whining".


"The unexamined life is not worth living." -- S.
-t