Subject: Re: FW: Why would I pay for Ximian software?
From: Ian Lance Taylor <ian@airs.com>
Date: 02 Jan 2002 23:43:29 -0800

"Perry E. Metzger" <perry@wasabisystems.com> writes:

> Ian Lance Taylor <ian@airs.com> writes:
> > There is really nothing ``mysterious'' about this--it's only
> > mysterious if you get your head so wrapped up in econ-101 that you
> > forget to look at what is really happening.
> 
> Remember, I'm someone who enjoys hacking on software I give away, and
> I do it regularly. I understand psychologically what's going on, but
> that's different from understanding the entire phenomenon well enough
> to try to keep a business sustained.

I guess I don't see why.  Your earlier message implied that you didn't
fully understand the incentives which led to the creation of open
source software.  Connect the dots for me: why would a better
understanding of those incentives help sustain your business?

From your point of view, you have a quality piece of software, and you
have some very strong developers.  You can predict that the software
will continue to improve (apart from whatever resources Wasabi adds to
it), and you can predict that you will be able to identify strong
developers in the future without having to train them yourself.
Should those predictions fail, you may be in trouble, but I think you
have to make them and I think they will come true.  As far as
sustaining your business is concerned, I don't think it matters why
they will come true.  If you understand psychologically what is going
on, then I think you know all you need to know.

Thinking theoretically rather than practically, I'm not sure how far
you can get with modeling volunteer work on free software in an
economic sense, although Stephen probably has some ideas here.  There
are so many different motivations for working on free software that
unless you want an extremely complex model, I think you might as well
just say something like ``for X% of the population of programmers, if
they have a salary higher than [some distribution], they will spend Y
hours on free software.''  Ideally you would use historical data to
work out the numbers, but there probably isn't any real data, so
you'll have to make it up.  This is more or less how some models
handle church tithing, which is a pretty significant use of income for
some percentage of the population.

There is a business angle in figuring out how to sell your free
software project to the pool of free software developers, since it's
pretty clear that there is more free software work to be done than
there are people to do it.  But I think in your case you've pretty
much got that licked.


> > I would guess that for a company like yours, the key is to find an
> > area in which your expertise in NetBSD is worth much more to the
> > customer than the time it takes you to solve the customer's problem.
> 
> And we believe we have such areas, but I must admit that the situation
> is sometimes disheartening. One runs into customers who more or less
> say "why should I pay you to fix a problem for me when if I wait long
> enough you may fix it for someone else for free."

Sure, we saw that at Cygnus all the time.  The best response I know is
``how much are these problems costing you today.''  If the answer is
``nothing,'' then that person is not your customer.  Tell them to call
you when they run into a problem which they need fixed right away, and
mention that your emergency fix fee is 100 times greater.  Then move
on to the next prospect.  As the saying goes, sales is a numbers game.
The faster you can eliminate a prospect who won't buy, the sooner you
will get to one who will.

> Even in the case of
> those who will pay, if our code was proprietary, some such people
> would be willing to pay me far more for it than they will if they have
> no restrictions on it at all. The irony of all of this is not lost on
> me at all.

I see no irony.  Customers who are not already in a panic always have
price objections.  Since you are mentioning the fact that your
software is free, that characteristic is a natural objection.

When I took the Dale Carnegie Sales Advantage Course (I strongly
recommend a sales training course for everybody who goes on a sales
call--I was happy with Dale Carnegie but I'm sure there are other good
courses) one of several techniques they taught to answer an objection
was to say ``what you say [as an objection] is true, but it is
actually to your benefit because....''  In this case, you could, for
example, say ``it's true that the code has no restrictions, but that
is actually to your benefit because you get the advantage of free
development across the net.  When you pay a proprietary vendor, you
are covering their development costs as well as everything else.  With
us, more of your money goes into testing and quality.  We can deliver
higher quality goods for less money, thus helping you build a better
product.''

> I'm not by any means saying I'm about to abandon our current business
> model, but it is obvious that there are features of economic problem
> here that are worth exploring in an economics sense.

Economics can in principle describe anything, but in practice I
believe there are a lot of things which it doesn't help much with.  As
I've argued before, though not recently, I think the free software
community is too small, too diverse, and too idiosyncratic to be
susceptible to useful economic analysis.  (I mean the community aside
from the existing free software businesses, which can be analyzed like
any other business.)  I expect that Stephen disagrees.

> > Perhaps they will pay hundreds of thousands of dollars for something
> > you can do in a couple of weeks but they can not do at all.
> 
> In some instances they will. The issue is deeper than that.

If you can characterize the set of customers who meet this criteria,
and focus your efforts on finding customers like that, then you are
80% of the way toward a successful company.  That's certainly what
made Cygnus successful.  In particular, it's a good fit for the
Geoffrey Moore ``Crossing the Chasm'' model of growing a company.

Ian