Staring at a long list of promising projects and unsure which to trust? How to choose open source software comes down to a short checklist: check the license, maintainer activity, security signals, documentation and your exit options.
This checklist sits within a wider topic: open source software in general.
| Item | Value |
|---|---|
| Security checks in OpenSSF Scorecard (March 2024 post) | 19 checks |
| Reference definition of “open source” | The OSI Open Source Definition |
| Preferred license type for source code | An OSI approved license |
| Machine-readable license labels | SPDX license IDs |
| Tool for tracking licenses in your code | Software composition analysis (SCA) |
Figures come from the OpenSSF Scorecard post and the Linux Foundation license guide. They can change, so check the sources before you rely on them.
Start with what you actually need
A checklist only works when you know what you are judging against. Before you open a single repository, write down the job the software must do and the limits you work within.
- Must-have features: the handful of things the tool cannot ship without.
- Environment: your operating system, database, cloud or on-premises hosting, and the skills on your team.
- Integrations: the systems it has to talk to, such as email, identity providers or other business tools.
- Risk level: whether a failure is an annoyance or a business outage.
With this written down, you can drop projects fast. A shiny tool that misses a must-have is not a candidate, however popular it is.
If you are still deciding whether open source is the right route at all, the comparison of open source vs proprietary software covers that trade-off.
Check the license first
The license decides what you may legally do with the code, so it is the first gate. The Linux Foundation’s guide notes that “The OSI definition of “Open Source” (https://opensource.org/osd) describes what is necessary to define code as open source.” A project that merely publishes its source under restrictive terms may be “source available” rather than open source.
Look for a license from the Open Source Initiative’s approved list. The Linux Foundation guide recommends an OSI approved license for source code where possible, so that others recognize it and understand the rights involved.
Then ask these questions:
- Is the license clearly stated in a LICENSE file at the top of the repository?
- Is it permissive (such as MIT, BSD or Apache) or copyleft (such as the GPL family)?
- Does it fit how you will use the software: internal use, embedding in a product, or offering it as a hosted service?
- Do the dependencies carry licenses that conflict with it?
The Linux Foundation also points out that scanning tools report far more accurate results when SPDX license IDs are present. When a project labels files that way, auditing is easier for you later. For real commercial or legal questions, ask a qualified lawyer.
Read the signs of a healthy project
A license tells you what you may do. Project health tells you whether the software will keep being maintained. You can judge much of this from the repository itself.
Activity and maintainers
- Recent commits and releases, not just a burst of work long ago.
- More than one active maintainer, so the project does not depend on a single person.
- Issues and pull requests that get answers, even when the answer is “no”.
- A visible roadmap or release notes that show where the project is going.
Community and governance
Look for a contributing guide, a code of conduct and a clear way to report problems. Projects hosted by a neutral foundation usually have written governance, which lowers the risk that one company changes direction overnight.
Documentation
Good docs are a strong signal. Check that installation steps are current, that upgrade paths are described and that examples actually run. If you can not get a demo running from the docs, expect pain in production.
Look at security signals
Open code can be inspected, but that does not mean someone has inspected it. The OpenSSF Scorecard is an automated way to look at security habits. In a March 2024 post, the OpenSSF said it was restructuring its codebase to divide its “19 checks” into distinct probes.
The same post states that “Users of open source software can use Scorecard results to make informed decisions about projects of interest.” The post also admits that “A fundamental challenge with Scorecard is the subjective nature of scoring.” Treat a score as one input, not a verdict.
Alongside any score, run through these manual checks:
- Does the project publish a security policy and a way to report vulnerabilities privately?
- Are fixes released promptly, with advisories you can read?
- Are code reviews and automated tests part of how changes are merged?
- How many dependencies does it pull in, and are they maintained?
Test it and plan your exit
Never decide from a README alone. Run a small proof of concept with real, but non-critical, data and note how long setup takes and where you got stuck.
Also plan how you would leave. Check that your data can be exported in open formats, that configuration lives in files you can back up, and that standards are used rather than a private format. If you are comparing tools in the process automation space, the roundup of open source bpm tools is a useful starting point for building a shortlist.
Finally, count the true cost. Free to download is not free to run: budget for hosting, staff time, upgrades and, if you need it, paid support from a vendor or specialist.
Common mistakes to avoid
Most poor choices come from skipping a step, not from missing some secret signal. Watch for these patterns while you evaluate.
- Choosing by popularity alone: a famous project can still be a poor fit for your environment or skills.
- Ignoring the license until late: discovering a conflict after you have built on the software is expensive to fix.
- Depending on one maintainer: if that person steps away, updates and security fixes may stop.
- Skipping the trial: features that look complete on paper can be awkward or missing in practice.
- Forgetting upgrades: an unmaintained version in production becomes a security and compatibility problem over time.
Ask a colleague to run through the same checklist independently. Two people often catch different problems, and any disagreement shows where you need to look closer.
Keep a short record of why you chose what you chose. When someone asks months later, or when you need to revisit the decision, that note saves you from repeating the whole evaluation from scratch.
Review the decision on a regular schedule. Projects change owners, licenses and priorities, and a tool that passed today may need a second look later.
How to choose open source software with a scoring routine
To compare candidates fairly, score each one on the same criteria. A simple pass, watch or fail rating per row keeps the decision honest.
- License check: OSI approved, clearly stated, compatible with your use.
- Maintenance: recent releases and several active maintainers.
- Security: a security policy, reviewed changes and prompt fixes.
- Documentation: current install and upgrade guides that work.
- Exit options: open data formats and standard interfaces.
Drop any project that fails the license row. For the rest, a few “watch” marks are normal; several “fail” marks are a reason to move on.
Frequently asked questions
Does a high GitHub star count mean a project is safe?
No. Stars show interest, not quality or security. Check maintainer activity, license and security practices instead.
Is a security score enough to approve a project?
No. The OpenSSF itself notes that scoring has a subjective element, so use it alongside your own review.
What is the difference between open source and source available?
Open source licenses meet the OSI’s Open Source Definition. Source-available projects publish code under terms that do not meet it, often limiting commercial use.
Should I pick permissive or copyleft licenses?
It depends on your use. Permissive licenses place few conditions on reuse, while copyleft licenses require derived work to be shared under similar terms. Ask a lawyer if the answer affects a product you sell.
