7 Factors Developers Should Consider Before Choosing an Open Source Project
Table of Contents
Your team is probably using many open source components throughout each software development lifecycle. Are you in the know about how your developers are checking open source components before integrating a new component into the software? Do your company happen to have any guidelines directing your developers what to check before adding something to the build?
Adding a problematic open source component may open up your product to unnecessary security and legal risks and lead to a lot of headaches. However, you can minimize the risk significantly by having your developers invest a bit more time and efforts during the selection process. This will also save them a lot of headaches later on.
So, without further ado, here are seven things we recommend your developers look into before integrating a new open source component:
#1: Known vulnerabilities
Security has become a critical aspect of all the phases of any software development. You invest a lot of resources (and budget) to secure your proprietary code with SAST and DAST tools. But when it comes to your open source libraries, what are your developers doing to ensure you are using secure components?
Earlier this year, researchers found that 1 out of 16 open source components included known security vulnerabilities. Now, these are verified and publicly published vulnerabilities. You should be aware that even if your developers are not checking for vulnerabilities in the open source project they integrate, hackers are. Open source vulnerabilities have proved to be a very efficient for hackers as one vulnerability has many victims.
So, what should your developers do? The minimum should be a simple search in the NVD database or, assuming you are using a popular and well maintain open source project, the project website.
However, the real problem is that open source vulnerabilities can be discovered months or even years after publication, so you need to continuously monitor for security vulnerabilities in your open source. For that you need an automated tool. Our customers understand the value of getting real-time alerts when a new security vulnerability is discovered in open source components in their software, even for historic versions released years ago to their customers, as it enables them to be proactive and protect their customers.
All open source projects have a bug tracker, but very few developers check to see if there are any critical or blocker bugs before they choose to use a certain component. Obviously, there’s a big downside to not checking for bugs thoroughly – because just one of these running rampant in a system can really compromise mission-critical operations.
As we all know, finding bugs is tricky, that’s why companies use the beta and extended user testing for. It takes a community to really thoroughly test for bugs. In the open source world, you already have it – so why not use it?
#2: Licensing
Open source components come with a license, which you have to comply with. There are hundreds of open source licenses, although the majority uses about 30 licenses, with different terms and conditions. Some require you to add notices, some have patent clauses, and there are the copyleft licenses obviously. Copyleft licenses, like the GNU GPL family, require the user to release the full source code and all of the rights to modify and distribute the entire code of the product.
Another problematic point is that you do not only need to check the specific library open source licenses and ensure it meets your legal team policy, but you need to check the licenses of all dependencies on the open source libraries you are adding. You should be aware that dependencies may have a different license than the actually used library.
The license will usually appear in the header, but the best place to check in the open source project website. As for dependencies…
#3: Software versions
New versions of open source libraries are released quite frequently. Often new versions offer new functionality, fix reported software bugs and 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. However, your preference should be to use the last stable version rather than the newest one, unless you need a specific new functionality.
Sometimes the last stable version is marked, and if not, a quick search in relevant forums will usually answer this question. In case there’s no ‘official’ last stable version, most developers’ rule of thumb is to use the one before the last.
Updating versions through the software development lifecycle is also important, but this is a more complicated process that needs a process on its own.
#4: Is your organization already using it?
It can help your developers to start off by checking whether this component is already in use. If it is and your developers have been following a certain procedure for a while, it is safe to assume this library is compliant with your organization open source policy.
You should also consider the versions in use and avoid a situation where you are using the several versions of the same open source library for no apparent reason. By doing so your team is unnecessarily complicating your supply chain, and therefore the tracking and compliance.
If your developers are maintaining an inventory list, manually in spreadsheets or using automated tools, this should be fairly easy to check.
#5: An active community
This is a huge one for any developers who is using open source components.
Open source projects have communities of contributors and active users who write the code, detect and fix issues, writing documentations and offering support to other users. The larger and more active the community is, the better the code and the support you can get if you run into trouble.
A quick search on the project website or in relevant forums will show you how active the community is. The number of commits and downloads is also a good indication of a project’s popularity and community size.
#6: Documentation
Popular and well maintained open source projects ensure they have proper documentation. Each one of us that has ever needed a good documentation and could find one, understands the value of good documentation.
This can be a great indicator for the quality and support you can expect from this community. If you happen to have a few options suitable to your needs, this metric should steer you in the right direction.
Working with open source components, which you are not familiar with the source code, without documentation makes dealing with issues a big hassle. When everything is directly presented in front of you, it makes things a lot easier.
#7: Choosing an open source project
Overwhelmed with this long list of things to check? Don’t be.
It is reasonable to assume that currently your developers are checking one, maybe even two items off this list, so adding a few more parameters to check, even if not all, is a step in the right direction. I strongly recommend starting from security vulnerabilities and severe quality bugs.
If your company is using many open source components, usually it’s in direct proportion of the number of developers, it will be wise to move to automated solutions like Mend that will free up your developers to code and will ensure the security, quality and compliance of your software.
