Subject: Re: Free Software vs Disruptive Change
From: "Benjamin J. Tilly " <>
Date: Tue, 02 Jul 2002 00:24:55 +0800

Jonathan Shapiro wrote:
> Folks:
> You all know me as a strong advocate of open source (with or without the
> trademark), so I hope you won't read what follows as a diatribe. As some
> of you know, I'm in the process of gearing up a company around the EROS
> project. we have had a series of internal discussions that are either
> (a) off base, or (b) problematic, in that they suggest a significant
> weakness of open source. Tim O'Reilly's recent column:
> prompts me to open a discussion about it here. My apologies for the
> length, but I believe context is helpful to frame the discussion.

Hey, I really liked Tim O'Reilly's recent column, and I was wondering
when it would be discussed here. :-)

> Over the past two decades, open source has slowly amassed a large body
> of function -- operating systems, web servers, databases, mail servers,
> etc. etc. All of this came about in an incremental way. For economic
> reasons, the absence of open tools was a critical enabler to their
> incremental creation. Today, this body of free software represents a
> continuously rising barrier to entry that any new technology,
> proprietary or free, needs to meet. It sets a minimum standard of
> function.

I disagree.  The phrase "minimum standard of function" only applies if
you are planning to compete head on with existing solutions.  Don't do
that then.

> I have argued in the past that open source collaboration is very well
> suited to incremental improvement (perhaps I should say, rather,
> "improvement at the margin" -- adding new function to existing tools
> certainly qualifies), but not well suited to funding disruptive
> innovation. The reason has to do with the risk/payoff ratio.

What do you mean by disruptive innovation?  I think I know, and I think
that most people are about to assume something significantly different.

> So we have been looking at business models, and we have come up with two
> very disturbing observations:
> 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. RedHat, for example, has made
> major investment in Linux and other technologies, but it did not have to
> build Linux from scratch. Similarly for other companies we have
> identified. The pattern has been that prototyping and early development
> has occurred as individual effort or in Universities and later
> commercialized. We would like very much to know of a counter-example:
> one in which a company has actually paid for its development costs from
> the ground up.

Please read for
an excellent explanation of why examples will be few and far between.
It also complements Tim O'Reilly's thoughts very well.

> 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.

I disagree.

The problem is, in essence, that you need to define viable initial
target markets that you can address *without* doing all that up front.

A viable product that you might look into is EROS running as a user
process under Linux or FreeBSD, with a well-defined interaction model
between internal EROS processes and external processes.  The idea is
that you are running an ultra-secure sandbox, and this tool is useful
even if someone needs capabilities that EROS does not yet have.

For instance it is common today for people to embed Apache into all
sorts of devices for remote administration.  It is just a question of
time until the recent chunking bug starts being exploited to crack these
devices.  If those copies of Apache were running inside EROS on top of
whatever OS the device runs, it would be extremely difficult to leverage
the Apache exploit into anything useful.  First of all it would be hard
(particularly for someone who hasn't seen EROS) to leverage the exploit
into access to the capabilities that allow editing of the administrative
files.  And it should be impossible to leverage that into local shell
access.  (This is, of course, assuming that you don't have a more secure
httpd for people to run...)

This makes EROS useful even if it doesn't for instance, have drivers for
the hardware, or possess the necessary software to do whatever the
embedded device does.

Allow EROS take advantage of features like raw partitions, and (assuming
that your earlier benchmarks hold) its advantages over *nix operating
systems on security, IPC speed, and disk performance should drive the
incremental development of a richer and richer set of native programs...


Download the free Opera browser at

Free OperaMail at

Powered by Outblaze