Subject: Re: Free software as a replacement for Microsoft
From: Tom Lord <>
Date: Tue, 18 Sep 2001 06:09:17 -0700 (PDT)


       The answer (or at least my answer) would be to focus more on
       the market than the software.  Software, particularly open
       source software, is infinitely malleable.  So start with which
       customer you want to serve and set your development priorities
       from there.  But then I'm no software architect.

I can see how "software is infinitely malleable" is a good rule of
thumb if you're an exec whose leadership responsibilities do not
directly include technical leadership.  As long as discussion is
constrained to consideration of short-term, tactical plays, within
domains for which you're technology is well prepared, "infinitely
malleable" is what you're engineering staff should (approximately)
offer you.  It makes the jobs related to finding customers and keeping
them satisfied tractable.

At strategic time scales, software *isn't* infinitely malleable. The
very opposite is true: software developed without effective strategic
awareness invites "curling", to repeat an earlier sports analogy.  I
think this is relevant to all kinds of FSB execs and engineers because
it says something about the kinds of development organization that a
business needs to renew its advantages over time.

Tactical malleability is an elusive quality of complex software
systems: something which we have to work very hard to achieve.  Part
of that work is carefully choosing architectures.  Part of it is
executing architectures under conditions that favor success, even when
that execution can't be performed as side effects of a series of
tactical plays.

When choosing architectures, it helps a lot if, within the domain of
functionality you're considering, there is a history of previous
architectural attempts by others whose experience you can draw upon.
Something I've tried to point out about some of the rising
app-framework architectures in the open source world is that the
tactical malleability of a complex piece of software is *not*
independent of the structure of the engineering organizations that
will use it to make tactical plays: a large army of coders controlled
from a central point, responding to orders expressed as
entity-relation diagrams and the like, enables some kinds of tactical
play; a loose alliance of individualist coders, without central
control, enables different (usually superior) kinds of tactical play.
Different architectures make sense in different contexts.

On the specific subject of GNOME, I am struck by not only the
architectural resemblance of GNOME to the Andrew Toolkit (a project I
was part of, as a junior staff member), but by the project management
resemblance.  GNOME is more ambitious than ATK feature-wise and has a
better appearance (or, rather, family of appearences, via skins).  To
a first approximation, though, they are architecturally quite similar.
As I recall the ATK project, things proceeded for a while with
different subgroups just hacking their hearts out on various
applications and architectural extensions.  Then, at one point, as the
system was being more aggressively deployed on campus, the leadership
promoted the idea of buckling down and serving the user community.
The focus switched from innovation to polish.  A big deal was made
about "the hit list" of known bugs and botched details.  Performance
started to be measured and improved in serious ways.  Effort switched
to a focus on tightening up the system to make it reliable and
productive for a large set of non-technical users.  There was fairly
tight feedback between the (cruelly critical :-) user community and
the developers.  I think that phase shift in project focus is what
gave ATK the long life it has enjoyed, in spite of falling far behind
the bleeding edge in terms of features.  I am certain that the
architecture was being pushed to its breaking-point limits just prior
to that phase -- we had started coming up with good goals that were
tactically unachievable without a large strategic overhaul of the
entire system.

A funny thing about the politics of the ATK project, life at CMU, and
my social position as a junior staff member: I got lots of informal
input from the surrounding technical community about the strategic
errors of the ATK architecture: input from a wide variety of
perspectives which it has been my privilege to try to integrate into a
coherent set of beautiful ideas and practical plans.  But that's
another story entirely.

Tom Lord