Subject: Re: Free Software vs. Disruptive Change
From: (Kragen Sitaker)
Date: Sun, 30 Jun 2002 21:19:20 -0400 (EDT)

I apologize for the length and rough tone of this message; if I had
more time, I'd shorten it and make it clearer that I might be wrong.

Jonathan Shapiro asks:
> 2. Not a single publicly traded open source company that we can find is
> making money on operations, or seems likely to do so. ...
> Can anybody identify a publicly traded open source software company with
> a reasonable expectation of profit on operations in the forseeable
> future?

I seem to recall that Red Hat made money on operations for several
years before it became publicly traded.  I know Cyclic made money on
its operations, because it published its books, but it didn't make
enough to keep its primary employee (and owner) from being hired away
by Cygnus.  Peter Deutsch has told me Aladdin has made him quite rich.
I assume, also, that Sleepycat, Troll Tech, and Crynwr are profitable,
or at least breaking even, but I don't have their books.

That doesn't answer your question, of course, because none of these
companies are publicly traded.

> In fact, the only company *I* can think of that has made money on
> development was Cygnus. They didn't sell software; they sold development
> services. Here again, it was done by building on a pre-existing
> artifact: GCC.

That's true, but was the rearchitecture that created gcc 2.0 an
"incremental improvement"?  All I know is what I hear on the list and
read in _Open Sources_, but I thought it was a lot more like "basic
new design work".

> So my question: does open source make it dramatically harder to fund
> investment in disruptive technology (either open or proprietary)? I
> think the answer is "yes".
> By way of illustration: the existence of a free GCC makes the investment
> in building new compilers much harder to justify. Sun has continued only
> because they are stubborn, and Intel only because their new compiler is
> a sales tool for their processors -- that is, there is no profit
> expectation in their compiler suite.

I'm assuming that I understand what Christensen means by "disruptive
innovation", and that by "disruptive technology" you mean what he
means by that term.  If that's the case, you're completely wrong.

Batch-mode C compilers were disruptive, maybe, in 1975.  In 1998,
batch-mode C compilers (for 32-bit machines, especially) were very
definitely sustaining technology, not disruptive technology.

A couple of years ago, there were quite a number of proprietary C and
C++ compilers out there being licensed by companies like PGI and KAI.
The only people I know of who even considered buying them were HPC
folks, because these compilers optimized far better than GCC, often
producing 20%-30% faster code.  I don't know if these companies were
making a profit, but I can't recall hearing of any of them going

Intel bought some of them, which presumably means that Intel expected
to make more money selling chips with faster compilers than those
companies' shareholders expected to make selling the faster compilers.

I mostly agree that open source makes it dramatically harder to fund
investment in sustaining technology, but I don't see anything about
disruptive technology in your illustration.

> It can fairly be said that GCC, over time, essentially killed the
> commercial compiler business. That's not meant as a negative value
> judgement -- it's an observation.

Well, it looks like you're talking about two different issues.  One is
the GCC issue: competing against good free software is hard.
(Microsoft is only still in business because Linux still sucks as a
desktop OS.)  This is not a significant weakness of open source; this
is a significant strength of open source.

The other one is the EROS issue: funding free software development is
harder than funding proprietary software development, because selling
packaged free software is inherently a pretty low-margin business,
like selling ketchup, while proprietary software isn't.

> 1. We cannot identify a single, highly successful open source software
> company (i.e. a company in the business of selling packaged software and
> associated products such as service) that paid for its own *initial*
> engineering as part of its startup costs. ...
> We have identified several *services* companies based on open source
> code that the service company has developed. This is an entirely
> different business model. Viable, but one we are reluctant to undertake.

Well, look, you can't run a free software business on a proprietary
software business model.  It won't work.  The proprietary software
business model depends on having no competitors selling the same bits.
A successful free software business will have competitors selling the
same bits, so it will have to find a different way to make money.
Services is one way to do it, used by lots of successful FSBs,
including IBM; Red Hat seemed to be doing OK with the Heinz ketchup
model for a few years, but not anymore; dual licensing is another way
to do it; promoting your hardware by improving its software might be a

> For EROS, the problem is, in essence, that we need to do a refactoring
> port of essentially all of the major open source applications to have a
> viable entry. The good news is that we *can* do this because these tools
> are open source tools. The bad news is that its cost is very very high.
> Take the GCC situation and multiply. 

Look, are you going to market EROS as sustaining or disruptive?  If
it's disruptive, it doesn't *have* to do everything Linux does.  Linux
users, and Windows users too, will look at it and sneer, "You call
that thing an operating system?  You can't even run [insert one of the
4000 software packages in potato] on it!"  But it will do things Linux
and Windows can't do now and will never be able to do, and so people
who need those things will adopt it anyway, and one by one, those 4000
packages will get ported to it because people need them.

If the hydraulic backhoe makers in Christensen's example had waited
until they could do everything a steam shovel could do, they never
would have come to market with a product.

If you want to market EROS as a disruptive innovation, you need to
identify a market that EROS can satisfy relatively soon, and not after
going through the several billion dollars' worth of free software out
there and spending several hundred million dollars over several years
on breaking it up into compartments and porting it to EROS.  

For example, if you ported the Apache core and a few popular modules,
most of Perl, and all of Python to EROS, then wrote some nifty
administrative tools, you'd have a killer secure virtual hosting
environment.  Since Apache runs on TPF, Perl on VMS, and Python on
OS/400, none of them have strong Unix dependencies; and it's likely
that the existing boundaries between processes in this environment, if
enforced in a more efficient and flexible manner, could satisfy the
market's security needs.

Or perhaps you could market EROS as a highly secure firewall platform,
a platform for set-top boxes, a platform for easy-to-administer
handheld devices (no more mysterious software interactions!), or
something else.

Mike Linksvayer writes:
> Many software entrepreneurs have tried to introduce disruptive
> products into e.g., the desktop OS, office automation and database
> markets and failed. Over and over.  With near-zero open source
> presence in those markets.

I can think of only seven disruptive operating systems: Unix, CP/M,
MacOS, PalmOS, KeyKOS, FORTH, and EROS.  Most of them succeeded
brilliantly.  All the Unix dialects, MS-DOS, Windows, NeXTStep,
Netware, OS/2, and BeOS were simply sustaining (although some of them
ran on disruptive *hardware*.)

Unfortunately, I don't know much about the history of the office
automation and database markets, but I suspect I'd find a similar
story there.  Disruptive innovations, more or less by definition,
don't get overwhelmed by established competition.

> The first refactoring ports to EROS may require significant
> innovation, most shouldn't.

I assume that the refactoring to which Jonathan refers consists of
breaking programs into mutually untrusting parts and making them not
depend on dangerous privileges (like the ability to write to a
universally-shared /tmp, for example.)

In the Unix world, it has often been much easier to rewrite programs
from scratch than to partition old programs into mutually untrusting
parts; for example, popa3d, Postfix, qmail, and vsftpd were all
from-scratch rewrites.  (Niels Provos' privilege-separation work on
OpenSSHd is an exception.)  EROS offers much better facilities for
constructing these parts, but I intuitively suspect that retrofitting
distrust into existing applications will still take a lot of time and

<>       Kragen Sitaker     <>
Irony and sarcasm deflate seriousness, and when your seriousness becomes detum-
escent, you're not held responsible for your thoughts. Irony beats thinking like
rock beats scissors. --