How to Evaluate Open Source Software Before Your Stack Depends on It

The friction of adding an open source dependency is almost nothing — a single line in a package file and the library is in your codebase. This is one of open source's genuine advantages: extraordinary leverage for moving fast. But the asymmetry between the ease of adding a dependency and the cost of removing it is one of the most common sources of slow-accumulating technical and legal risk in early-stage companies. Dependencies added quickly and without evaluation become load-bearing infrastructure before anyone notices, and by then the cost of replacing them is high enough that the problem gets deferred indefinitely.

License risk is the most misunderstood category. Many founders assume open source means “free to use for any purpose,” but open source licenses have conditions. The GPL family of licenses uses copyleft: if you distribute software that incorporates GPL-licensed code, your software may need to be distributed under the same terms. For a company trying to protect proprietary source code, this is a genuine exposure — one that's expensive to unwind after the dependency is deeply integrated. A legal opinion on your license stack before you raise a Series A is far cheaper than the conversation with an acquiring company who discovers a GPL dependency in your codebase during due diligence.

Maintenance risk is the other major category, and it's less visible. A library that goes unmaintained doesn't break immediately — it becomes gradually more dangerous. Security vulnerabilities go unpatched. Compatibility with newer versions of the language runtime degrades. Bugs accumulate with no one responsible for fixing them. If the library is critical to your product and you can't replace it without significant engineering work, you're now maintaining someone else's abandoned project in addition to your own. Evaluating maintenance health before a dependency becomes critical is far easier than managing the situation after.

Permissive licenses — MIT, Apache 2.0, BSD — are the simplest for commercial use. You can use, modify, and distribute software under these licenses in proprietary products, typically requiring only attribution (a notice in your documentation or credits). Apache 2.0 additionally provides a patent grant, which is why some companies prefer it to MIT for anything with patent exposure. The vast majority of open source software that goes into commercial products uses permissive licenses, and for most purposes you can treat them as “free to use with attribution.”

Copyleft licenses — GPL, AGPL, and to a lesser degree LGPL and MPL — have conditions that can affect your commercial product. GPL requires that if you distribute software incorporating GPL-licensed code, the combined work must be distributed under GPL terms — meaning your source code becomes available. LGPL weakens this: it applies at the library boundary, so you can link against an LGPL library without your own code being covered, but modifications to the LGPL library itself must be shared. AGPL extends GPL to network use, meaning SaaS applications using AGPL components may need to open-source their code. The practical significance depends on whether you're distributing software and what the license boundary is between the open source component and your code.

The distinction between using a library (calling its functions from your code) and distributing software that contains it matters enormously for license compliance. If you're building a SaaS product and running GPL-licensed code on your servers, you're not distributing it to users — the GPL's trigger isn't activated. If you're building a desktop application or a product you ship to customers, you are distributing it, and the GPL applies. AGPL, as noted, applies to SaaS as well. When in doubt on a specific dependency, a conversation with a lawyer who knows software licensing is worth the hour.

Start with the license. It should be in the repository root as a LICENSE file or clearly stated in the project documentation. Identify which license family it belongs to and confirm it's compatible with your commercial product. This takes two minutes and is the most common thing that gets skipped. Tools like FOSSA, Snyk, and licensee can automate this for your entire dependency tree and surface conflicts — useful if you have a large number of dependencies or want ongoing monitoring.

Check maintenance health by looking at three indicators: commit activity (when was the last commit, and has activity been consistent or declining?), issue response time (how long do open bugs sit before being addressed, and what's the ratio of open to closed issues?), and contributor count (is this a one-person project where the maintainer burning out would end the project, or does it have multiple active contributors?). A project with a last commit three years ago and 400 open issues is not actively maintained, even if it works fine today. A project with a single maintainer who is active and responsive is healthier than it looks, but it carries key-person risk.

Check the security track record by reviewing the project's CVE history (the National Vulnerability Database and GitHub's security advisories both index this) and how quickly past vulnerabilities were patched. A project with an active security response process and a track record of timely patches is trustworthy for production use. A project where a known CVE sat unpatched for 18 months is a signal about how future vulnerabilities will be handled. For Node.js, Python, and other ecosystems with package managers, running your package manager's audit tool on your dependency tree is an easy first check.

Five dimensions cover most of the risk for a production dependency. License type and commercial compatibility is the first: permissive licenses are green, GPL/AGPL require a license analysis specific to how you're using them, and anything with a commercial use restriction or a source-available license (which is not actually open source) requires explicit review. Maintenance activity is the second: active commit history within the last six months, issues getting responses and resolutions, and multiple contributors reduce the key-person risk that turns into an unmaintained dependency.

Security track record is the third: check CVE history and patch response time. Community size is the fourth: large, active communities mean more people finding bugs, more documentation, more Stack Overflow answers when something breaks, and more likelihood that the project survives any single contributor leaving. The fifth is business criticality and replaceability: how deeply integrated would this dependency become, and how hard would it be to remove if it went unmaintained or changed its license? A utility library that touches ten lines of code is low risk. A framework that your entire data layer is built on is high risk regardless of how well-maintained it looks today.

For critical dependencies in categories two through five, it's worth asking explicitly: if this project went dormant tomorrow, what would we do? If the answer is “we'd need to fork and maintain it ourselves or do a major rewrite,” that's a risk you should acknowledge deliberately. Some projects in this category are worth the risk because they're widely used and the community is large enough to ensure continuity. Others warrant a more cautious stance — either choosing a better-maintained alternative, budgeting for a potential fork, or using the project behind an abstraction layer that makes replacement feasible.