Choosing an open source component is easy; finding out two years later that it has been abandoned, when the whole system depends on it, is very expensive. The number of stars on a hosting platform or popularity on forums says little about a project's real health. Different checks are needed, almost all of which can be done in half an hour by looking at the repository and the documentation.
Recent activity
The first signal is whether anyone is still working on the project. Check:
- date of the last commit on the main branch and frequency over the last year;
- date of the last release and how regular previous releases were;
- response time to issues: they need not be fixed immediately, but someone should read them;
- external pull requests: are they reviewed and merged, or do they stay open indefinitely?
Beware of one special case: a small, stable project may have few commits simply because it is finished. A library that does one thing and does it well does not need constant change. What makes the difference is how problems are handled: if security issues get attention, the project is alive even if quiet.
People and bus factor
The bus factor is the number of people who would have to disappear for the project to stop. You estimate it by looking at how contributions are distributed:
- if a single person wrote the vast majority of recent commits, the bus factor is one;
- if several people have release rights and are active, the risk is lower;
- if all maintainers work for the same company, the risk matches that company's decisions.
A low bus factor is not an automatic reason to reject a project, but it should be weighed against how critical the component is and how hard it would be to replace.
Releases and versions
A mature project handles releases predictably:
- numbered versions following a stated scheme;
- release notes explaining what changes and what breaks;
- a statement of which versions still receive fixes;
- packages published in the ecosystem's official registries, signed where possible.
If the only way to install the software is to build the main branch, the project is not ready for production use.
Security handling
This is where differences are sharpest. Look for:
- a
SECURITY.mdfile or a page explaining how to report vulnerabilities privately; - security advisories published for past problems, with affected and fixed versions;
- reasonable times between a vulnerability becoming public and its fix;
- regular dependency updates.
The absence of past advisories does not necessarily mean the software is secure: it may mean nobody ever looked for problems or published them.
Documentation and community
Good documentation lowers the cost of adoption and shows care. Check whether there is an installation guide, an options reference, up-to-date examples and migration instructions between versions. Also look at where users ask for help and whether questions get answered, including by other users and not only by maintainers.
License and governance
Check that the license is a recognised open source license and that it is the same across the whole repository. Also check whether contributors must sign a CLA allowing a company to change the license, and whether the project has written governance or sits under a foundation.
A checklist to fill in
| Criterion | Positive signal | Warning sign |
|---|---|---|
| Activity | Regular releases, issues read | No response for months |
| People | Several active maintainers | A single person |
| Releases | Versions, changelog, stated support | Only the main branch |
| Security | Private channel, public advisories | No process |
| Documentation | Complete and current | Stuck on old versions |
| License | Clear, uniform | Mixed or missing |
The exit plan
The last question is the most neglected: what would I do if the project stopped tomorrow? Possible answers are switching to a fork, maintaining a copy in-house or migrating to an alternative. If none is feasible, the component should be isolated behind an internal interface, so it can be replaced without rewriting everything.
In my work I often prefer a less brilliant library with three active maintainers to a more elegant one that depends on a single person.
In short
- Stars and popularity do not measure a project's health.
- Check activity, bus factor, releases, security, documentation and license.
- A small, stable project can be healthy even with few commits.
- For critical components, always prepare an exit plan.
