Software development depends a lot on open source projects. From operating systems to editors, we use open source software everywhere. Nevertheless, we should be careful about what we are using. We should potentially go through a checklist to see if the software meets our expectations. If there doesnʼt exist a guideline for the company or the team, we should set up one.
So, without further ado, letʼs see what we should check before using open-source software.
Open Source
Security
A problematic open source software can open up a huge risk for your product. What should developers do for potential vulnerabilities? The least that can be done is to use the national vulnerability database, common vulnerabilities and exposures, and OWASP dependency check.
Unfortunately, security vulnerabilities often get discovered months later. Even worse, there are cases where the vulnerabilities are discovered after years. Thus, we should constantly check the dependent libraries and possibly automate it by OWASP dependency check plugins.
Correctness
Open source projects are written to address different problems. Nevertheless, there are times where the open source software struggles to deliver the very premise of a correct solution. For example, one can expect a distributed lock to provide atomicity over threads and processes. In reality, you can find out this isnʼt the case. It can be hard to realize such problems since the project can have big community support or many stars… I suggest reading a bit of code of the project before committing to it. I know it would take time to dive into the code but itʼs better than getting paged for an unforeseen reason. No matter how popular a library is, stars and downloads are not proxies for correctness. Before integrating a dependency, trigger edge conditions, simulate failures, and test concurrency boundaries. Ask which assumptions make it break.
License
Open source software development licensing is one of the first things you need to check. If you aren’t comfortable with licensing, I recommend checking out common licenses. The way you would handle the licensing part depends on the intent etc. For some cases, you might need to get some legal advice as well. On the other hand, there are standard licenses like Apache that you can expect you won’t have many headaches. The trouble here is about checking dependent software licenses since one project depends on another. You can automate license checking as well by using different tools based on the languages and platforms. If a dependency’s license conflicts with your product model, for example modified AGPL-covered code in a closed-source network service, replacing it early is far cheaper than refactoring later.
Here's a table for some of the licenses for a quick reference.
| License | Permissions | Restrictions / Obligations | Best For |
|---|---|---|---|
| MIT | Commercial use, modification, distribution, private use | Must include copyright and license notice | Small libraries, permissive use |
| Apache 2.0 | Commercial use, modification, patent use, distribution | Must include notice; provide license; state changes | Corporate or SaaS integration |
| GPL v3 | Commercial use, modification, distribution | Copyleft – derivative work must be open source | Developer tools or standalone apps |
| LGPL v3 | Commercial use, linking, modification | Library changes must be open; linking allowed | Shared libraries, plug-ins |
| BSD 2-Clause / 3-Clause | Commercial use, modification, distribution | Retain copyright notice; no endorsement implied | Infrastructure or network code |
| MPL 2.0 | Commercial use, modification | Must open modified files only (not whole codebase) | Large modular systems |
| EPL 2.0 | Commercial use, modification, distribution | Must disclose modified files under EPL | Enterprise frameworks |
| CC BY-SA 4.0 | Copying, redistribution | Must credit and share under identical terms | Documentation or media assets |
Community
An active community is an important aspect of open source software. Before deciding to adopt a solution, you should check if issues are being addressed, if bugs are being tracked, and if it has guidelines or sufficient documentation. A quick research on the project page and potentially StackOverflow might give you some idea about the community support. Yet, sometimes it’s hard to find an open source solution with a good community. In that case, the question is whether you want to contribute back to the project when you hit a dead end. Contributing to open source projects is always fun, so why not? Look at issue response time, issue close rate, contributor churn, and maintainer diversity. A project supported by multiple organizations is more resilient than one dominated by a single developer.
Stability
The stability is another aspect to look for. If the open source software changes a lot and you don’t think you can keep up with the changes, perhaps this isn’t a good choice for you. Even in the stable open source software, you should lean towards stable releases. For example: if you have a new version of a project, I would recommend waiting a bit than upgrading since for every new release there would be potential problems. It’s better to wait for issues to be fixed and hope to get the release to reach some maturity. You can also manage part of the risk by pinning dependency versions.
All in All
Today’s software development can’t be done without the help of open source projects and products. Whenever we want to introduce an open source dependency, we should go through at least some of the topics discussed here. Personally, I recommend checking out security and then the solution. Both security and correct solutions matter a lot since you don’t want your product to have security holes as well as unexplained bugs. Every library you adopt becomes part of your supply chain, so the same care you apply to internal systems should apply here.
A small amount of diligence up front prevents costly rework, unplanned incidents, or compliance surprises later.