Any misgivings enterprises may have once had about adopting open source software for critical corporate functions is long gone. Studies show that over 90% of IT leaders consider open source software “strategically important” and that more than 87% of enterprises are running applications today that are open source. Enterprises embark on open source journeys – creating data pipelines with Splunk, using MuleSoft to connect applications, orchestrating workloads using containers – because they want to take advantage of open source software’s flexibility, shareability, and portability.
Still, open source continues to cause headaches when it comes to support. As Forrester stated: ”79% of IT leaders struggle with real-time open source support.” Since open source is, by definition, open, its creators don’t automatically service it the way sellers of proprietary software would. Open source software can have bugs and technical challenges like any other set of programs. So, enterprises try to manage its use by hiring developers with specific open source skills and cobbling together support agreements to troubleshoot specific platforms.
They often fall short, however. Somewhere in their open source journeys, many enterprises find they lack the knowledge and the technical capabilities to support their growing open source environments from an operational services perspective.
In doing so, they can run into any number of challenges. One is with problem resolutions. If an organization logs a ticket with an open source community, it can take weeks or months to resolve a technical issue. Service organizations can resolve these, but unless they have knowledge and experience across platforms, they may be solving a short-term problem and not addressing the issue from a long-term perspective.
Another challenge: finding talent that understands the open source technologies that organizations are using. Open source developers have specific and unique sets of knowledge for their specific applications. That means if an organization is running 16 different application stacks on open source, it often needs 16 different developers available globally for operational support. Then, once you’ve found skilled developers, there’s the added complication of keeping them. If a developer specializing in MySQL leaves, database project updates can grind to a halt.
Further, organizations tend to struggle to keep current with their licensing requirements. If they’re running a lot of open source stacks, they need to know the licenses in each and that the licenses are compatible. They need to understand which version of an application is supported, which is the recommended version, and when specific versions are being abandoned. Also, which vulnerabilities are each software stack within open source exposed to? Organizations are installing open source applications across multiple environments – legacy platforms, private cloud, public cloud, containerized workloads – without knowing any rights or implications. How do you ensure asset management across your open source is compliant and secure?
Given open source’s growing importance to business organizations today and the complexity of these issues, many enterprises are seeking out third-party, enterprise-level support arrangements. Here are three best practices to keep in mind as you try to optimize open source technologies.
1. Know what’s under your roof
Most companies are running dozens, if not hundreds, of open source applications. If they haven’t made an accurate count of what’s installed and what’s been discontinued, they won’t know what to assign a third-party organization to service. To operate efficiently, you need to have an overview of operational excellence via a single pane of glass.
It starts with the bigger applications – enterprise horses running ERP, CRM, finance, or manufacturing information systems. But it doesn’t end there. It has to extend to all the smaller community styles, the plug-ins, and all the dependencies they track toward.
If you’re engaging with a third-party group to service open source platforms, you should work together to create an asset management system. Most operational leaders don’t know what technologies developers are using on a day-to-day basis. Much of today’s development is done in microservices that developers build and tear down in a few hours. You need to track those fractional changes that can expose your organization to security threats.
This also extends to licensing. Having a vendor manage the complicated matrix of open source licenses removes stress and helps organizations stay in compliance. What is the state of the environment? When does it fall out of scope from a legal perspective? What is the next version the user needs to update to? If you don’t update by the prescribed date, what security boundaries will you be restricted to? These are all critical questions that have to be answered.
2. Choose services that match your need
Support arrangements can vary greatly based on the computing environments the company is using.
If you are operating exclusively in a private cloud environment, you’re less exposed to open source interactions. Thus, these situations require less intensive ongoing support. Using open source applications in hybrid cloud environments requires tooling that can work across private and public environments. Public cloud environments open up applications to more vulnerabilities, so companies will need to invest in order to not lose traction.
Support arrangements also can overlap. Companies that have many applications – open source, proprietary, and internally built – have many different agreements that cover different departments, geographical areas, and applications themselves. There’s a benefit to engaging with an enterprise organization that can support multiple technologies and multiple areas. But how much responsibility do you need to outsource to this group?
That often depends on how different organizations operate and how service level agreements (SLAs) are structured. Do you want to put the enterprise organization in charge of resolving all tickets and supporting all disputes? Should the organization oversee certain issues and escalate if they’re not resolved? Does the enterprise vendor have the right multi-vendor agreements in place to handle situations involving open source on a global level?
3. Embrace open-source support in a holistic manner
To get the most out of open source technologies, companies should think beyond open source support. They should engage with a support partner that knows their whole technology environment – and is committed to solving problems on a holistic basis.
That means troubleshooting a problem with an open source application in several ways. One is to work directly with the open source community to manage a long-term fix for the problem. Another is to do the coding alone to plug the immediate need. If the issue with the open source app affects a larger technology initiative, an enterprise support partner should be able to work with the organization to deliver a better solution incorporating another platform grounded in another technology.
The holistic approach is about helping an organization drive an overall experience – with open source software as one important component. Organizations can drive business value through the use of open source. To do that, they can engage with support organizations to embrace innovation while remaining compliant and secure through the software’s entire lifecycle.
Open source has benefits and risks. Approaching it in a structured way and engaging with trusted partners helps accelerate the benefits and mitigate the risks.
Click here to learn more about how HPE can help optimize your entire IT environment.
____________________________________
