Four GitHub API Calls That Show if a Project Is Still Maintained

The moderators of r/opensource, Reddit's main open-source subreddit, pinned a policy titled "Your tokens aren't valuable: No more AI", posted on 24 October 2026. It bars projects that "use AI, are made by AI, or are intended for AI". It also sets minimums: a project must be at least a year old and actively maintained, have multiple contributors (the post says subjectively 3+), have an existing community and carry an OSI licence. People who do not speak English are told to "find a different community". The moderator's stated reason is that they cannot tell AI-written text from AI-translated text.

PPC Land counted about 1,400 comments within a day. The loudest objection, as reported by The Verge, is that the Linux kernel now contains some AI-generated code, so under the rule as written Linux itself could be excluded. The Verge also reported the moderators saying there is room for selective enforcement, for example software with incidental AI features such as automatic captioning. Before you install anything on your own server, though, you have to answer a different question. The mods' one-year rule puts it in plain words: will this project still be maintained a year from now?

How to check if an open source project is maintained in ten minutes

You do not need an account or any special tool. GitHub's public API answers the important questions in four calls. Without a token you get 60 requests an hour, which is more than enough. I pipe everything through jq to keep the output short, so install it with your package manager if you do not have it.

Replace OWNER/REPO with the project you are looking at, for example nextcloud/server.

Call 1: the repository record

curl -s https://api.github.com/repos/OWNER/REPO | jq '{pushed_at, open_issues_count, license: .license.spdx_id}'

This gives you three fields. pushed_at is the last time anyone pushed to any branch, which makes it the quickest sign of life. open_issues_count is the number of open issues, and GitHub counts open pull requests in that number too. license.spdx_id is the licence GitHub detected, such as AGPL-3.0 or Apache-2.0. If it says NOASSERTION or comes back null, read the licence file yourself.

Call 2: the latest release

curl -s https://api.github.com/repos/OWNER/REPO/releases/latest | jq '{tag_name, published_at}'

This returns the newest full release and the date it went out (drafts and pre-releases are skipped). Pushes tell you someone is working. Releases tell you someone is finishing that work and handing it to users.

If both fields come back null, run the curl without jq and you will see "Not Found". That 404 means the project has no releases at all, which is itself an answer: you would be installing whatever happens to be on the main branch that day. Some projects publish only git tags, so glance at the Tags page before you rule one out.

Call 3: how the work is spread

curl -s "https://api.github.com/repos/OWNER/REPO/contributors?per_page=100" | jq '[.[].contributions] | {accounts: length, top_share_pct: (max / add * 100)}'

The contributors endpoint lists accounts by commit count, up to 100 per page. The filter adds up the top 100 and works out what share the biggest account holds. That one number tells you how much of the project rests on one person.

Call 4: who wrote the last 20 commits

curl -s "https://api.github.com/repos/OWNER/REPO/commits?per_page=20" | jq -r '.[] | .commit.author.date[0:10] + "  " + .commit.author.name'

This prints a date and an author name for each of the last 20 commits on the default branch. Read it like a shift log. Several human names over recent weeks is healthy. Twenty commits from a dependency bot spread across a year means the lights are on but nobody is home.

Two real results

I ran these calls today, 26 October 2026, against two projects that turn up in a lot of home-server stacks. These are my numbers, taken straight from the API.

nextcloud/server: last push 26 October 2026, latest release v33.0.10 published 15 October 2026, licence AGPL-3.0, 3,825 open issues, and the top contributor accounts for 7.4% of the contributions among the top 100 accounts.

Code landed the day I checked, and a release went out eleven days earlier. The 3,825 open issues look alarming until you remember that the count includes pull requests, and that a project this widely used collects reports faster than any team can close them. The 7.4% figure is the reassuring one, because the work is spread across many people. AGPL-3.0 is OSI-approved, but it carries obligations if you modify the code and offer it to others over a network.

jitsi/docker-jitsi-meet: last push 23 October 2026, latest release stable-11248-2 published 23 October 2026, licence Apache-2.0, 13 open issues, and the top contributor accounts for 46.6% of the contributions among the top 100 accounts.

It was pushed and released three days before my check, and the issue tracker is small and tidy. Nearly half the commits come from one account. Keep in mind that this repository is the Docker packaging for Jitsi Meet, not the whole video platform. The concentration describes who maintains the containers you would actually run.

What a year of age does and does not prove

The one-year minimum is a sensible first filter, because many abandoned projects never reach their first birthday. On its own, though, age proves very little. A repository created five years ago can have its last push two years back, and Call 1 will show you that in one line. A project that is eight months old can have steady releases, several active people and a responsive tracker.

So I read age next to activity. The useful questions are how long ago the last push and the last release happened, and whether that gap matches how the project normally works. A small, finished utility might release twice a year and be perfectly healthy. A web app that faces the internet and has gone quiet for a year is a different story.

Contributor concentration needs the same care. The Jitsi Docker repository's 46.6% is one person doing most of the work, and that work is still shipping: the latest release went out the same day as the last push. That is a working project with a single point of failure, which is common and often fine. Nextcloud's 7.4% across a hundred accounts means no single bus can stop it. Both pass the check. They simply carry different risks.

Treat all of this as heuristics, not verdicts. The numbers tell you where to look. They do not replace ten minutes of reading the issue tracker and the last few release notes.

What the check cannot tell you

Whether a project is maintained is one question. There are at least three others, and the four calls above do not answer them.

The licence. spdx_id tells you what GitHub detected, not what it means for you. Copyleft, source-available and model licences each have their own catches. I keep those checks in my open weights vs open licence checklist.
Security response. A busy project can still handle vulnerability reports badly. Look for a SECURITY.md file and the repository's Security tab, and check whether past advisories were fixed and announced.
Your hardware. A healthy project may not publish ARM images, or it may need more RAM than your box has. Check the install docs and image tags against the machine you actually own.

Whether a model helped write the code tells you nothing about any of these. AI authorship is not the variable that decides whether a project survives on your server. Abandonment is.

Do this before you install, not after

The order matters. If you only run the check once a project already holds your files, you end up migrating in a hurry. My routine has three steps.

Check. Run the four calls, read the last few release notes and skim the open issues for anything that matches your setup.
Pin a version. Use the release tag you just checked, not latest. In Docker Compose that means a fixed image tag, so an upstream change cannot reach your server until you decide to let it.
Subscribe to releases. On GitHub, choose Watch, then Custom, then Releases. You can also add https://github.com/OWNER/REPO/releases.atom to your feed reader. Either way, you hear about breaking changes before they break your stack.

services:
  app:
    image: example/app:1.4.2   # pinned, not latest

When a new release arrives, read the notes, bump the tag and run the four calls again while you are at it. A project that was healthy last spring can go quiet. An empty release feed is often how you first notice.

None of this needs a policy post or a moderator. It needs four requests and an honest look at the answers. If you would rather have someone do this vetting and the install for you, have a look at my services page. Fiverr: hiteshsaini459 · Upwork: hiteshsaini25