Across countries, almost every government function and government funded organization has made bold statements and commitments towards the open source movement. They believe in not promoting or getting tied down to proprietary and expensive solutions to enable processes, citizens and overall functioning of the government. The belief is that tax-payers’ money should be saved to give the biggest bang for the buck. So forget the hugely popular operating systems, office productivity tools, virtualization, management solutions, and almost everything in between, that does not have the open tag. This is a topic that has taken a lot of vendor and system integrator stress levels north in the past.
The luminaries interacting with me had a lot of experience with a variety of open source solutions. We discussed open versions of office productivity tools, open source virtualization, learning management systems, database solutions, operating systems, and many more. They advised that most open source solutions had been adopted by quite a few large IT companies to create their version, and bundled them with charged support services. Thus, corporate entities should not have concerns around support. They work equally well as compared to commercial solutions; maybe in a few cases, the user interface may not be as user friendly—but that should not deter the strong hearted to push its case through.
There were too many questions in my head, so I started what appeared to be an interrogation. Can such solutions still be called “open source”, or should the nomenclature be “originated from open source”? How does the ROI or TCO model change from pure open source to adopted open source? Are these deployed for critical or core functions as well or they are still around the fringes? What is the level and quality of support from either the open source community or the vendors? Did they struggle with or face any interoperability issues? How did they manage the infrastructure and applications? Were there any performance or scalability issues? And so on I kept on rambling (to the group’s embarrassment), which started looking uncomfortable with most answers having a “conditions apply”.
The big realization was that the criticality of applications, infrastructure, service levels, performance parameters, expected resilience, and turnaround times were all dissimilar to what the enterprise CIO is typically expected to deliver. Even in such scenarios, it was evident that critical applications were procured from, and deployed on, commercially available environments—though not always discussed in gatherings. Quiet acknowledgements were also provided on the ROI and TCO cases—as not been significantly attractive for open source solutions.
The reality is that for almost every enterprise solution, there exists an open source alternative. The adoption and usage of these has been to typically support non-core or non-critical activities depending on the industry segment (including government departments and public sector enterprises).
When business depends on any technology, the risk appetite is low to negligible. Is this likely to change as the numbers increasingly inch up for open source solutions being deployed?
Well, my belief is that we will continue to see this divide for a long time. Everyone will talk about it—some will deploy in non-core functions, and the rest will debate.