Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
By Jeff Luszcz, Vice President of Product Management at Flexera.
In only a decade or so, Open Source Software (OSS) has completely changed how software development is done. Previously, a software development team would make a “build versus buy” decision for any feature, and would weigh the cost of creating a feature from scratch against the cost of paying a commercial software vendor for the needed functionality. The high cost of purchase, as well as the lack of awareness of available commercial components, created an environment where software developers often created the vast majority of the source code that went into their software product. During this time, it was common to see that over 90 percent of the software product was written by the company itself. As time went on, the Internet allowed worldwide connections between software developers that created an environment where millions of “free” software components were available for easy consumption by software teams. After this change in the software world, it is now common to see a software product that is 50 to 90 percent OSS and contains hundreds to sometimes thousands of third-party open source components.
This new way of creating and using software components has greatly expanded a company’s ability to create massive, high quality, modern projects powered by “Best of Breed” components. Whenever there is such a large change in business or engineering practices, it is not unexpected that business processes need to catch up to the new world. Previously, any third-party software components were signed off not only by engineering but also by purchasing and legal. This was due to the need to negotiate commercial terms, purchase the license, and manage any other contractual documents such as Non-Disclosure Agreements, Service Level Agreements, or similar material.
In today’s engineering environment, third-party components are investigated, reviewed, and integrated typically with little oversight and policy review. Additionally, once a component is selected, it often is left in place without a periodic review.
Be Aware
There are multiple things that a software developer should be aware of before selecting a software component, no matter if they are choosing open source or commercial. The first and most important is the permission and obligations required to use the component legally. For commercial components, this means negotiating payment and usage terms.
For open source components, this means reviewing the license that controls its usage and confirming that your organization is able to follow each obligation required by it. For example, if you distribute a product and select and link against a component under the General Public License, one of the obligations is to provide the source code for your linked product and the source code for the original component as well.
For components licensed under a license like MIT, one of the main obligations is to include a copyright statement and permission notice in the software itself. If an open source component does not make its license completely clear, this is a sign that the component is not well used or may not have a large ecosystem of large users. In some cases, a developer can submit a bug report to the original project requesting that a license is selected, or clarify any confusion about a license. This can be a more difficult problem if the component is already being used in a product. The answer that comes back from the author or project may mean that you are no longer able to use the component in the way you wanted to. If that is the case, you will be required to stop using the component and remove it from your project. This highlights the importance of understanding the controlling license before making a choice to use a component.
How Old? How Maintained?
Another area to examine when selecting an open source project is to see how old and how well maintained the project is. You may find that no one has contributed to the project in many years, or that there is only a single author involved. Both of these issues may be things that cause you to explore other options in terms of components to use. The more contributors to a project and the time that a project has been around are both important health metrics. That said, in many cases the most popular and most respected projects are found to be mature projects run by individuals. By being mature, there is not often a need to make changes (this is common in compression and image handling libraries) and thus, you may find many users but very few contributors to these types of projects.
National Vulnerability Database
The security and vulnerability status of a component is also an important test when selecting an open source component for use. There are databases and feeds of information that can give you the current list of known vulnerabilities for the component. A well-known source of vulnerability information is the National Vulnerability Database. This database allows developers to search for component names and view the associated vulnerabilities with a specific version, or ones that have been reported in the past. It’s important to mention that a component with vulnerabilities reported against it isn’t necessarily a sign of a low-quality component. The more popular or the more important a component is, the more likely security researchers will examine it for problems to improve its quality. If you have a choice between two components—one which has had vulnerabilities reported against it, and one that has never had any reported—you may find that the one with previous vulnerabilities could end up being the more secure component!
Lastly, once you select a component, it is important to check periodically that no new vulnerabilities have been discovered for that component since it was first downloaded. New attacks or vulnerabilities are typically found after a component has been released and used for a while. After new vulnerabilities are discovered, it is common to update the application with a patch or new release.
By taking into account the vulnerability status, controlling license, and project health information, you will be able to select the best open source components for your project. By providing feedback, bug reports, and your own security reviews to these open source projects, you also can help the entire software ecosystem build high-quality components. The results of all these actions are more secure products, a more controlled upgrade cycle, and less need to redo work unnecessarily.
