The real problem with end-of-life software
You’re probably aware of the risks of using software that has reached end-of-life (EOL). New vulnerabilities go unfixed. If you need new features or compatibility fixes, you’re out of luck. This presents both a functional and security risk. But no software is truly end-of-life if you can write a big enough check. No, the real problem with end-of-life software is knowing what end-of-life actually means.
When a project defines a lifecycle for it’s software, it’s pretty easy to tell what end-of-life means. As part of the lifecycle, the project documents the level of support a particular version gets and when that support period ends. The project may say “we’ll fix bugs for six months, and then only fix security issues for another six months after that.” There may be several levels of varying lengths.
But what happens if the maintainers just sort of…disappear? If a project hasn’t had an update in two years, is it because it’s complete or because it’s abandoned? How can you tell?
Services like endoflife.date and standards efforts like OpenEOX can help you know when the software you depend on has reached end-of-life, but only if the project makes — and shares! — and explicit EOL determination. When a project is abandoned or the flywheel slows, how can you tell? The ultimate risk is the same as with an explicit date, but you don’t know about it.
So how can we fix this? The short answer is: we can’t. You can’t force your upstreams to provide a lifecycle policy because they are not your supplier. The best we can do is pay attention when that information is available and set a good example in our own projects. Not every maintainer will be willing to make that commitment, which is fine. The more projects that adopt an explicit lifecycle, though, the better of we’ll all be. Chapter 7 of Program Management for Open Source Projects describes creating a lifecycle for your project’s releases.
