Subject: Re: A few thoughts.
From: shap@eros.cis.upenn.edu
Date: Fri, 14 Aug 1998 10:38:15 -0300

> Frank Hecker <hecker@netscape.com> wrote:
>  > ... So I was trying to think of some cases where
>  > software innovations first appeared in open-source form and those
>  > products continued to be popular.
> 
> Now that it [netscape communicator] is open-source, someone can just
> go ahead and implement a feature that's too risky or too costly to
> implement before. This is ``innovation in the small'';

I've been looking at costing open-source development, and I think that
what you say is only partially true.

It's true that individual user communities can now implement
community-specific features, and that they could not do this on a
proprietary code base.  It's not so much cost that gets reduced as the
size of market you need to make the work cost-effective and the number
of places you can shift the burden of development costs to.

Other communities will sometimes adopt these features, and when enough
people yell for them they'll get merged into the common source base.
This is a force for innovation, and that's a good thing *provided*
that the source maintainer has sufficient technical taste to keep the
source base maintainable. I believe that this sense of ``taste'' is
one of the key reasons why Cygnus has succeeded -- Michael certainly
has it, and has somehow figured out how to train people to it or
recognize and hire people who have it already.

I'm not convinced, however, that development in the large is any
cheaper in the open source model.  The ``innovation in the small''
issue is about focusing *more* development dollars on the same code
base by redistributing the costs.


My issue with what you say is that I'm not convinced that open source
engineering is cheaper overall.  Dennis Allison and I were talking
through the costing on an open source development for a consulting
project recently.  Our conclusion was that if you want to deliver a
tested, robust product, the engineering, integration and testing cost
is about the same in the open source model as it would be to do things
in a proprietary model.  The advantage is leverage and ability to
experiment with the product in a way that is visible to the market.

Neither he nor I has any experience actually *doing* this, so I'ld be
very interested to hear if this conforms to what RedHat, Cygnus, and
others have actually experienced.

[ Michael writes: ]

>  > My benchmark of innovation is rather whether the software in question
>  > gave rise to a recognizable new market space (with multiple competing
>  > products and companies formed around those products) that did not
>  > previously exist prior to the first product of that type appearing.

This is a reasonable benchmark for product innovation.  I'ld suggest,
though, that a product that substantially redefines or succeeds in
altering the balance of market share in an established market also
qualifies as innovative.  Once the top two players in a given market
are established, you really need a perceived 10x advantage to displace
them.  Emphasis on *perceived*.

> However, I would consider Linux to be an innovation....

If you buy into the market shifting argument I've just made,  I'ld say
that the jury is still out on this one but it's looking pretty good at
the moment.

One risk I see to Linux is that changing the balance of power in the
market involves going through a phase of market instability as the new
technology is approaching parity with the old.  At this point, you
might think that the market is in a bimodal choice mode, but it's
actually in an open evaluation mode.  At such junctures, a third
offering can come along and significantly alter the market.

If I end up deciding to commercialize EROS somehow, it's in my
interests to support Linux actively in order to cause such a change
point in the market to come into existence.  Come to think of it,
that's an argument for free software I haven't heard anybody advance
here, and it's an approach that will appeal to Fortune 500 marketing
folks....

BTW, it's looking more and more like we are going to Mozillize
(Mozillify?  Mozzle?  Definitely not Mozzle.) EROS.  We will likely
use a more restricted license up to the moment where we ship our first
product and then open up the source base.  In our particular case
there is one potential competitor who has the technical know-how and
marketing inclination to scoop us if we don't ship before we open up.

>  > It is unlikely that anyone will make money selling open-source software
>  > they develop as if they are shrink-wrap software companies.  In fact,
>  > these days, it's probably pretty hard to make money selling shrink-wrap
>  > software if you're a new guy.
> 
> I agree with Kragen.  I can't find any reason to adopt the free software
> business model if I'm thinking about selling shrink-wrap software.

I'm not convinced about this.  If you look at the cost of the BOM
(bill of materials) in a shrink-wrap product, it's about $7 including
the manual.  The biggest variance comes from the cost of printing
manuals, which is mainly about length and quantity.

The conventional wisdom is that the software development is less than
10% of the value in the ultimate product price.  This suggests that
the customer shouldn't give a damn if the product is open source.
What they are buying *may* be usability, support, and commitment to
stability and compatibility.  This is one place where cheap innovation
becomes a potential liability, and there are a lot of ways to fail.

Once they purchase, they will stick with a given vendor -- look at the
situation in Linux.  I bought the RedHat release back at version 2.0.
At various points I've been tempted to switch to other releases.  I
stick with RedHat because it's a known quantity, because the patches
are quickly available (even though I don't use them most of the
time).  Mostly, though, I stick with them because the cost of
switching to a different release is quite painful -- I know how this
one works.

I do *not* stick with them because of the upgradability.  My
experience is that if I let the RedHat installer do the upgrade, I end
up with every package known to man installed and I have to clean it
out by hand -- which does *not* usually work, in spite of the benefits
of the package system.  My upgrade strategy is therefore to copy off
/home and a couple of critical files to another machine, reformat,
reinstall, and copy everything back.  I've gotten good at this over
the years :-).

The reason I make the point is that customer loyalty has much more to
do with perception than reality.  People ``know'' that RedHat is
easily upgradable, even though the upgrade mechanism isn't all that
good.  Software patches and updates work well, cross-release updates
do not.


shap