Subject: Re: Free software as a replacement for Microsoft
From: Tom Lord <lord@regexps.com>
Date: Sun, 16 Sep 2001 13:29:54 -0700 (PDT)



       I think the evidence is pretty clear, though:  You can't build a
       free software business competing with Microsoft for dominance on
       the desktop.  Larry and the team at VA tried it; it didn't work.
       Abiword, Eazel, Caldera, SuSE, and others

That's not clear evidence at all.  They all took (or are taking) a
similar technological approach to one another, and most tried (or are
trying) similar business models aimed at getting a large general
customer base quickly.  Those are four important variables
(technology, business model, initial customer base, planned rate of
deployment) -- all we have is evidence that one particular setting of
those variables doesn't win right off the bat.

	If you're asking yourself how you can capture Excel users from
	Microsoft, you're doomed.

If you're trying to do that as a tactic (short term, reliable play)
you're obviously correct if for no other reason than the technology
isn't available.  However, if you're trying to build a _strategy_ in
that direction, you're smart.  There's simply no other possibility if
you want to survive in the long term.

I think there are some fairly promising strategic directions to take,
though I don't want to publish them in detail on this list (if you're
interested, contact me privately).  Some companies not on your list
are quietly active in this area and there is plenty more that can be
done.

One of my personal favorite peeves relates to the "technology"
variable.  Unix-ish, software tools approaches to desktop apps haven't
been invested in in any serious ways.  That style of tool
differentiates Unix from MS platforms and industry leaders ought to
have been building upon that aggressively all these years.

Historically, Unix software tools development has been badly outspent
(in comparison to spending on MS' software architecture)
simply because no unix-based businesses stepped in to create a
unix-style platform sufficiently small to run on early PCs at the
right price-point for the early desktop market.  (The existence,
today, of small, embedded, unix-compatible platforms proves that the
lack of something that could have been called "unix" on early PCs has
no technical excuse -- it was a tactical oversite.)

In the late 1980s, people began creating graphical desktop
environments for low-cost machines.  At that time, in academia, we
developed on relatively expensive unix work-stations, but the implicit
target was next generation low-cost PC hardware, which everyone knew
would soon be challenging the workstation market from below.

Several important academic projects created GUI environments.  For
example, the Andrew proejct at CMU, succeeded at creating a simple
component architecture sufficiently powerful to build the core
applications of the emerging desktop: a nearly-WYSISYG multi-media
word processor, a multi-media email user agent, a spread-sheet, and a
drawing editor; the programs implementing those components were
expressed in the form of dynamically loadable modules designed to
share a single process and address space.  That software is still in
(limited) active use today, almost 15 years later: it was pretty good.

Technology and personnel from those academic projects were transferred
to Microsoft who encorporated the basic architecture into their
emerging monolith and gaves us early versions of Windows.  They built
on top of DOS.  Had they instead used a unix-like embedded kernel, the
industry would be very diffent today.

Microsoft, by putting a desktop on a cheap PC first, reaped a famous
windfall from the then new desktop market and has since then had ample
resources to keep the monolith going by brute force.  .NET is a
natural extension of that effort: it aims to extend the component
architecture in such a was as to capture a useful range of patterns
for Internet application development.  Linux vendors today face not
only a huge barrier in the desktop market, but an increasingly serious
threat of backsliding in the network infrastructure space.  I expect
MS, which has now had lots of practice, to menace the embedded systems
markets next.

Today's open source unix-family vendors can learn from their
proprietary predecessors: The early unix industry was badly managed.
Vendors implemented revenues with expensive Unix licenses.
Consequently, they were forced to compete on platform features rather
than develop a meaningful industry standard and extend the platform.
There were "System V" vs "BSD" wars.  There were file system
performance wars.  There were compiler wars.  There were numerous but
pointless small incompatibilities between platforms.  One way for
programmer's to specialize their skills in those days was to become an
expert in porting between unix platforms;  how sad that Linux vendors 
are starting to create demand for a similar specialization.

There was a token amount of investment in creating new software tools
to extend the reach of unix-family platforms as a whole, but in
several years, there was barely enough of this to fill out a Usenix
technical conference speaker program.  All those nearly pointless
fights on easily-measured, easily-slide-showed aspects of platform
performance soaked up a lot of resources that could have gone to
beefing up what unix is capable of.

That was an odd path to steer.  The early popularity of Unix was in
large part driven by a small flurry of software tools development at
places like Bell Labs and the Computing Systems Research Group at the
University of California, Berkeley.  When Unix grew into a big
business, development and wide-spread deployment of new tools failed,
for the most part, to grow along with it.  Unix today looks much the
same as it did a decade ago.  If it weren't for open source projects
like Perl, GNU, and X11 -- unix would be a legacy platform at best:
Oracle's kernel, or something.

That unix has survived at all is a remarkable demonstration of the
power and flexibility of the software tools approach.  Let's hope
today's Linux vendors learn to pick up on that and start planting
two trees for every one they cut down.

-t