Subject: Re: A few here may have an opinion on this
From: Tom Lord <lord@emf.net>
Date: Mon, 28 Oct 2002 16:16:16 -0800 (PST)



	chrismeade:

Made what I think are some really good points which I'd like to try to
amplify and expand upon.

	The real issue is how best to create value with 
	software.  In the proprietary model, it's pretty 
	clear how a business creates value because it shows 
	up on the books as license revenue and profit,

Correlating with that is the observation that there are so many
different kinds of licenses, each (at least in intention) aimed at
modeling what lma has been calling the "customer value" of the
software.  Proprietary licenses are legally enforcable [*],
product-specific accounting standards for customer value.
CPU-licenses for server software; seat licenses for productivity apps;
even MSFT's recent experiments -- each attempt to measure customer
value and link it to price.

That creates an interesting, perhaps problematic feedback.  It is the
nature of software (and digital information generally) that the sum of
customer value across the market often astronomically dwarfs the cost
of development.  Successful proprietary companies wind up with a lot
of money in the bank (unless they're very progressive about paying the
damn dividends, which (am I right?) none of them seem to be).  If the
market were a person, it would be saying "Thanks for the work of those
500 people.  Next, please see what you can do with 10,000 times that
much."


	In the OSS model, you give away the license which means little
	or none of the value of the software shows up on your books;
	it instead shows up as higher profits elsewhere in the
	economy.

Up2date and Red Carpet are first cuts at value-based pricing.  As with
proprietary licenses, they define an accounting standard.  As I said,
there's all kinds of problems with these specific mechanisms -- RISKS,
questions about legality, and a general "miss" on making efficient use
of the advantages of free software to name a few -- but they at least
do attempt rational pricing.

Apart from those models, there's distributions and support.  The price
of the former is essentially 0 [**].  The price of the latter is just
the cost.  With these models, if the market could be
anthropomorphized, it would be saying "Thanks for the work of those
10,000 people.  Next, please see what you can do with 10 or 100, plus any 
slaves you can con to play along."

A large part of the problem is that customers don't understand what
they're buying when they buy software.  They don't seem to understand
where it comes from, what it costs, whether or not they are buying
well-engineered infrastructure, what a healthy software ecosystem
would look like, or why it would be valuable to support one.  If
customers could be magically enlightened, they'd _voluntarily_ engage
in value-based accounting/price-setting, keeping their eye on the size
of total revenues compared to the needs of the development community.
The efficiencies of free software would assure them lower prices than
they'd have to pay for proprietary software (especially from The
Monopolist), but they'd happily pay higher prices than they do
currently.

It is my sense that, in the Golden Old Days of FSB, much of the
discussion focussed on people proposing and knocking down kinds of
products that FSBs might offer.  In retrospect, I think that could be
partly interpreted as a search for products that would support legally
enforceable, value-based pricing ("Is there a clever hack, here, that
would let some of become the free software bill gates?").

Maybe it's time to renew that question.  The goal is to find products
that support a legally enforcable pricing mechanism in which:

	1) There's a sustainable level of investment in free software
	   r&d, across the board, and across all practical time
	   scales.

	2) Most customers are charged in relative proportion to the
           value they receive. [***]

I happen to think that the renewed question is pretty easy to answer:
customers should be paying to preserve invariants.

What kinds of invariants?  Software performance metrics; preparedness
metrics; correctness metrics, responsiveness to customization
requests; and, especially in IT, metrics of productivity gains and
user satisfaction in customers' businesses.

We (rightly) freak out and cry "foul" when people propose, for
example, software publisher liability legislation.  Ok, that's fine,
but the guarantees and liabilities customers want _can_ be provided
privately (an analogy to the property mgt. industries comes to mind).
That can be done through legally enforcable contracts for which the
price can be set so as to satisfy the two goals enumerated above.

Here's the hard part: what does it look like from the engineering
perspective?  If we're going to serve customers with invariants, what
does that imply about how our software is architected and engineered?
What is the _form_ of these new products and how do we achieve them?
(It's my attempts to answer those questions that led to my promoting
such diverse things as the virtues of aggressive source
mgt. technology. and the virtues of the Emacs architecture for user
interfaces.)

And, a little bit of a non-sequitor:

     Now back to the public policy point.  I want the 
     government to promote policies that increase overall 
     wealth in the US.  

I want the congress to live up to its constitutional mandate to
promote progress in the useful arts and science.  The blessings of
liberty and the general welfare ought not to be conflated with GDP.


-t



[*] "Proprietary licenses are legally enforcable":

    For now.

[**] "The price of [distributions] is essentially 0":

    As an anecdotal example, I once met a handsomely funded
    start-up that decided the way to deploy gnu/linux for 50
    developers was to mail order _a_ boxed set.


[***] "Most customers are charged in relative proportion to the
       value they receive."

    That start-up I mentioned in [**] were just being obnoxious.
    On the other hand, less handsomely funded efforts, npos, private
    citizens, businesses in a down-turn, etc -- _should_ (ideally)
    be given a free ride.   That's one of the big advantages of 
    free software -- you can be nice to people with whom you want to
    foster a long-term relationship.