Barriers to FOSS adoption and the role of the provider

A couple of weeks ago I posted a writeup on why organizations can’t afford to ignore open source anymore, the write-up was based mainly on my own experiences and knowledge I came to possess as a result of working for a product company that is built around an open source business model. Towards the end of the writing process, I felt there is a lot more that can be said about FOSS, especially concerning adoption and the role providers play in assuaging adoption pains.

....

As discussed in the previous post[1] the drive for Open Source adoption in organizations can come from the industry or broader technological community manifested as ground level traction by the in-house engineers. This driver was looked at by Miralles, Sieber and Valor. Two types of technology adoption views were considered in their research. These two views being,  technical push; a deterministic view, where the decision to adopt is mediated by an accumulation of factors such as technical attributes, the cost of ownership and ability to transition into open source. Organizational pull; factors intrinsic to the organization such as organizational capabilities, vendor-organization match and psychological factors of the decision maker. The research found FOSS to have a greater technical push compared to its proprietary counterpart, in all areas except lock in(ease of transition) but in most cases, it was beaten off due to low organizational pull when it came down to the decision to adopt(2006). This study was done a decade ago, it would be interesting to see if the strength of correlation between the technical push and the decision to adopt has changed over time, looking at the current technological landscape one can assume it has gotten stronger.

The technological superiority of FOSS has been discussed in countless research papers and countless more web articles. Furthermore, even if the strength of correlation between technical push and decision to adopt has gotten stronger from the time the research in question was done, common sense dictates the factors looked at in organizational pull should have a stronger relationship with the decision. The decision to adopt therefore should be made by assessing the potentialities through both views. This is where I feel FOSS is lacking, its ability to convince that it is the right choice regardless of the view one adopts when assessing it. The purpose of this post is to point the reader on how the shortcomings of FOSS can be circumvented through the services of a provider.

Before we can address how a provider can address the drawbacks of Open Source and other barriers to its adoption, we should have a better idea of these drawbacks and barriers. Hauge et al found Lack of support and expertise, difficulties in selecting the right OSS products and ambiguities in liability as major barriers to adoption.(2010) Morgan and Finnegan found compatibility issues, lack of expertise, poor documentation and lack of roadmaps and other documents pointing to strategic direction of Open Source projects as technical drawbacks. Moreover, the researchers found a lack of ownership, a lack of support and difficulties of finding right staff/competencies as business drawbacks.(2007) As mentioned in an earlier paragraph, Miralles, Sieber and Valor highlighted the following three organizational barriers. Organizational capabilities; concerns regarding in-house expertise on the technology and the logistical/operational constraints of building up expertise. Network externalities; the indecisiveness that one might feel due to the phase of evolution in open source. Psychology of decision makers; factors such as the impression adoption decisions of peers have on your own and other individual differences.

Providers such as Red Hat and WSO2 build value on top of FOSS by addressing these shortcomings and drawbacks, providing products that are better tailored to enterprise needs. Providers that have adopted similar open source business models provide paid auxiliary services on implementation, support, maintenance and consultation. These auxiliary services may be availed to a great extent by any organizations considering Open Source adoption but discouraged due to its perceived drawbacks. 

Lack of expertise,

Product expertise will be needed by organizations at various stages of their technology adoption and transition journeys. The specific needs pertaining to expertise at one point of the adoption journey can differ from another, therefore organizations evaluating providers should look into the potential provider's ability to cater to these varied needs.     

Providers should be able to address concerns about an organization's in-house expertise with focused on site consultancy services, documentation, and other training resources. Furthermore, The providers should possess the competency to address concerns that may come about at different points of adoption that are specific to the organization's existing technological infrastructure. Lastly, the providers should have dedicated channels(such as support channels) to disseminate the expertise.

Organizations, in turn, can put programs in place to cultivate in-house expertise of the products, leveraging the documentation and other learning resources provided as value additions by the providers.      

Compatibility issues and concerns of lock-in,

Organizations may get discouraged by possible compatibility issues between FOSS and their existing technological backbone. Though this is a concern that is common to both open source and proprietary software in adoption and transition, in the case of open source, the access to the information needed to decide on compatibility may be hard to come by. Therefore, organizations should be able to get the assistance of the providers when they are evaluating the possibility of adoption. Dedicated channels should exist for organizations to access the information from the providers. Organizations should opt for providers that assist in this evaluation process, some providers may even provide specialized services catered for this very requirement.   

Considering the comparatively low cost of ownership, It may be worthwhile for some organizations to purchase lower tier support/assistance services purely for compatibility evaluation. Organizations may avail these services to run pilot projects with the products, the benefit of such pilot projects are twofold as they will build up in-house competency on the technology.

Some providers may even offer their products as SaaS offerings, organizations evaluating OSS may use these services to get a better idea of functional compatibility of the products. Though it should be noted that at times the functionality of such SaaS offerings may be cropped to improve suitability.    

Concerns with liability and longevity,

As FOSS is maintained by a community unbound to organizational goals and needs, many organizations find liability as a barrier to adoption. Therefore, organizations should expect the providers to address these liability concerns with contractual obligations such as SLA's. Organizations should look to dedicated L1, L2 support from the providers.

As with proprietary software adoption, it makes sense to place the responsibility for the adopted technology between internal resources and external resources of the provider. Some providers may be able to provide dedicated agents that can integrate into the in-house teams to address concerns on behalf of the organization with the provider.

It makes sense to go with a provider that has been in the domain for a considerable length of time and proven domain expertise. Furthermore, organizations may look to the provider’s product strategy through product vision documents, roadmaps and such when assessing longevity.   

In summation, it is my personal opinion that many of the barriers to adoption that prevent the organizational pull favoring FOSS can be addressed with the assistance of providers, with a thought out adoption plan on the adopter's side and the backing of the right provider. That, those organizations that embrace Open Source as discussed in this post would have an advantage over those who have opted for proprietary solutions.

List of References

Hauge, Ø, Cruzes, D. S., Conradi, R., Velle, K. S. and Skarpenes, T. A. (2010) 'Risks and Risk
Mitigation in Open Source Software Adoption: Bridging the Gap between Literature and
Practice' IFIP Advances in Information and Communication Technology 319(1), 105-118

Miralles, F., Sieber, S. and Valor, J (2006) 'An Exploratory Framework for Assessing Open
Source Software Adoption'. Systèmes d'Information et Management 11 (1), 85-111

Morgan L., Finnegan P. (2007) 'Benefits and Drawbacks of Open Source Software: An
Exploratory Study of Secondary Software Firms' The International Federation for
Information Processing 234(1), 308-311