A prospect recently approached us with a problem statement that his upload and download speed for WAN was way lower than expected and wanted us to have a look and fix
We asked him for details of the test setup he used and kind of tests he ran
We, then replicated the same at our end and got excellent results.
“Great! So what was the issue?” He asked.
“There is nothing that we fixed, we just ran the tests”
He was clueless and asked us to investigate further as to what different did we do. But, there was nothing to investigate. And then it occurred to me that I did not ask the version of the open source software that they were using.
Turned out that it was exactly the reason, which made all the difference!
He asked for the invoice, and I was clear that we did not want to charge since we hadn’t done anything. He still insisted and paid us.
We have experienced this, way frequently. Staying up-to-date with latest version of all the open source softwares that are used in the product is very important yet often neglected angle of product development lifecyle.
If it ain’t broke, don’t fix it – isn’t always a good strategy!
Many a times, companies start with one version of open source software(OSS) and do not plan an upgrade unless there is something wrong with the version they are using. This is convenient approach but can be riskier than we think.
Using OSS can decrease Time to market. However, it also comes with the responsibility of keeping the software secure. This does not mean in any way that OSSs are less secure than proprietary software. Just that whenever the vulnerabilities are found in OSSs, the information is out in public and could be taken advantage of!
I know this might sound scary but it is, in fact, an advantage of using open source software. Since there are active communities, the vulnerabilities are usually found and fixed early. For proprietary software, one needs to wait for an official update to release to get those fixed.
OSSRA Report 2020
If I haven’t made my point yet, I will let the OSSRA Report for 2020 to do the talking.
The entire report is worth studying if the companies are planning to use OSS. There 2 sections that I want to highlight though.
75% of the codebases contained vulnerabilities. Out of those, 49% are high risk vulnerabilities.
82% of the codebases had components more than four years out of date
(Image source — synopsys.com)
Now, even though it is important to stay up to date with the upgrades, it is also practically impossible to do that for every release coming in. For starters, it needs testing your ENTIRE product once you update the open source software.
So how do you know when it’s the time to upgrade the Open Source Software?
There is no standard answer to this. However, you can make a deliberate decision if you keep an eye on the changes going in every release of the OSS. The updates can be loosely categorized in 3 lists. Critical, Relevant, Can-do-without.
- Critical: Security updates and bug fixes like memory leaks fall into critical category. These are the changes which should never be overlooked. There are enough stories on internet of products that missed updating the security patches and landed in big trouble.
Another change which falls under this category is framework or interface changes. Those changes, if not taken care properly, will end up in breaking the “backward compatibility”
Equifax data breach is assumed to be the largest in the history. As per wikipedia, Private records of 147.9 million Americans, along with 15.2 million British citizens and about 19,000 Canadian citizens were compromised in the breach. All this because, Equifax was using a third-party software that had a security exploit. The software did release the patch, but Equifax had not updated on their servers. Equifax had to pay a heafty price of not doing that upgrade in time
- Relevant: These are usually enhancements to existing features or new features introduced. Companies should assess the relevance of those for the product they are using the OSS for. They also need to consider the SDLC efforts needed to fit these changes in current product. If the feature can not be accommodated in the upcoming release, it could at least be put in the roadmap. That way, companies will not miss out on those.
- Can-do-without: This is easier to decide. These changes could be skipped if the changes are not important from the business perspective.
Companies can also set policies to make the process easier. Irrespective of the approach taken to address this aspect, it is always a good idea of maintaining notes of the analysis and decisions made for future reference.
At Plexusbit Software, we always make sure to have this point covered in checklist for each project that has something from open source. We also maintain the list of OSSs used by all our clients and email them whenever there is an important release out.
What is your strategy of upgrading OSS? Do you still follow — “If it ain’t broke, don’t fix”?
Reference: