Measuring the health of open source projects
Open source software doesn’t come with service level agreements. You can decide to rely an open source project today, only to see its core maintainers leave and its community dwindle within a year.
Sure, you’ll be able to continue using the software, but you’ll be the one responsible for keeping it up to date. Fixing security bugs, updating dependencies, or maintaining interoperability with other software you rely on, all suddenly fall under your responsibility. In the long run you’re more likely to end up migrating to a more sustainable solution, bearing the cost of the migration and having to rebuild or port custom code you had developed around the original open source project.
So when picking open source software, choosing a healthy project is paramount.
In her July 2018 article Methodologies for measuring project health article, Nadia Eghbal provides a great overview of different solutions to measure the health and velocity of open source projects. She finds most solutions focus too much on contributors and suggests instead to consider project activity. She remarks that developers tend to naturally check the date of the latest commit to quickly assess project health, which she considers a “useful indicator of whether a project is being actively developed, and thus reliable to use.”
Sometimes, the simplest solution is just good enough.
