Embracing Open Source: How to consume opensource software in enterprise?

What are the best ways to consume various types of open source software?

July 5, 2016 Zohaib Khan

7 minute read

What are the best ways to consume various types of open source software?

In the past two articles we have covered the foundations of what Open Source Software is and how it is created and various types of OSS out there, the inevitable question to confront now is “Is there a proper way to consume Open Source Software in an Enterprise?”.

In fact this is the exact same question I have asked some decision makers to gauge the level of their organizations’ maturity in OSS and gotten surprising answers. “Yes we use Spring Framework in our Java project” and “We have some Apache as our web servers” being most common answers. Nothing wrong with that. But ironically, most rate themselves higher even when only a handful of their developers have downloaded and used some OSS in production, which is the extent of their experience with OSS.

Understanding the dynamics of how open source software is introduced and gets adopted for serious production use in enterprise is usually the first step, not last.

Most common way to get started with OSS

The most prevalent channel of OSS consumption is via developers. After all, they are the new Kingmakers . They download some new framework, a new or improved software platform or language, something that makes them curious and/or allows them to do their jobs more efficiently, faster, better and start to experiment with it. These experiments often lead to discoveries that conclude in either the adoption of that open source software in whatever they are building or just an experiment that generates some learning. Either way, it is mostly time well spent.

The biggest pitfall in this cycle is when we implicitly assume that an open source software is ready to be put into production when the initial evaluation succeeds. This might be a dangerous assumption.

The biggest pitfall in this cycle is when we implicitly assume that an open source software is ready to be put into production when the initial evaluation succeeds. This might be a dangerous assumption.

Evaluation vs Production Use of Software

For starters, the concerns of developer evaluation are vastly different than production readiness. Developers want to:

Use latest open source software frameworks that either give them new capabilities and/or allow them to do their jobs better, faster and more efficiently.
Experiment with new ideas quickly using new open source software and deploy them to get feedback from real users and make incremental improvements.
Change things quickly if they do not work out and continue to explore alternatives.
Use multiple frameworks, libraries and tools; weave them in a web of inter-dependent components and/or services to deliver business value.

In contrast, running software in production requires:

Stable and known bits that can be managed, monitored and scaled easily to meet the SLAs.
Complete security discovery, rating and patching capabilities in case new vulnerabilities get discovered.
Knowledge and expertise by existing operations and support teams.
Preferably, as few overlapping stacks that provide similar functionality.
Supported by a reputable vendor that can address issues quickly and deliver innovation in new versions.

The above paradigms seem at odds with each other, but together they form the Yin and Yang of software delivery in an enterprise. It becomes important to intimately understand these concerns and have a game plan to provide room for experimentation while not compromising key principles of production readiness.

Best practices in Open Source Software consumption in Enterprise

Some common sense ways to consume various types of open source software might be as follows:

Community Open Source

Key Characteristics:

Fast moving with new features released regularly.
Security and bug/fixes are applied to the most recent stable version.
Bug fixes or features may be out of sync with your needs if community does not prioritize them.
Mostly community supported.
Requires some DIY to bridge functional gaps.

In my opinion, the most limiting factors in the wider adoption of community open source stem from two reasons:

They are mostly supported by the community and thus require a good amount of DIY, patching and fixing capabilities within enterprise teams.
Community decides which versions to patch and bug fix, which is mostly the latest version. This requires a forced upgrade to latest version in most cases and may incur significant technical debt in order to upgrade the enterprise software built using it. Sometimes this debt is not significant and easy to manage. But at scale it can present quite a challenge to review, patch, test and release thousands of binaries without a significant downtime or impact.

DOs	DONT’s
Experiment and evaluate new capabilities and use cases using community open source. For example, evaluate MySQL or Postgres as possible replacement of expensive proprietary databases.	Expose to production data in production environment without having a bullet-proof rollback and recovery strategy.
Build initial capability and momentum for a new business case. For example, use API frameworks to evaluate, build and provision REST APIs for partner or B2B integration.	Deploy at scale if you cannot upgrade at community’s pace.
Release as part of a pilot or controlled testing. Might be okay for low-visibility or low-impact production which does not increase security or data corruption risk.	Deploy to production if you don’t have capabilities to (a) detect security vulnerabilities in the new OSS and (b) patch it in-house.
	Deploy to business critical environments, where service, support and recovery guarantees require vendor support.

Enterprise Open Source or Open Core

Key characteristics:

Supported by a vendor.
Stable with long supported versions.
One off bug fixes and feature enhancements are usually supported.
Feature rich and complete package provided by vendor, to implement and run in production.
Performance tuned to typical production workloads.

Most enterprise open source software have one or more community equivalent from which it is built. For example, Apache Camel is community to JBoss Fuse, Fedora is community to Red Hat Enterprise Linux etc. You can do nearly everything with Enterprise open source software that you can with its community counterpart and more. In addition:

DOs	DONT’s
Deploy to production after thorough testing, performance benchmarking and integrating with support and operational procedures.	Select a vendor without understanding what they will and will not support. For example, if the vendor does not provide at least three years of support, be very deliberate about it.
Make sure all Dev, Test, QA and UAT environments have the same enterprise versions running as production.	Select a vendor that does not significantly contribute of the community open source equivalent. This is important for various reasons. Notably, vendor’s ability to support issues on time and be able to drive the product’s direction and provide innovation.
Adopt an enterprise roadmap to map out where the open source version might be able to displace proprietary stacks and still match or exceed feature + performance metrics. This could result in significant cost savings.

Innovation with software requires discipline and relentless quest to discover, evaluate and adopt new methods for improvement. Open source software is no exception. Understanding the dynamics of how open source software is introduced and gets adopted for serious production use in enterprise is usually the first step, not last. In this post, we have laid out other important considerations that need to be considered, for a sustained and successful consumption of open source software and harness its power of innovation at scale.

I hope this series on Open Source Software was informative and gave you some useful information that you can use. In order for me to gauge the effectiveness of the content, I depend on your valuable feedback. So go ahead and leave a comment to let me know your thoughts or ask me any questions. If you liked it, let me know by sharing it on LinkedIn or Facebook, liking it and/or tweet a question or comment @zeebluejay.

Embracing Opensource Series