Proactive Open Source Lifecycle Management
Open source software is used extensively across enterprise infrastructure. But with many different technologies in play, staying on top of open source lifecycle management can be challenging:
- How do you keep track of the various releases and updates for each OSS?
- What do you do when your OSS is no longer being supported, but you need to stay secure and compliant?
- What are the advantages of commercial technical support and when should your organization consider using it?
In a recent webinar, my colleagues at Zend and Perforce joined me in a discussion about how organizations can take a proactive approach to open source lifecycle management. This blog recaps our discussion. On the webinar panel were Javier Perez, Chief Open Source Support Evangelist and Sr. Director of Product Management, OpenLogic; Matthew Weier O’Phinney, Zend Senior Product Manager; and myself, Tim Carroll, Director of Product Development at Perforce.
Open Source Software Lifecycles, Release Cycles, and Support
It’s safe to say that everyone has a different idea of “support”, especially around open source software. In fact, there are different definitions out there. Open source communities and projects have their own, and commercial vendors do as well. So, let’s define some basics:
What Is Release Lifecycle Support?
Release lifecycle support refers to the commitment by software providers to stand behind major and minor releases or patches.
What Is Long-Term Support for Open Source?
Long-term support, or LTS, is key for many software providers and open source communities. When they commit to provide LTS for a major release, they give organizations the confidence they need to rely on that version in their infrastructure. They can trust it will be supported for a specified amount of time. One of the reasons Linux became so popular was because of the LTS version of 10 years or beyond. That gives organizations assurance in leveraging that software in their infrastructure.
What Is Maintenance Support?
Maintenance support refers to when software providers and open source communities do maintenance-only support; they only patch major or high severity vulnerabilities (CVEs).
What Is Open Source Technical Support?
Technical support comes in two flavors. One is through self-support, where organizations do their own research on forums, look for documentation, or pose questions to the community to solve issues. Alternatively, commercial support, like OpenLogic, allows organizations to contract for enterprise-grade technical support with service level agreements and objectives that provide time commitments for response, engagement, resolution, etc.
These are some basic definitions. Let’s look at an example of how this might work. We’ll take PHP, a programming language. For a long time PHP did not have a formal release cycle support policy. Then they decided to implement one where every version has a release support cycle of three years. That means you get two years of active support with bug fixes and security patches, and the last year is security-only patches.
Three years, however, is not a lot of time. Zend has a lot of customers with applications that can’t be updated on a regular cadence of one to three years. At a certain point, the PHP version goes end of life. Then the organization feels stuck and wonders what to do. How do they make sure they stay secure? This is when organizations turn to other sources.
Let’s say they are running a Linux Operating System. Linux distros have an LTS commitment that says they will do backported security patches for all of the bundled packages. But, in a Linux OS, you get one version of PHP for the duration of that LTS timeframe. When it goes EOL, you not only have to upgrade to the next version of the operating system, but also the next version of PHP, and by that time, there are likely many newer versions. This creates risk in updating applications and all kinds of complexity.
With each new release there's a deprecation of features, signaling they will be removed in the next major release. There are many little pieces that can cause problems and risk as you do upgrades. Being on an older version or end of life version makes it really challenging to get technical support. It also means that older versions no longer get tested, and updates on security fixes for libraries may no longer exist. Staying secure becomes a major challenge.
Back to topOpen Source Lifecycle Management Monitoring
The question becomes, how do you monitor software lifecycles and be proactive about being on the latest versions? It’s a hard question. In the PHP ecosystem, for example, there aren’t really feeds you can follow to find out when PHP releases come out. They’re getting better at it, but it’s still tough. There are some tools you can use, like Composer, within PHP, which is a dependency manager. But dependency managers have their limits.
What we highly recommend is for organizations to create a software bill of materials, or SBOM – which is an inventory of all of the packages and dependencies that make up software for your entire stack. A SBOM is how you get a complete view of everything you’re dealing with, and helps you see what will be impacted by changes in versions or release cycles. The first time customers run a SBOM, they are often surprised. For example, they realize they have dependent packages they are responsible for like Apache HTTP, which is critical for all their infrastructure; however, they have no one who is familiar with it. Having a SBOM is one of the most critical pieces in establishing a proactive software lifecycle management approach.
Organizations that create SBOMs can prioritize whether they need to patch certain systems immediately or if they have time to wait and see whether those patches have other side effects. The important thing about a SBOM is that it gives you visibility, and then you can categorize issues. When you understand what is in your software stack, you can better analyze risks and plan for the impacts of upgrades and migrations.
Back to topOpen Source Versioning and Risks
One of the most common discussions we have with OpenLogic customers explores the impacts of upgrading to a newer version and weighs the risks. What might break? We field a lot of consulting calls where we help customers navigate the best way to prepare for upgrades and advise them on how to move forward. Because we serve many of the Fortune 500, we gain first-hand knowledge from our work with those customers, and that gives us unique insight to assist other customers on similar issues.
It helps to understand more about versioning and the associated risks of upgrading. Major releases obviously pose bigger risks of breaking things when moving to a new major version. Most projects follow semantic versioning – where version numbers have three parts to them: i.e., X.Y.Z.
We’ll start with the last number. The Z level represents patches and fixes. Those are guaranteed to always be backwards compatible. There are never any other changes other than fixing the bugs or security issues.
The next number, the Y level (the middle number), represents minor release. It usually indicates that new features have been introduced. They don’t change existing functionality, but they allow you to adopt new features in a way that as you go forward, you can continue to use.
Lastly, the X level number is updated only when there’s a backward compatibility break. That means there are code changes that will either break something or make it impossible to use if you attempt to do so with a previous version. Most projects will only issue a major version when there’s something that is going to change how you consume the project.
Organizations typically need to be proactive in going out and looking for information that will indicate whether a release is going to break something. This requires consistent monitoring and not every organization has the bandwidth to devote to it. Many of our customers turn to us to help them understand the potential impact of their plans for upgrading or migrating, and what they can to do handle it. Others ask for help after they’ve already experienced the break and need help fixing what has broken.
Back to topGet the Open Source Support You Need
Our experts are ready to provide technical and long-term support, answer your most complex questions, and help you avoid surprises in open source software lifecycle management.
Advantages of Commercial Open Source Lifecycle Management Support
Because of its potential impact on disrupting the business and user experience, it’s important to understand the impact of release cycles. It’s also essential to realize that once community-level support ends, you are without support. That means your software is unpatched and you’ll be at risk for being out of compliance, especially in regulated industries like financial services and healthcare. It’s not a risk worth taking, which is why companies choose commercial technical support vendors like OpenLogic for OSS support.
Commercial technical support vendors like OpenLogic continue to provide support when community-level support ends, including after end of life. For example, when CentOS ends next June, OpenLogic will be providing long-term support until 2029, perhaps beyond — which gives organizations the opportunity to take some time to solidify the best strategy to migrate to another Linux distribution. We also ensure customers stay secure by providing patches for vulnerabilities or CVEs.
Organizations do not have the time for messy support interactions, which is why we’re committed to zero escalations and assign every support ticket to a Tier 3 technical expert that has at least 15 years of experience working with open source software. We also often employ specialists that have been working on specific open source projects for years, and they bring high levels of skills and experience with that project’s release history.
Organizations that want the assurance of knowing they have open source technical experts available to them 24/7/365 with unlimited tickets often find commercial support to be an ideal solution. We can ensure they have the support they need across their open source lifecycles.
You may consider commercial support for software lifecycle management if:
- You do not have the resources or skillsets to stay abreast of lifecycle management for all the packages in your SBOM
- You’re concerned about security or noncompliance
- You want a predictable support cost with SLAs and guaranteed support timeframes
- You need open source experts that can keep you stable and secure without disruption to your business or customers
Implementing a proactive software lifecycle management approach is essential whether you do it yourself or turn to a trusted partner of experts. Now is the time to make sure you’re supported.
Watch the recorded webinar for the full discussion:
Additional Resources
- Blog – Software Bill of Materials and Your Open Source Options
- On-Demand Webinar - Open Source Security and Compliance
- Guide - Enterprise Application Security
- Blog - Debunking Open Source Software Security Myths
- Blog - Understanding CVEs and CVSS Scores
- Video - Open Source Software Compliance
