Why Adoption-Led Is Not Trialware

In response to my posting Adoption-led is Not Shareware, IBM's Savio Rodrigues continues the exploration of the adoption-led concept in another blog entry. As an explanation of his view that "adoption-led" is a synonym for "shareware/trialware" he has modified my original explanation to read:

In this approach, developers select from available Shareware or Trialware 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 the creator of the Shareware or Trialware 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.

Savio is correct to note, as Zack does, that Free software is easier to evaluate. The trap Savio is falling into here is to go no further and to be focus only on the procurement of the software. That's a natural reaction given the dominance of procurement-driven thinking, but it hides the natural progression of software in an adoption-led context. What matters is not the freedom to procure the software, but the freedom to adopt it. The two are only the same in a procurement-driven world.

Freedom to Use

No Fun

With trialware/shareware, one is only free to use the software for evaluation purposes. Once one switches to production, one is compelled to pay for a license to the software in order to take it into production. This causes significant problems in an adoption-led context:

  • It frequently means that the features needed for production are not present in the software in use.
  • It erects a barrier between evaluation and deployment that most likely involves a switch of versions, resulting in a need for re-evaluation. For example, if the evaluation was on Fedora, to go to supported production the system will need to move to RHEL, since Red Hat do not support Fedora (as far as I know).
  • It erects a payment barrier in the adoption process, one which is located at an arbitrary point known only to the vendor's legal team. Does one have to pay between evaluation and development? Between development and pilot? Between pilot and initial roll-out? Between initial roll-out and full production? Who knows?

True Free software (software with the freedoms left in) doesn't have these problems. There are no artificial barriers or toll-booths on the path to deployment, and adoption is a process that can be conducted under the control of the adoption team. As they progress they can decide at each stage whether to go buy a subscription from a vendor to meet their sustaining needs, or whether to engage experts from the open source community around the code to do it, or whether to just absorb the risk themselves.

This is the key to the adoption-led approach. It's about adoption of software, not about the procurement of software. It puts control in the hands of the adoption team. It's about freedom - freedom from vendor control, freedom to use the software how you want.

[Previous: Adoption-led as a Force of Nature | Next: An Adoption-Led Business Model]

Comments:

Post a Comment:
Comments are closed for this entry.
About

Thoughts and pointers on digital freedoms and technology markets. With a few photos too.

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today