Self-Hosted Nutrition // calorie tracking without the SaaS
#f-droid#checklist#evaluation#foss

How to evaluate an F-Droid nutrition app: a 12-point checklist

Before you trust a tracker with a year of your data, run through this.

By Alex Brennan · Published

Why a checklist

You’ll find dozens of nutrition trackers on F-Droid. Most are fine. Some are unmaintained. A few have permissions or network behaviour that doesn’t match their description. A 5-minute checklist prevents most of the regrets.

Here’s ours.

The checklist

1. F-Droid metadata

On F-Droid:

  • Last updated under 12 months ago: green. 12–24 months: yellow. >24 months: red.
  • Anti-features listed: read them all. “NonFreeNet” or “Tracking” should be a hard pass for a tracker.
  • License: GPL-3, AGPL-3, MIT, BSD, Apache 2 are all fine. Anything else, read carefully.

2. GitHub / GitLab health

Open the source repo. Check:

  • Last commit date (matches F-Droid’s “last updated”?).
  • Contributor count: 1 contributor is more fragile than 5+.
  • Open-issue count and oldest unresolved issue. >2 years old without engagement is a yellow flag.
  • Recent CI status. Broken builds are a yellow flag for an active project, a red flag for a stale one.
  • License file matches what F-Droid claims.

3. Permissions request

In the F-Droid listing, click “Permissions.” For a calorie tracker, the realistic minimum is:

  • Internet (for online lookups)
  • Camera (for barcode scanning)
  • Storage (for export, sometimes)

Permissions that should make you pause:

  • Read contacts. (Why?)
  • Location. (Most don’t need precise location.)
  • Phone state. (No.)
  • Microphone. (No.)
  • Read SMS. (Definitely no.)

If a permission is requested without a documented reason, that’s the question to ask the maintainer.

4. Network destinations

Install on a phone with NextDNS or another DNS-level filter. Use the app for 30 minutes normally. Check the DNS query log.

A FOSS tracker should query:

  • Open Food Facts (world.openfoodfacts.org etc.)
  • Maybe USDA (api.nal.usda.gov)
  • The app’s own update server, if it has one

It should not query:

  • Google Analytics, Firebase, Crashlytics
  • Facebook
  • Branch, AppsFlyer, Adjust, Segment, Mixpanel, Amplitude

If you see ad-tech destinations, the app is doing something you didn’t sign up for.

5. Data export

Look in Settings for:

  • Export to file (any format)
  • Backup-restore round trip
  • Documentation of the export schema

If there’s no export, that’s a deal-breaker. You’re committing your data to an app that’s already saying “leaving will be hard.”

6. Database backend

Where do food entries come from? The README or about-screen should tell you. The realistic options:

  • Open Food Facts (good)
  • USDA FoodData Central (good)
  • A bundled database (acceptable, ages over time)
  • “Our proprietary database” on a FOSS app (red flag, ask why)
  • Nothing, you enter every food (acceptable for some users)

7. Account requirement

Does the app require you to create an account? Most well-designed FOSS apps don’t. If it requires an account, ask:

  • Is the account local-only (a username/password for the device)?
  • Or is it a server account (your data leaves the device)?
  • Is the account creation handled by a third party?

A required server account is fine if you trust the operator. For a small FOSS project, server accounts often disappear when the maintainer disappears.

8. Onboarding behaviour

Pay attention to first-run. Red flags:

  • Required Google sign-in.
  • A request for Health Connect / Apple Health permissions before you’ve used the app.
  • A push to enable notifications.
  • A “what’s your goal” funnel that gates the app behind a 30-step quiz.

A good FOSS tracker is usable in three taps from install.

9. Update cadence

Look at the F-Droid version history. A healthy app shows:

  • Multiple versions per year.
  • Reasonable gaps (not 4-versions-in-one-day-then-silence-for-6-months).
  • Versioning that follows semver or a similar scheme.

Bursty release patterns followed by silence often correlate with a maintainer who has lost interest.

10. Documentation

Open the README and the project wiki / docs site. A well-maintained tracker has:

  • A description that matches the F-Droid listing.
  • A list of features and known limitations.
  • An install / build doc.
  • A privacy / data section.
  • Contact info for the maintainer.

Sparse documentation is a yellow flag, not red. Plenty of fine tools have terrible docs. But the absence of any privacy / data section is a red flag.

11. Issue tracker culture

Read the last 20 closed issues. Healthy signals:

  • Maintainer responds to bug reports.
  • Reproduction-required-info gets asked, but politely.
  • PRs get reviewed within weeks.
  • Disagreements stay civil.

Unhealthy signals:

  • Maintainer ghosts contributors.
  • Issues sit for years without a tag or a reply.
  • Closed-without-comment is the default.

This is fuzzy and you have to read it. It correlates with whether the project will be alive in two years.

12. Personal fit

Finally: does the app actually fit your workflow? A perfectly-built tracker that doesn’t match your habits will go unused. We’ve seen people install OpenNutriTracker, decide they wanted a CLI, and end up with NutriCompute. That’s fine; it’s a feature of the FOSS landscape that there’s variety.

Red flags summary

If two or more of these hit, pass:

  • Last commit >24 months
  • Single solo maintainer with no recent activity
  • Network traffic to ad-tech destinations
  • Required account with no local-only option
  • No data export
  • Permissions requested with no documented reason
  • “Proprietary database” claims on a FOSS app

Yellow flags (proceed with caution)

  • Last commit 12–24 months
  • Single solo maintainer who is actively engaged
  • Network traffic to one analytics/crash-reporting destination only
  • Bursty release cadence
  • Sparse documentation but otherwise clean

Green for go

  • Last commit under 12 months
  • Multiple contributors or a clearly-engaged solo maintainer
  • Network traffic limited to data sources (OFF, USDA) and update servers
  • Permissions match documented features
  • Working data export
  • A privacy/data section in docs

What we run through this checklist

The two we currently recommend (OpenNutriTracker, Waistline) cleanly pass all 12 items. The Tier-B apps in our annual roundup pass 8–10 of them. Below 7, we don’t install.

References