Is There Life After End-Of-Life For Your Open-Source Software?

End-of-life (EOL) refers to the point in time when an open-source software (OSS) project or a particular version of it will no longer be maintained or supported by the developers or the community. EOL software no longer receives feature enhancements, security updates or patches, or bug fixes–leaving it vulnerable to security threats and potentially causing compatibility issues with other software.

Open-source software is attractive because they are free to use and often have a large community of developers who contribute to their maintenance and improvement. However, like all things, open-source libraries can reach their end-of-life.

For some this end-of-life situation is a temporary inconvenience. But for most it can mean new security risks to your codebase, compatibility issues with apps and browsers, no lifeline of support when things do go wrong, and potential data loss.

Finding out about security issues on end-of-life versions of OSS that you still have in your stack before it’s too late can potentially be devastating.

The Equifax Data Breach

Take for example the Equifax data breach, one of the largest data breaches in history, affecting over 140 million people. The breach occurred due to a vulnerability in the Apache Struts web application framework, specifically in an end-of-life version of the Struts framework that was still being used by Equifax. The attackers were able to exploit the vulnerability in the Struts framework and gain access to sensitive information, including names, Social Security numbers, birth dates, addresses, and in some cases, driver’s license numbers and credit card information. The vulnerability had been patched in a newer version of the Struts framework, but Equifax failed to update their systems in a timely manner, leaving them vulnerable to the attack.

If you are using popular OSS like AngularJS (also referred to as Angular 1.x), Vue 2.x, Drupal 7.x, Python 2 or 3, this already applies to you or will very soon apply to you even if you might not have realized it. Checking versions end-of-life dates is time consuming and tedious, and sometimes not very clear, but very important.

Other Ways to Die

This is precisely what makes OSS EOL events so aggravating! There are no standardized practices that OSS authors employ to end-of-life an older version of their library, or their project entirely.

A few common examples of how OSS authors “end-of-life” their libraries:

• Announced Date: Some authors publish an announcement and identify a particular date, stick to a timeline, and make sure everyone knows the path forward. Most major libraries with resources and teams do it this way.
• The Undead: Others never “officially” end-of-life their projects, but yet do not provide active or security support for it any longer, leaving the community to wonder what is going on, or worse yet, turning a blind eye and continuing to use it.
• The Worst Case Scenario: Then there are the horror stories, where OSS Authors, justified or unjustified, abandon their projects and let the mantle fall to “someone else” to pick up the pieces, or worse, the dreaded “Endgame commit” scenario leaving everyone in the dust.

Why Does Open Software Ever Die?

The “why” behind OSS authors deciding to end-of-life their OSS is varied as well, but it can most probably be reduced to the following statement: it was time to move on.

OSS authors and communities move on for all kinds of reasons; financial, better opportunities, personal reasons, and some just realize there is a better way of doing things now and need to move on from the old to innovate and build the new. A lot of it has to do with resource allocation. Sending a version or a project to end-of-life can free up resources to allow for authors to have the freedom to keep innovating and improving later versions to everyone’s ultimate benefit.

In essence, end-of-life marks the end of the software’s lifecycle and, to the perceptive, should signal that it is time to move on to a newer or alternative solution.

It is important for you and your organization to understand what options are out there to plan and prepare for EOL events to avoid potential risks and disruptions to your operations.

Is My Software Affected?

No framework is too big to drop into the EOL bucket. Some recent examples include:

• Google’s AngularJS (commonly referred to as Angular 1.x) reached its EOL after December 2021
• Vue2 will reach its EOL after December 2023
• Protractor will reach its EOL after August 2023
• Drupal 7 has been on tap for EOL for years and is set for EOL on November 1, 2023
• Bootstrap 4 reached its EOL on January 1, 2023
• Node 14 & Node 16 both versions will reach EOL on April, 30 2023 and September 11, 2023
• Python 3.7 will reach its EOL on June 27, 2023

What Are My Options?

Now the trick becomes, making a decision when end-of-life ultimately happens. At this phase you might be asking yourself the question, “what the hell do I do now that the OSS I use every day has reached end-of-life?”

Here are a few options you might consider:

• Do nothing. You may choose to continue using the library as-is, even if it has reached end-of-life. This can be a viable option if the library is stable and reliable and doesn’t require any further development. However, this approach carries some risks, as there will be no further bug fixes or security updates–which can leave your software vulnerable to security breaches and other issues. This option also adds heavy baggage to your technical debt. If security is important to you, this option is not a realistic option at all.
• Fork the library. The nature of open-source allows for anyone to make a clone of a library and continue to build off of that clone. This is referred to as “forking”. If you and your team have the necessary expertise, you can choose to fork the library and continue developing it yourself. This can be a good option if the library is still popular and widely used, and there is a community of developers who are interested in contributing to its development. However, forking a library requires significant effort, and the developer team will need to be committed to maintaining it over the long term.
• Replace the library. Another option is to replace the end-of-life library with a newer and more actively maintained one. This can be a good option if there are suitable alternatives available that offer the same or better functionality. However, this can be a time-consuming and expensive process, especially if the library is deeply integrated into the developer team’s codebase.
• Migrate to the latest supported framework. This option is the most obvious long-term solution. The latest version of the OSS code you are using is where all the attention of the community is. It’s where the top talent wants to be. Migrating to the latest is the ultimate goal as that is where the security fixes, new features, bug fixes, and support will be for the near future. This is a great option but the cost and time of a migration is a factor that cannot be ignored. Finding migration experts to fill in your team or guide you can reduce the amount of time and overall cost of your migration project and lessen the mistakes throughout the process.
• Work with an extended support partner. Luckily, there are third-party partners that can offer support past end-of-life for certain OSS libraries. Purchasing extended support contracts from a vendor or third-party support providers can buy you time to migrate, or can even provide a way to stay on your current framework forever. Long-term support can give you the ability to take back your development schedule, focus on what matters most to your business and extend the runway before having to make a decision to migrate, move to a replacement, or fork the project. Working with a trusted extended support partner can ensure your EOL OSS can continue to receive security and compatibility fixes and keep you in compliance with your client SLAs and/or other compliance agencies.

The Cost of Inaction

The risks of doing nothing when an open-source library reaches end-of-life are significant. Some examples:

• Instability. Libraries may become unstable or incompatible with the rest of your codebase, leading to bugs or other issues.
• Insecurity. EOL software means no security updates which can leave your codebase vulnerable to breaches and cyber attacks.
• Legality. Do you have an SLA obligation to use supported software with your own clients? Being out of compliance can open the door to litigation.
• Expensive. Eventually we all have to pay the reaper, and in this case doing nothing means technical debt accrues and you will eventually have to pay someone to rectify.

There’s Still Time

You may feel that you were left on an island when the OSS authors and community decided to move on and you are stuck using an OSS past its end-of-life.

Don’t panic!

Review the options above and work with your team to make a plan that works best for your circumstance.

Whether you decide to bite the bullet and migrate to the latest version or move onto a replacement, you decide to YOLO and fork the project to become yours forever, or you decide to work with an extended support partner to provide support past the end-of-life, the most important thing is to make a plan and stick with it!

The only bad option is doing nothing at all.