How do You Support Open Source?
One of most critical decisions to make when using open source is how do you support it.
Without a doubt the entire software industry has changed, and the use of open source software is now part of almost every company’s business strategy.
We all like free, and many people will state that open source is really free. Others might talk about open source software is really more of a “freemium” which wikipedia states is something provided free of charge, but money (premium) is charged for additional features and services.
Why, if open source software is free, would I need any additional features or services? Almost every developer I talk to sees the value of leveraging open source software, and I myself leveraged it in my previous role as I led a technical team on a transformation journey to agile and devops.
My team had may spirited debates on do we really need to purchase support for the open source or not for our environments. It always boiled down to:
- What is the impact to the business if the service running on this goes down?
- How do we provide reliable support to fix any issues to allow quick restoring of the service which runs on it?
- What risks are we taking about how well this open source will be maintained if the open source community shifts direction and the contributions significantly drop off especially security enhancements?
The issues can come from many different areas with the primary ones usually being centered around security, quality assurance, and life-cycle maintenance of the ecosystem of the collection of open source software.
While developers tend to love open source software, the business application teams want to ensure that when things break there is someone committed to quickly fix the issue and restore the service. Business owners, especially those with production mission critical applications, are typically willing to pay for some level of enterprise support. Each business has to decide: do they staff up to do self support (which can be a expensive and risky proposition), or do they buy this external support from a vendor.
Make no mistake that self support is not free as it involves several people who are highly skilled across several areas. Developers need to fix issues quickly as mission critical applications cannot wait for a community response to a quickly needed fix to the code. Security people need to subscribe to Common Vulnerabilities and Exposures (CVE) feeds to understand what new security issues have been identified, and then they must quickly assess what is the impact is to their environment, and then determine how fast the patch must be applied across their production environment. Governance people need to ensure the business as a whole is not picking various different open source software for the same functions across various business units or staying with open source which has lost momentum and contributions. Operations people must develop automation to execute the implementation of whatever changes are need to get back into compliance. Regulatory compliance people in regulated industries need to ensure they have documentation, and auditors need to allow their business to avoid exposures and potentially fines.
For open source packages where enterprise support is available, it simply comes down to comparing the total cost and risk of self support versus the total cost of acquiring 3rd party support.
Companies like Red Hat offer subscription based support from the operating system up through Kubernetes and a common set of services which are needed to actually have a production application platform to run your business applications.
Red Hat #OpenShift for example offers security (security response team that identifies, tracks and resolves issues, image scanning, integrated and authenticated image registry, single signon, and many other features). #OpenShift offers SLAs, defect escalation, end of life policy management, and ability for clients to file request for enhancements. Openshift also addresses many other key enterprise level needs including: Consulting and training; quality assurance including testing for performance, scalability, availability, and reliability; Ecosystem support along with certifications; Dynamic storage provisioning for persistent volumes; Infrastructure including edge routing and SDN capabilities; and Monitoring and Telemetry.
In the end, most businesses I talk with or read about are willing to subscribe to 3rd party services for their open source software and that allows them to free up the developers, security, compliance, and operations teams to focus on improving the client experience through developing new applications and services versus support an application infrastructure and ecosystem.
My experience with clients who start out running their own Kubernetes based ecosystems has been it can initially work when there is a couple of clusters in development. Staffing and training 5–10 people in large organizations is feasible, but as the workload shifts to production, as it scales to dozens or hundreds of clusters, and as things break in production, those Do It Yourself, Build Your Own (BYO) clients will quickly realize it is more productive and cost effective to consume the platform versus own the platform.
From Cloud Engagement Hub perspective, I fully endorse clients to embrace open source software on their Journey to Cloud which have the follow key characteristics: Responsible licensing, Accessible commit process, Diverse ecosystem, Active community, and Open governance.
In the end the choice is yours, but I recommend at least doing the cost and risk comparison of both options before deciding against any commercial support for open source software.
Let me know what you think.
The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
