So you did your research and chose the most suitable open source component. You then integrated it with your code and everything works great. But how do you make sure that your choice remains the best even in the future?
You probably understand that no open source component is ever future-proof.
The open source community is continuously reporting issues and improving the quality of existing open source components. That’s why you see new versions getting released constantly. These frequent updates require your team to catch up. Especially now, when the industry is increasing funding to open source projects to ensure better maintenance, like the CII and other similar initiatives. These efforts will lead to even more frequent version releases, which means even more catching up to do...
The Implications of Not Updating Your Versions
Often new versions offer new functionality, fix reported software bugs / security vulnerabilities or add compatibility with other open source projects. These versions are the result of the open source community’s collaboration. And collaborative work is the key to improving open source. But you can’t benefit from it without updating your versions.
And when it comes to new versions that fix security vulnerabilities, it’s not a matter of using ‘the latest and greatest’ but a matter of protecting your product. If you don’t update these versions, you expose your company to a great risk as some hackers follow security related incidents in open source projects and try to exploit the known vulnerabilities. Fortunately, the open source community has repeatedly proven that it is very quick to respond with new patches or versions that fix the discovered vulnerability. But if you don’t update your components, you are leaving yourself vulnerable to hackers who have the ‘exact recipe’ to hack into your product.
Why Open Source Components Are Not Updated Often
Updating components take time, and you never know how long it might take you. Why? Compatibility!
A new version is not necessarily backward compatible with its previous version and since most companies don’t update regularly, when they do upgrade an old version, then it’s fair to assume that the update will never be 100% backward compatible. This means that you will need to modify your code, in some level, to integrate with the latest (updated) version.
There’s also the question of compatibility to other open source projects. There’s also the risk of a ripple effect that the version update might cause due to incompatibility with other open source projects.
Another reason that makes it harder for companies to properly update their versions is the amount of work it takes to track all versions and make a decision. Most commercial software products use dozens to hundreds of open source components, with each component having its dependencies. To top it up, some open source projects release updates as frequently as every 2 weeks. The fact that lots of open source components are involved, including dependencies, coupled with the rapid development and version releases of some of them make it almost impossible to track and decide for each component if it gets updated or not.
Best Practices: 3 Easy Steps to Survive Frequent Open Source Component Updates
So now that we understand how important it is to update all the open source components in a project, and also the amount of work and risk it entails – what’s the best way to go about the updates?
Just follow this simple three-step process:
- Start by regularly monitoring your versions for new releases - if your company uses a lot of open source components, it is best if you automate this process with tools like WhiteSource. Identifying all open source components whose updated versions are available is the first step.
- Classify the identified new versions from step one and assign them to one of the following three types:
- Security issues – you need to be aware that you have a security vulnerability in your code and that there’s a new version that can fix this issue. You can then make a decision whether you’d like to update according to its severity score and community feedback. Remember, that just like you are aware of this issue, so do hackers tuning into the open source community.
- Quality issues – similar to security issues, you first need to understand the severity of the bug. If it’s a critical bug, then it requires an upgrade.
- Business need – some new version may improve the performance or add new functionality. It may solve mission critical issues or just be ‘nice to have’. You need to understand what type of upgrade you are looking for and prioritize accordingly.
- Your next step should be to classify within each segment what is critical, what is ‘nice to have’ and what is not worth the trouble.
Companies that manage their open source versioning diligently, continuously update a versioning roadmap as new issues get discovered and new versions are released according to this 3x3 matrix (Security, quality, business need X critical, nice to have, not needed).
While it’s not possible or even reasonable to update all open source projects every time a new version is released, you must still be aware of your situation to make informed decisions. Remember that ignorance is not bliss when it comes to open source updates.