Buy “or” Build: Moving to “and” leveraging the power of supported open source

As chief architect for the financial services industry (FSI) at Red Hat, a key part of my job is collaborating with my clients to help them realize value and a competitive advantage from open source and emerging technologies. This gives me an opportunity to hear the thought processes of multiple personas within multiple organizations, and a key and ongoing decision point for many technologists at all levels in most FSIs is whether to build or buy a given solution.

This post goes on to explain the different points of view in the context of the build or buy decision making process and gives some insight into how to make that decision. I'll also highlight a possible third alternative.

First, some definitions and scoping:

When I say "Build" I mean it in the context of open source projects. That is, downloading multiple open source projects from their upstream repository then weaving them together to make a solution to some business problem. Deciding whether to "build" open source based solutions yourself or buy commercial support for an open source product is an important decision, and one that requires a bit of clarity. Part of the reason for the need for clarity is because there is often confusion around the open source model itself. This blog post from Red Hat's Paul Cormier explains it best:

"Open source is a development model, not a business model. Red Hat is in the enterprise software business and is a leading provider to the Global 500. Enterprise customers need products, not projects."

So, whether they are built or bought, technology products should help an organization to realize some business value. Open source is a means to an end: it's a development model that may lead to a product that can provide business value.

So what does "commercially-supported open source product" mean? A commercial open source product is a supported offering that is made up of multiple open source projects. Before they are offered as a product, the projects are made to be stable, reliable, scalable, and compatible with each other (typical enterprise requirements). How an open source software company does that is its differentiator.

The strategy Red Hat uses is:

• Participate in and create community-powered upstream projects

   

  • Champion enterprise requirements within those projects
• Enable software and hardware partners, customers, and academia to participate at every stage of development
• Invest in engineering work to commercialize the offering:

   

  • Extensive quality assurance activities
  • Hardware and software certifications
  • Multi-year maintenance and global support

On that last bullet; it is often necessary for Red Hat to provide fixes for older versions of our products. Those fixes may be backported from the upstream code base or freshly developed. It is often true that the upstream open source projects which make up that product will likely have moved forward, possibly by several years, and may not be interested in creating patches for old software. One example of where Red Hat provided fixes across multiple JBoss products and versions was the JBoss Worm.

Different points of view:

By and large, the different points of view I see among my clients on building technology solutions vs. commercially-supported approaches fall into two somewhat orthogonal categories:

• Those that perceive building their own solutions using the latest upstream innovations as a higher priority than risk management.
• Those that equate non-commercially supported open source products with high risk.

Both acknowledge that in either build or buy approaches, integration work is often needed before a product can realize business value. The nature of this work can vary from the almost always necessary hooks into existing infrastructure systems such as security administration (e.g., identity management, configuration management, and provisioning systems) to the sometimes necessary hooks into the business logic of one or more business processes.

The build using upstream camp puts a very high value on the open source development model since it generally allows for a high pace of innovation. A good piece of evidence for that is in a 2016 Red Hat-sponsored IDC study on the business value of OpenShift (a supported open source container application development platform):

https://www.openshift.com/sites/default/files/idc-business-value-of-openshift.pdf

According to the organizations interviewed, those OpenShift customers have sped up the

delivery cycle for applications and major feature releases by an average of 66%. The IDC study noted that "in turn, these efficiencies have also enabled the release of more applications and features (36%) that resonate with users and customers (136% higher user adoption)."

In addition, in the results of Black Duck's 2017 survey on open source, respondents also cite "the rate of open source evolution and innovation".

The build using upstream camp perceive building solutions as a competitive advantage for at least two reasons: open source innovation (already covered) and they believe the building effort will help them tightly integrate into their organization's existing systems. They weave together some number of open source projects and productize them in their organization so that multiple existing business processes can more easily reap the benefits of this new product which amplifies the benefit of their integration work.

The risk management minded camp worry about compliance. Earlier this year, Red Hat asked IDC to look at the hidden costs of unsupported software. In that report, IDC talked to Red Hat customers for whom compliance is a business critical concern, such as a financial services organization which stated, "We have to demonstrate data lineage to regulators on a periodic basis under different regulations. There are a lot of things required from a compliance perspective. Because there is not much visibility into what is going on with unsupported solutions, we cannot guarantee compliance like we can using Red Hat supported software."

Insight to Help the Decision Making Process:

The reality is that most large organizations have application and business process owners that are both building open source-based solutions themselves and using commercially supported open source. As described above, both have merit.

So how do you decide which path to take if there's a new problem which could be solved with open source?

• Weigh the amount of integration work which would need to be done in either case.

• Reconcile the pace of innovation of each approach with your own rate of deployment; Technology solutions usually provide the most business benefit when they are actually deployed to production.

• Be mindful of the compliance requirements of the business process which will use this solution. If the business process is more heavily regulated, a commercially-supported product may be a better fit.

There is another potential option: Partner with a commercial open source vendor by contributing code to shape their open source product to better meet your requirements. Building usually means investing internal resources to integrate with free open source. Why not further augment those internal resources with the open source community by using a commercial open source vendor to help champion your requirements. There are numerous success stories in this space like what Amadeus did with OpenShift:

"... with Amadeus engineers now contributing to the upstream OpenShift Origin community. This visibility into the OpenShift code allows Amadeus engineers to maximize existing resources by integrating and monitoring their existing middleware applications within the OpenShift platform."

In short, in order to decide how to invest your own resources to take advantage of the high pace of innovation and cost efficiency of open source, there are several best practices I recommend: Look to join forces with a commercial open source vendor. Whether buying or building, let the value of the integration work, pace of innovation, and risk management requirements be the deciding factors.