The Adoption-Led Market

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 to a mesh
topology for society1 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!
[Next: Adoption-led is not shareware]
1. Described in more detail in Adoption-led as a force of nature
Comments are closed for this entry.





Posted by webmink
Hello. I liked this idea well enough that I thought to forward it to the leader of the little start-up that I work for, and then I decided to instead just post it to the public mailing list for our open source project.
http://allmydata.org/pipermail/tahoe-dev/2008-March/000410.html
I also included mention of the famous Asutralian Fruit Bats.
Posted by Zooko O'Whielacronx on March 03, 2008 at 10:37 AM PST #
Posted by OpenLogic Blogs on March 12, 2008 at 12:24 PM PDT #
Spot on. My "introduction to XML" slideset for years has answered the question "Why was XML successful" with the answer (in part) "Because developers were able to deploy it without first having to argue a business case".
Posted by Michael Kay on March 20, 2008 at 05:26 AM PDT #