Subject: Re: Free Software vs. Disruptive Change
From: Mike Linksvayer <>
Date: 30 Jun 2002 00:30:12 -0700

On Sat, 2002-06-29 at 12:20, Jonathan S. Shapiro wrote:
> 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.

As does today's proprietary software.  Try competing with Word or
Oracle.  Those products and others have set the bar incredibly high for
would-be disruptors, even though many people can conceive of a word
processor or database that would be theoretically farsuperior.  The only
argument, I think, is whether free or proprietary applications are
raising the bar faster.  Over the very long term I'd like to think open
source, but world domination is _far_ from guaranteed.  I'd even venture
that marginalization of free software is more likely than the other
> 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.
> When making incremental improvement, a company paying a developer can
> say: "We will pay a modest amount for this change and it will be
> recouped several times in our business operating costs. Conversely,
> *anybody* could make this incremental change cost effectively, so it
> does not represent a meaningful barrier to entry. We should do it for
> the sake of the operational cost reduction rather than as a strategic
> investment, and we should give it away because competitors using
> proprietary infrastructure will be disadvantaged. I  believe that this
> argument lies at the heart of the success of open source collaboration.
> When initiating basic new design work, a company must weigh the
> strategic advantages (and costs) of a proprietary approach. The open
> approach can clearly be justified in many cases, but it is clearly
> *harder* to justify. Once the initiator is making the majority of the
> investment, there comes to be an incentive to monopolize the benefit.
> The stories are similar for investors. When a proposed technology is
> disruptive, the absence of open source ROI combines with the "ever
> rising barrier to entry" to make open source almost impossible to fund
> in large scale. The high cost of disruptive technology introduction
> isn't new. What I want to suggest here is that open source makes it
> higher, and therefore has the unintended side effect of impeding
> disruptive changes.

I have no argument with a narrow interpretation of your analysis above. 
But it sound suspiciously similar to arguments along the lines that
businesses only do incremental innovation due to short time horizons.

How many disruptive software technologies have arisen from the open
source or proprietary product development worlds in anything but an
incremental fashion?  None that I can think of.

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

Hasn't early EROS development occurred in Universities?
> 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. GCC itself is undergoing a
> reconstruction only very slowly -- you see new front ends periodically,
> but change to the GCC optimizer over the last decade has been relatively
> small. 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.

Highly selective illustration.  First, you neglected to mention
Microsoft as a compiler vendor.  Second, you neglected to mention that
gcc is perhaps the second most successful open source project in terms
of market share (after Apache).  In nearly any product area you can name
open source hasn't gained more than a toehold, from configuration
management to decision support to word processing to shoot 'em ups.

The software ecology has matured considerably, yes raising the barriers
to new technologies.  Free software is just a part of that.  Many
software entrepreneurs have tried to introduce disruptive products into
e.g., the desktop OS, office automation and database makets and failed. 
Over and over.  With near-zero open source presence in those markets.

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

Porting sounds like just the sort of thing open source contributors
working massively in parallel can do well, though it won't happen
overnight.  The first refactoring ports to EROS may require significant
innovation, most shouldn't.

OTOH if I were an investor after reading the above paragraph I'd run
away very fast, even if EROS were a proprietary product.  Way too much
work for a startup to take on its own.  Certain failure.

Leveraging the open source community to do your porting won't happen
overnight, but it has other benefits:  much higher chance that it will
eventually get done, dissemination of knowledge and buy in for EROS
(lots of people need to understand and appreciate the benefits of your
product if they're going to pay for it or pay for your services as the
one/company that knows it best), and you stay on good terms with
developers of all the leading open source applications.

Mike Linksvayer