Subject: Re: FW: Why would I pay for Ximian software?
Date: Thu, 3 Jan 2002 14:11:27 -0500

Perry Metzger writes:
> Ian Lance Taylor <> writes:
> > "Perry E. Metzger" <> writes:
> > 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.
> Not quite. I more or less noted that the conventional theory of public
> goods doesn't work, but neither does an analysis that fully ignores
> issues such as "free riders" -- we don't yet have a reasonable
> economic model of what's going on, which makes it difficult to make
> reasonable predictions of behavior. This is a significant problem if
> you're trying to run a business.

What kinds of things would you expect a reasonable economic model to
tell you?

> > Connect the dots for me: why would a better understanding of those
> > incentives help sustain your business?
> As just one reason it would be valuable: understanding the economics
> well would mean one could make predictions, and business planning
> requires the ability to make reasonable predictions (if only very weak
> ones) about how economic actors will behave. The actors I'm most
> concerned about are not the developers but the consumers, and I'm
> especially interested in problems like information effects.

Separating developers from consumers in free software is IMHO a
mistake.  A key principle is that the consumers are also your potential
developer pool.  We are talking network effects, content is both
produced and consumed by the same people.

> As one example, one could easily imagine that if a group of companies
> all needs a feature one could get them to pool their resources to get
> the feature developed, but in practice this never happens. I suspect
> this is because of information cost effects -- it is easy in the case
> of proprietary software, because they are in effect pooling their
> resources by making the purchase decision. However, in the case of the
> open source development situation, there are a number of issues,
> including lack of knowledge about the timing and quality of the
> software development process and the costs of simply organizing the
> pool.

The biggest single issue I would think is the cost of deciding whether
what someone else is talking about is what you want as well.  As every
programmer has painfully experienced, nailing down a specification for
just one customer can be incredibly painful.  When the specification
has to be decided between 2, it gets much more painful.  And as the
number of people arguing about what is wanted goes up, the effort
required to decide what is wanted can easily scale quadratically.  And
likewise as the desired system grows in size, the complexity of
figuring out what it looks like grows faster than linearly.

The general solution to this kind of complexity issue is modularity.
You want software features to be divided into components that can be
understood and developed, which can be pieced together into larger
components that people can pretend are units.  And then people swap
units.  So people can get solutions when the solutions can be described
by all involved as simple units, and those units tend to get developed
in smaller units as well.

For a better understanding of issues with managing communications I
strongly recommend reading the Mythical Man-Month.  What Eric Raymond
described working in the free software world is a way around this
problem for evolving complex systems over time.  But the path around
requires that people be communicating in digestable and independent
chunks.  (Often with the eventual path forward being found by multiple
people trying different approaches and then letting them compete.)

> Such effects are conventionally invoked to explain the reason we have
> firms in the first place rather than much looser pools of contractors
> -- because the costs of setting up the web of relationships in the
> pool of contractor case exceed the benefits, so it is easier to get an
> in house monopoly provider of a service with known quality and cost
> than to contract for it. As information flows improve and the cost of
> setting up relationships drops, we end up with much smaller
> organizations being viable, and in many ways this has happened. Some
> industries (like filmmaking) have actually become webs of contractors,
> and certainly the largest firms in the world have shrunk dramatically
> in size. IBM is a fraction of the size it was at its peak, although it
> produces far more than ever before.

I maintain that one of the best ways to reduce the cost of
relationships is to have standardized components that both sides can
talk about when communicating.  When people start off speaking something
close to a common language, it is much easier for communication to

Indeed I think the phrase "information flows" is seriously misleading.
Data flows.  Information is comprehended, integrated and then acted on.
Barriers to comprehending, integrating and then acting on information
are a significant part of costs in anything involving software
development.  To understand why things happened in technology as they
did (and to place bets for the future) you often need to pay close
attention to this issue.

For instance as I have said before, I think it is no accident that CPAN
developed around Perl - a language which doesn't encourage

> The open source community is in many ways an example of this issue of
> information effects being reduced as a barrier to participation. The
> fact that open source is possible at all is because of the low cost of
> becoming a participating developer that the internet has created --
> before the internet, you couldn't have had the efficiencies we've been
> able to achieve now (although there certainly was open source software
> before, it didn't operate on the modern scale).

As you say, open source is only viable when you have a low cost of
sharing and communicating.  The ability to communicate through TCP/IP
is far from the end of the story when it comes to reducing those costs.
For a random influential paper on how to do so try Worse is Better, at

> Can we similarly reduce the information costs of participating in
> pools sufficiently to allow better transfer of resources from
> consumers to producers? I don't know, but the entire area is in
> desperate need of study.

If participating in pools means having multiple users agree on a
feature then getting it created, I am dubious about the potential for
succeeding for the reasons I gave above.

But if these pools are peer to peer pools with many in the pool having
the capacity to produce and consume, then yes we can find ways to
reduce costs so that there is more value to being in the pool.  Whether
you can make a business from trying to *run* the pool is more
questionable.  But there are plenty of profitable businesses who find
value in being in the pool.