[tahoe-dev] procurement-driven vs. adoption-led markets

[zooko]

Folks:

Simon Phipps's job is "The Open Source Guy" at Sun.  I usually read  
his blog.  I liked today's entry, and thought Peter might like it,  
then I thought other people might, too, so I'm posting it here.

http://blogs.sun.com/webmink/date/20080303

The full article is quoted below:

Regards,

Zooko

"""
Monday March 03, 2008
The Adoption-Led Market
[INSERT PICTURE OF ASUTRALIAN FRUIT BATS HERE]

I've previously spoken of payment at the time of deployment rather  
than at the time of selection - Software Market 3.0 - as the defining  
characteristic of open source business models. As I've spoken about  
this in all sorts of contexts, it's become apparent that this is just  
an aspect of a deeper trend, which in some ways relates to Greg's red- 
shift/blue-shift idea.

Traditionally, the process of acquiring software has involved a  
request for proposal from vendors against a customer specification.  
Vendors then make proposals, submit prototypes, contend for business.  
In smaller bids, an evaluation team considers trial versions, makes  
evaluations, makes proposals to management. Eventually software is  
selected and paid for. At that point, adoption can begin. Every user  
of software in this model is also a customer. Software selection is  
something of a matter of faith in the procurement-driven market.

    Defining Adoption-Led

The switch for a mesh topology in society has led to easy access for  
everyone to Free software created by open source communities. The  
result is an emerging approach which is rapidly spreading for smaller  
software projects and in my view is the future of all software  
acquisition. The emerging approach is an adoption-led market.

In this approach, developers select from available Free software and  
try the software that fits best in their proposed application. They  
develop prototypes, switch packages as they find benefits and  
problems and finally create a deployable solution to their business  
problem. At that final point, assuming the application is  
sufficiently critical to the business to make it worthwhile to do so,  
they seek out vendors to provide support, services (like defect  
resolution) and more. Adoption-led users are not all customers; they  
only become so when they find a vendor with value to offer.

    Consequences

Written down like that, it seems pretty obvious, but having a name  
for it – an adoption-led market – has really helped pull together  
explanations and guide strategy. For example:

  * In a procurement-driven market you need to go out and sell and  
have staff to handle the sales process, but in an adoption-led market  
you need to participate in communities so you can help users become  
customers.
  * In a procurement-led market you need shiny features and great  
demos, whereas in an adoption-led market you need software that is  
alive, evolving and responsive to feedback.
  * In an adoption-led market you need support for older hardware and  
platforms because adopters will use what works on what they already  
have.
  * Adoption-led users self-support in the community until they  
deploy (and maybe afterwards if the project is still “beta”) so  
withholding all support as a paid service can be counter-productive.

Naturally now I have a new hammer everything looks like a nail, so  
expect to hear more of this if you talk with me!
"""