5 principles for your cloud-oriented open-source strategy

Many companies are still trying to work out strategies to incorporate cloud services and open-source software, two of the most significant developments to hit enterprise IT in the past decade.

Here are five principles—honed by observing HashiCorp customers and reflecting on our own decision making—that can prove invaluable to enterprise IT leaders looking to guide their organization’s cloud journey and digital transformation.

1. Open-source projects are fertile ground for experimentation

Keep tabs, via conferences, social media, and technical websites, on open-source projects that are gaining traction in the community.

Practitioners on your team should investigate projects that have the potential to solve a “job to be done” for your business. What they turn up may need more time to bake before it can be used in a meaningful way at your company, but if a project isn’t immediately useful, star the repo and keep tabs on the project.

More importantly, make sure your engineers have time to learn and try new things every week and even to contribute to open-source projects. It can do wonders for morale, retention, and recruitment, and if the open-source projects are ones that your business depends on, the benefits multiply.

Pay attention, though, and make sure your teams are experimenting with tech that’s worthwhile to your organization, not just shiny new projects engineers want to play with. Establish ground rules for experimentation, perhaps based on project maturity, opportunities for upskilling, or potential business value.

2. A portfolio-level view of open-source usage can develop a framework for commercial relationships

It’s easy to have more open-source tech in your IT organization than you realize. Using open-source software is often the easiest way for an engineer to add a feature to in-house software or fix a bug in third-party software. While open-source proliferation means your team is finding creative ways to solve business problems, you need to understand what technology is being used and how it affects your organization.

Start by inventorying the open-source projects used in production, and then ask your team a few critical questions:

• How many of our critical apps depend on this technology?

• How much money do those apps bring in?

• How many business transactions are affected by this technology?

• How many engineers at the company are proficient in this technology?

• What is our plan if there’s an unexpected outage or other issue with the tech?

• What version of the tech are we using? When was the last time we patched it?

• What role does open-source tech play in our compliance with industry regulations or corporate governance? What risk does this pose?

The answers you get may make you uncomfortable, but they will help you to understand and quantify the risk. If any open-source projects are mission-critical, consider replacing them with paid relationships with vendors that have deep expertise in those key technologies. After all, this is what you do with other IT products you depend on.

Just as with every other IT line item, a commercial relationship with a vendor should have a business case. Fortunately, the ROI of a paid relationship with an OSS vendor is usually straightforward. You can count on less downtime because you have experts helping design resilient systems and access to skilled engineers to speed troubleshooting, and you will have a better security posture because of rapid resolution of common vulnerabilities and exposures (CVEs).

And a commercial relationship may also lead to greater productivity; with support from a trusted vendor, talented employees can be freed from the operational toil often associated with homebrewed open-source setups and spend more time solving business problems.

3. Cloud services based on open-source projects are increasingly important

A small slice of open-source projects that prove to be widely popular eventually become fully managed cloud services. These third-party cloud services are likely to become the dominant way you consume open-source technologies.

Be ready to evaluate and use such projects, because their managed nature can dramatically speed your time to value and reduce up-front investment compared to traditional technology deployments—you’re trading off the training required for your staff and the detailed infrastructure setup that you’d need.

4. You must know how open source fits with your larger IT environment

API-centric strategies have made business workflows more composable than ever. Any given piece of tech likely interacts with several—perhaps dozens—of other systems. While additional dependencies can add complexity, gains in agility and feature velocity make it a worthwhile tradeoff.

But you have to evaluate in the context of API interactions in the open-source technology you use. Ask your team:

• What open-source technologies interact with our most important IT vendors?

• What is the nature of those connections?

• Is this integration supported by the community at large?

• Are other companies relying on a similar integration pattern, or is our setup unique?

• Is there a commercial version we should consider?

These questions are critical because running IT systems at scale is tricky even if you have trustworthy experts on hand to assist with architecture, routine operations, and troubleshooting. In their absence, things can be much harder.

You may decide that your homegrown open-source setup works for you and you don't have a compelling business case to justify a commercial relationship with a vendor. But it is still important thing is to ask the questions, establish the level of risk involved, and reevaluate the risk regularly.

5. Have a strong security posture across your entire IT estate

We’ve all read the terrifying headlines about ransomware and software supply chain hacks. Zero-day vulnerabilities are a fact of life. And some of us recall Spectre and Meltdown, two staggeringly widespread hardware vulnerabilities.

Open-source communities typically prioritize security. Patches and fixes are published soon after vulnerabilities get disclosed. The question for you: How quickly can you apply these fixes to your systems?

Historically, security updates have been the reason businesses choose to pay for open-source technology. The idea is that the vendor can quickly package the fix and distribute it for easy deployment. This makes sense, especially for technology that affects your core systems.

Open source will become the rule, not the exception

These five principles will help you to effectively and efficiently use open-source technology to your best advantage.

Even if open-source software remains the exception to how you run IT today, it’s likely to become the rule tomorrow. Consider creating an open-source program office, a center of excellence designed to foster the use of open source and maximize its value across the enterprise.

The OSPO will typically set policies and remove obstacles around the use of, and contribution to, open-source projects, helping to justify internal decisions and making sure OSS efforts align with strategic business objectives. And an OSPO can help attract top engineering talent increasingly looking to work in organizations that demonstrate strong open-source programs.

Web-scale companies all have OSPOs. To keep pace, traditional enterprises should follow suit.