Published August 6, 2019 · 7 min read

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.

Open source is one of the biggest enablers of modern engineering but also one of the largest sources of hidden risk. The same libraries that accelerate development can introduce vulnerabilities, compliance issues, or long-term maintenance costs if not properly vetted. In earlier discussions like Engineering Roles and Responsibilities, I emphasized how defining ownership helps mitigate such risks. This post dives deeper into that principle from the lens of open-source dependency management.

So, without further ado, letʼs see what we should check before using open-source software.

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, trust must be earned by validating its correctness.Stars and downloads are not proxies for those guarantees.  Before integrating any dependency, run focused validation: trigger edge-conditions, simulate failures, test concurrency boundaries, and ask “under what assumptions does this 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.

License compliance is a technical safeguard. Violating even a single transitive dependency’s license can jeopardize a product release or expose a company to lawsuits. Many applications contain components with unclear or incompatible licenses, primarily due to nested dependencies. 
Automated scanners are helpful, but they don’t replace human review. The goal isn’t to block open-source adoption. It’s to understand your obligations. Integrating license checks directly into CI/CD, much like compliance or security validation, ensures alignment between engineering speed and legal safety. If a dependency’s license conflicts with your product model, for example, GPL in a closed-source service, treat it as a production risk Replacing it early is far cheaper than refactoring later.

Here's a table for some of the licenses for a quick reference.

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?

A healthy community is a proxy for the project’s long-term stability. If bug reports are ignored, documentation is stale, or maintainers respond slowly, you might get into real trouble. When evaluating community strength, look for measurable signals. Some examples are contributor churn, issue close rate, average response time, and diversity of maintainers. A project supported by multiple organizations (high “elephant factor”) 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.

In production systems, change frequency is a form of risk. Projects with rapid release cycles can introduce unseen regressions, undocumented API shifts, or untested dependencies. Stability isn’t just about how often code changes but also whether change is predictable and reversible. You can 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.

Treat dependency evaluation like code review, systematic, repeatable, and documented. Every library you adopt becomes part of your supply chain, so the same care you apply to internal systems should apply here. Building this discipline ties directly to your broader engineering culture.

A small amount of diligence up front prevents costly rework, unplanned incidents, or compliance surprises later. Open source isn’t “free”; it’s a shared responsibility. One that rewards those who check first, then use.