Subject: Re: FW: Why would I pay for Ximian software?
From: Tom Lord <>
Date: Wed, 2 Jan 2002 20:48:44 -0800 (PST)

       If you go back to the "tragedy of the commons paper, you will
       see that it does not apply to software ... very precisely
       because of these qualities you mention that make it naturally a
       public good.  The tragedy of the commons occurs when the
       ressource made public is rivalrous.

The bits in a distribution are not rivalrous.  The "commons" is the
engineering infrastructure which produces, maintains, and deploys the
software, not the software itself.  Proprietary software companies
have figured out how to administer this resource.  FSBs, for the most
part, have not.

The problem seems to be that FSBs are selling what they know how to
sell, and what their customers know how to buy and receive, rather
than what they ought to be transacting over.  For what they *are*
selling, prices are naturally low, so the engineering infrastructure
becomes "over-grazed".  Some FSB execs even try to valorize this
situation: arguing that underfunding engineering is an example of

FSBs sell things like boxed sets, custom development, and support
contracts.  Those things have very limited value in isolation -- so
FSBs have trouble collecting enough money to sustain the operations
that should be going on behind those points of contact.

Proprietary software companies sell the same items, but get to charge
much more for them through licensing restrictions.  That's ok though
-- its just a facade.  The *value* customers get from the proprietary
software companies is a relationship (and the customers know this and
count on it).  Sales and engineering teams visit the customers
regularly -- study their operations and needs; provide ad hoc advice
and assistance.  They feed-back what they learn to the engineering
organization.  Would customers benefit from a new feature?  Nobody has
to contract for its custom development (how inefficient!).  Rather, it
gets paid for out of the general pool of license fees: customers get a
heads up that its on the way, an invitation to help review the design,
and finally it simply shows up in a future release.

One solution here is to sell the relationship itself, not (usually)
the products, the formal support, or each separate new feature or
port.  Sell the mutual site visits.  Sell the informal, friendly,
engineer-to-IT department email assistance.  Sell the newsletter that
describes what's in the engineering pipeline and how it can have
positive impact for customers.  Sell the data sheets that characterize
the testing effort so that customers can use that information for risk
assessment and planning.  Sell the right to review designs and
participate in R&D.  For customers who themselves are doing software
engineering, sell them advice, design review, coordination with their
industry siblings, mediated cooperation with their competitors over
the non-contentious issues, and help contributing back the changes
they make to the public code base.  Sell these mostly-intangible
things at prices close to what you could get via license fees and
concentrate on generating the bulk of cost savings to customers by
giving them the much better software and support that we know open
source processes can produce.

Make engineering teams directly responsible to (multiple) customers
and put customers directly in contact with multiple teams.  Make the
multi-metric measurement of value delivered an open-ended, ongoing
effort that is a regular part of the customer relationship.  Design a
rational engineering process with strategic, tactical, and custodial
components.  Involve customers in planning the future and for gosh
sakes, help them to recognize the value of advanced, speculative,
risk-ridden R&D.

A nice side effect: there's not much of a free rider problem when what
you're selling is a deep relationship to a powerful engineering