Other Insights

Understanding the hurdles to Open Source Adoption

Over the last decade and half, open source adoption has seen unprecedented growth. For example, since 2005, over 13,500 developers from over 1,300 different companies have contributed to the Linux kernel, a single open source project.¹

As more and more businesses adopted it, they gained agility, scalability, cost savings and accelerated business innovation. However, we have observed that our customers consistently face challenges when adopting open source across all business segments. In this blog, I will talk about the key adoption challenges which are as below:

• Bewildering technology choices
• Scarcity of end-to-end experts
• Complex vendor ecosystemsn
• Challenges in building a secure open source solution
• Ignorance on the capability of the product

Let us deep dive into each of these challenges with some examples

Bewildering technology choices

Learning to choose is hard. Learning to choose well is harder. And learning to choose well in a world of unlimited possibilities is harder still, perhaps too hard.

― Barry Schwartz, The Paradox of Choice: Why More Is Less

Every modernization program has a lot of technology products to choose from. Be it the API, integration, BPM, database or the microservices layer, there are many products, both open and proprietary, in the market. The challenge is to identify the right product based on what you need. The most common mistake that people make is to first choose the technology product and then decide how to use it for their need. In reality it should be the other way round, where you must first understand the need and then see which product will be able to address it.

I found two main reasons for choosing the product first. One of them is an excellent sales pitch from the product vendor and the other one is love for the technology. It is good to be enthusiastic about a promising technology but not at the cost of the architecture. In one of our engagements, it took us a lot of time and effort to explain to the client why the product they wanted to use was an unnecessary addition to their technology stack. Taking such decisions require good knowledge of a wide variety of solutions.

Scarcity of end-to-end experts

Full-stack architects are experts who have experience in designing solutions for enterprises across business domains. They bring best practices and experiences from different industry segments. Some of the industries like retail, energy and banking are far ahead in adopting open source technologies and they bring innovations and techniques to build excellent architectures, which can be gathered and leveraged by other industry segments. To be a full-stack architect, it is essential to be involved from the design phase of projects. Unfortunately, there are only a handful of such full-stack architects.

Complex vendor ecosystems

Thanks to the bewildering range of technology choices, any modernization program has a minimum of five products to choose from. This number is based on a recent survey that we did internally with our client base. We have seen this number go as high as eight to 10. In such a scenario where the interfaces are many, how does one ensure the development of a modern architecture at a good price?

Building a secure open source solution

It is a myth that open source solutions cannot be built in a secure way. In many of my client discussions, I come across people who believe that a certain database or an integration product is not secure. In such instances it is important to ask your clients, questions such as, how are they securing the database connection? Have they enabled SSL on the server? Most of the open source products that we work with have excellent security features but there is lack of knowledge and awareness on how to make these work. If you are using Kafka, you can SSL enable both the broker and the zookeeper. You can setup trust stores, key stores and Access Control Lists (ACLs) to ensure only the authenticated user is allowed access. You can restrict access at a very granular level. In some scenarios, we need to adopt the enterprise version of the product to be able to use the security features.

Ignorance on the capability of the product

Most of the new age open source products have been built to solve the problems of architecture which is distributed, requires scale and which might need to ingest high volume of data at an accelerated speed. The problem is that one needs to know how to use a product optimally to get maximum benefit out of it. Many old school practices are no longer best practices. We need to unlearn the old and learn the new. For example, I cannot apply relational concepts while building a non-relational model. One needs to know the various event-driven architectural patterns like event sourcing, event notification, CQRS and when to use which pattern. Whenever an element of doubt exists, it is recommended to do a pilot implementation of a portion of the architecture before embarking on a full-fledged implementation. In many of our engagements, we have done pilot implementations which usually last six to eight weeks, to convince non-believers.

Each of these hurdles can be solved with the right approach and best practices. Read my blog “5 Steps to crossing Open Source adoption hurdles” to know more.

¹https://www.linuxfoundation.org/resources/open-source-guides/participating-open-source-communities/