Subject: Re: rocket science
From: Laurent GUERBY <>
Date: Thu, 03 Mar 2005 13:41:59 +0100

This is a fine example of economists blindness when it comes
to software real use and needs in the real world.

Wherever there are significant risks involved in the use of a particular
piece of software, the aspect that quickly becomes the most important is
the support service behind the software. How long until the bug (all
software will have bugs) is identified, it's importance evaluated, a fix
or workaround is proposed and then a way is found to deploy it.

The proprietary model impose a monopoly on support services which is
genrally bad as everyone knows, plus reduce the software developper
incentive to provide a good service since the main revenue is paid
upfront for the software license, inequation between needs and
revenue model.

Those two factor *destroy* the price signal on support service
perceived needs and quality (on both client and customer side).

And proprietary software creates a rational incentive to keep the
quality low enough so that purchasing the license for the next version
of the software is perceived as having enough value to justify the costs
while not compromising the market share of the software.

Free Software doesn't have this problem, and *restores*
the price signal, though not on the supermarket CD price, but on the
support service price. And restores competition too, so efficiency in
this market, and solution to the proprietary software "commercial" end
of life problems.

As an example, still GNAT the GNU Ada compiler. The most expensive
"product" (software cost is zero, software support > 0) you can buy from
AdaCore is the most limited version of the compiler toolchain, the one
that comes with no useful libraries at all. That is because it is
used for safety critical software development market where all
running code must be certified, so including external code in the form
of compiler libraries doesn't work certification wise.

Also AdaCore does sign long-lived (several decades) support agreements
with its clients, typical in this market too.

Another smaller example, not in the critical software market, but
in the desktop world which may be more familiar to economists. 

Often someone asks me wether he should use Linux or Windows. I ask them:
who do you call when your software doesn't work. This is of course never
the so-called "customer support service" of high profile proprietary
vendors? Then I tell him go ask this person with what software he feels
more confortable with, or may be find another person. Why? Because
support is the critical information piece in choosing software, and the
price signal has been destroyed for so long people don't even remember
it even though they use it all the time and it seems "free" in the form
of personal contacts.

Also when someone at home or work asks for a proprietary software
problem, I now always answer "you paid for the software license, ask the
vendor support" which always make people laugh as a good joke. Of course
they "friendly" ask someone else for a solution, and not the vendor.


On Wed, 2005-03-02 at 17:05 -0500, Marshall W. Van Alstyne wrote:
> At 02:34 AM 2/27/2005, DV Henkel-Wallace wrote:
> >The question is: I would not be surprised (not on any evidence but off the 
> >top of my head) that Free Software Businesses can handle these risks 
> >poorly, since they don't get valid economic signals about this.
> >
> >Thoughts?
> Yes, speaking as the token economist here, there's a really good econ. 
> insight in this observation.
> Prices convey information.  It's this implicit value information that 
> causes (profit motivated) suppliers to generate more of a resource when it 
> comes at a high price and produce less of it when the price is low.  Absent 
> information about the relation between demand and price, there needs to be 
> some other signal about how to allocate resources -- and programmer time is 
> a really valuable resource.
> So one issue is identifying good alternative sources of such information 
> when the core contribution is free.
> MVA