5 Tips for Using Open Source Components More Wisely
Table of Contents
In our last post we discussed how to choose the best option for your product and company. This week we’d like to share our tips on how you should be using open source software components, once selected, to ensure better tracking and maintenance.
The choices range from copying a few lines into your project’s source code base to integrating open source libraries, using complete classes or files, using a pre-built library, or having your code communicate with a separately running process.
Here are our top five tips for how to use open source components more wisely:
1. No matter what you do – Do not copy & paste
Although the copy and paste method were considered a common approach in regards to open source libraries in the past, most software development teams now know that this is not suitable – especially with open source components.
When you copy a code snippet, you also copy its bugs and vulnerabilities, but you lose visibility. Once you copy and paste a few lines you have no way of tracking this snippet and update it when a software bug or a security vulnerability is discovered and fixed with a patch or a new version.
Even if the code is flawless, which it never is, what happens when a new version is released with new features or improved performance – how can you upgrade? Unless you are using the component ‘as is’, you have no backward compatibility.
Software code is dynamic and so is your product’s requirement. Your needs will change throughout the software development lifecycle (SDLC) and you’ll need as much flexibility as possible. You are limiting your options once you copy and paste a few lines from an open source library.
2. Manage changes with facade design pattern
If you must use a small subset from an open source library and decide not to use a local clone or fork it (see our next recommendation), then your next best option is to use a Facade design pattern to wrap the library in your own interface.
Writing a wrapper will allow you to easily replace the library with another, should the need arise. It will also turn the usage to centralize and will help you to monitor the places where the wrapper is used. The wrapper also helps with encapsulation and information hiding, making sure that any functionality you don’t want to use is “hidden”.
3. Why aren’t you forking?
The right to “fork” or clone an open-source project and take the copy in a new direction, remains one of open source’s great merits, but it’s a right not exercised as often as it should.
If you do not wish to download an open source library and use it ‘as-is’, since you’d like to modify it, then your best practice should be to fork it or clone. Forking (or cloning it) will enable you to track improvements made to this open source components since you will always have a link to the original repository. The disadvantage here might be the need to compile and build your own package.
4. Hosting your third party components
Some software development teams still manually transfer open source components via email or similar ways. Sounds crazy, right?
A repository manager is a dedicated server application designed to manage repositories of binary components. It is considered an essential best practice for any significant usage of binary open source components.
Using a repository manager significantly reduces the number of downloads of remote repositories, saving time and bandwidth resulting in increased build performance, improved build stability due to reduced reliance on external repositories and provides an effective platform for exchanging binary artifacts within the organization.
If your team is not using one of the repositories in the market (Jfrog Artifactory, Sonatype Nexus or Apache Archiva), you better store your third party components on a shared network location.
5. Keep track to know when you need to update
A recent survey pointed out that 1 out of 16 open source components contains a security vulnerability and many other libraries contain critical severe software bugs. The majority of issues (both security vulnerabilities and software bugs) are fixed at newer version, but unless you are tracking your inventory and the updates of the libraries you are using, then you won’t notice these problems until a hacker breaches your application.
If you do happen to find an update is needed to one of your components, be sure to remember than you have no way of knowing if the new version is backward compatible with other open source components or to the way you have integrated the library into your code. This means you need to write some tests that prove the functionality that you want to use from the library. As a bonus, these tests double as documentation on how to use the library.
Manage open source software components throughout the software development life cycle
You should always know what open source components you are using, as well as their dependencies and versions. You just never know when someone from the security team is going to call you about a critical vulnerability in a specific version of a library, or when the legal department suddenly decides to forbid the use of a certain license.
You need to manage your components throughout the development process, to detect problematic components as early on in the SDLC as possible. Your build tools and CI servers are the ideal places to verify that all the components used meet your standards and catch issues as soon as they are introduced and be able to fix them quickly. Think of it as using the CI system to alert you of compliance issues just as it alerts you to quality issues today.
If you are using a repo manager, then restricting the repository to approved artifacts is another method for ensuring that applications are free of defects. Some organizations approve every artifact before allowing it in the repository (white list) while others allow developers to add any component by default and only restrict those with known issues (blacklist).
You also need to track known security vulnerabilities in your product after you release to alert your customers and offer patches once a security vulnerability is discovered in one of the components in your product.
