Last commit in six months? Which FOSS trackers are alive vs abandoned
A pulse check across 14 GitHub-hosted nutrition trackers. Half are healthy. The rest are not.
What we measured
For each project: date of most recent commit to the default branch, distinct contributors in the last 12 months, count of opened-vs-closed issues in the last 12 months, count of merged PRs in the last 12 months. Pulled February 14, 2026.
We classify into:
- Healthy (<6 months since last commit, >1 contributor active in the last year)
- Slow (6–12 months since last commit, or single-maintainer with intermittent activity)
- Stale (12–24 months since last commit)
- Abandoned (>24 months since last commit)
The list
| Project | Last commit | Contribs (12mo) | Issues opened/closed (12mo) | Status |
|---|---|---|---|---|
| OpenNutriTracker | 8 days ago | 12 | 145 / 138 | Healthy |
| Waistline | 22 days ago | 5 | 83 / 71 | Healthy |
| OpenScale | 41 days ago | 8 | 96 / 88 | Healthy |
| NutriCompute (CLI) | 4 months ago | 2 | 14 / 11 | Healthy |
| GnuCal | 5 months ago | 1 | 11 / 4 | Slow |
| FoodSnap-Lite | 4 months ago | 1 | 22 / 15 | Slow |
| Foodvore | 7 months ago | 1 | 30 / 13 | Slow |
| OpenNutriDB | 9 months ago | 1 | 8 / 4 | Slow |
| (Project E) | 14 months ago | 0 | 8 / 0 | Stale |
| (Project F) | 16 months ago | 0 | 14 / 1 | Stale |
| (Project G) | 19 months ago | 0 | 5 / 0 | Stale |
| (Project H) | 28 months ago | 0 | 3 / 0 | Abandoned |
| (Project I) | 32 months ago | 0 | 2 / 0 | Abandoned |
| (Project J) | 41 months ago | 0 | 0 / 0 | Abandoned |
Projects E–J are real; we anonymise here because naming-and-shaming a solo maintainer who lost steam isn’t useful editorial.
What predicts “healthy”
Three signals correlate strongly:
- More than one active contributor. Solo-maintainer projects in this category have ~30% probability of going stale within 18 months. Multi-contributor projects have ~5% probability over the same period.
- Public release cadence beyond the source code. Projects that publish to F-Droid / Play / TestFlight regularly tend to keep going. The release work creates a forcing function.
- A healthy issue tracker. Issues opened and closed (not just opened) in roughly equal volume signals an engaged maintainer.
Counter-intuitively, star count is not a great predictor. Some 4k-star projects go stale; some 200-star projects keep shipping. What matters is the people, not the popularity.
What “stale” means in practice
A “stale” project (12–24 months) is usually still installable and usually still works for current OS versions. The risks:
- Security patches in dependencies haven’t been applied. For a calorie tracker, the practical surface is small but not zero.
- Database backend evolution: OFF and USDA evolve their API responses. Stale apps can break in subtle ways (a field renames, the parsing fails, calories show as 0).
- Newer Android API levels can break the app. Google’s enforcement window is roughly 24 months.
You can usually run a stale app for another 6–12 months before it breaks visibly. After that the breakage is usually network-shape changes rather than code rot.
What “abandoned” means
An abandoned project (>24 months) is not coming back. The realistic next moves:
- Fork it if the codebase is small enough to maintain yourself.
- Migrate to an actively-maintained alternative.
- Continue running the old version offline only, accepting that database updates will eventually break it.
We have one project on this site (a personal CLI tool we wrote in 2021) that’s effectively abandoned. We use it because it’s small and we wrote it. Forking is implicit when the repo is yours.
What you should do as a user
Periodically (annually is fine) re-check the cadence of the apps you depend on. If your tracker drops into the “slow” tier, look at the alternatives in our annual roundup and start dual-writing data into a second app. Don’t wait until the first one breaks.
For projects in the “stale” tier, export your data, evaluate alternatives, and consider switching. The data export should be the same one you exercise in the F-Droid checklist.
What you should do as a maintainer
If you’re the solo maintainer of a tracker that’s about to slip:
- A short “I’m taking a break, expect 3 months of quiet” issue is more useful than silence.
- Tag a “good first issue” or two to invite contributors.
- If you need to walk away, say so. Archived repos are honest.
Recommended
For a personal tracker you’ll use every day, only install from the Healthy tier. For occasional / single-use tools, Slow is fine. Stale and Abandoned, only if you’re prepared to fork.