The star chart came back. It answers the wrong question.

You have a repository open in one tab and an invoice in the other. The tool in the repository does most of what you are paying for, and the question in front of you is not whether it works, because you can stand it up on a small server this afternoon and find out. The question is whether it will still be serviceable in two years, and what you are holding if it is not.

The number your eye goes to is the star count. As of the first week of September that number has a curve attached to it again, which is worth knowing about, because the curve is going to start showing up in comparison tables and it answers a narrower question than the one you are asking.

What GitHub took away, and what it gave back

On 30 June GitHub announced that it was restricting several endpoints that had been public for years. Access to the list-stargazers endpoint (/repos/{owner}/{repo}/stargazers) and the list-watchers endpoint (/repos/{owner}/{repo}/subscribers) was limited to admins and collaborators, the /stargazers and /watchers pages went with them, and the endpoint listing the repositories a user watches was put on a path to removal. The stated reason was straightforward: those lists were being scraped to build spam target lists, and GitHub said so in the changelog. The trade-off was that the standard way of drawing a star-growth chart — page through the stargazer list, read each starred_at timestamp, sort — stopped working for any repository you did not maintain. Charts embedded in thousands of READMEs went blank.

On 4 September GitHub shipped the replacement: a star history endpoint that returns counts without identities. It is GET /repos/{owner}/{repo}/stargazers/history, and the REST documentation describes the shape precisely: stars grouped by calendar week, newest week first, each entry carrying a Unix timestamp for the start of the week, a total for that week, and a days array beginning on Sunday. Weeks with no stars come back as zeros so pages join into one continuous series. Pagination walks backwards toward the repository's creation week, thirty weeks to a page, a hundred pages maximum. It needs no token for a public repository. There is a companion GET /repos/{owner}/{repo}/stargazers/count that returns the current total as {"count": 42}.

One limitation matters if you are going to use this yourself. Each weekly entry holds that week's delta, not a running total, so an accurate curve means paging all the way back to the week the repository was created. Tianzhou, who maintains star-history.com and worked with GitHub's team on the endpoint, wrote up the whole sequence and says the missing cumulative field is the one thing he still wants. The upside he names is real, though: cost now scales with a repository's age rather than its popularity, so a project with three hundred thousand stars takes the same handful of requests as one with three hundred, and the old forty-thousand-star ceiling is gone.

The one thing a star curve is good for

It tells you the shape of arrival. That is genuinely useful and it is not the same as popularity.

A single near-vertical week followed by a long flat stretch is a front-page appearance. Ten thousand people bookmarked the thing on a Tuesday and then the world moved on. A gentler line that keeps climbing for a year is people finding a project through use — someone searching for exactly this problem, a colleague's recommendation, a comparison post. Those two repositories can sit at the same star count and be in completely different health.

The second read is almost more useful: a curve that flattened nine months ago while the README still says "actively developed" is a mismatch worth asking about.

What the curve cannot see is most of what you need. A star is a bookmark. GitHub's own documentation describes stars as showing "an approximate level of interest" and notes they have no effect on notifications or the activity feed. Nobody is obliged to unstar a project they abandoned, so the curve only goes up. It says nothing about whether patches are being merged, whether the licence you adopt under is the licence you keep, or whether your data comes back out. And because it is now one unauthenticated request instead of a scraping job, it is about to become the cheapest number to put in a comparison table, which usually means the most over-weighted one.

Here are the four checks that bear on the actual question, in the order I would do them.

Check one: who is in a position to change the terms

This is not the question of what the licence permits you to do today. That question is answered by the licence file and it deserves its own reading. This is the narrower one: who could answer it differently next year, and what you are left holding when they do.

Redis is the cleanest documented case because Redis wrote it down itself. In March 2024 the company moved Redis to the SSPL. In its own retrospective, published when it changed course, Redis states plainly that "SSPL is not truly open source because the Open Source Initiative clarified it lacks the requisites to be an OSI-approved license," and that the change "achieved our goal — AWS and Google now maintain their own fork — but the change hurt our relationship with the Redis community." Then on 1 May 2025 the company added AGPLv3 as a licensing option starting with Redis 8, folding the previously separately licensed Redis Stack features into the core under that licence.

Read that as a mechanism rather than a story. A single company held enough of the copyright to relicense the project twice in fourteen months, in both directions. Nothing stopped it, and nothing was supposed to.

So spend twenty seconds on ownership:

• Does a CLA bot comment on pull requests? A contributor licence agreement usually means

contributors are granting a company rights broad enough to relicense their work. A DCO sign-off (Signed-off-by: in commit messages) generally does not.

• Whose name is in the copyright headers and the `LICENSE` file? One company, or many

individuals, or a foundation.

• Is there a trademark policy? A permissive code licence plus a restrictive name policy

is a deliberate design: you may fork the code, you may not call it the thing people search for.

The practical consequence is that your insurance against a licence change is the fork right, and it only covers the versions already published under the old terms. That is real insurance — Redis's own post confirms the hyperscalers used exactly that — but it only helps if somebody maintains the fork, and realistically that somebody is not you.

Check two: is anyone home

Three cheap signals, and none of them is the star count.

Release cadence. GET /repos/{owner}/{repo}/releases lists tagged releases with dates. You are looking for a rhythm and for the size of the most recent gap. A project that shipped every three weeks for two years and has shipped nothing for seven months is telling you something the star curve cannot.

Last activity and the archive flag. The repository object carries pushed_at and archived. An archived repository is a maintainer explicitly saying they are done, which is more honest than most and easy to miss if you arrived from a blog post.

Commit concentration. This is the one people skip and it is the most predictive. Clone the repository and count:

``bash git clone --filter=blob:none https://github.com/OWNER/REPO cd REPO git log --no-merges --since="1 year ago" --format='%an' | sort | uniq -c | sort -rn | head ``

That pipeline gives you commits per author for the last year, highest first. The git shortlog -sn --no-merges --since="1 year ago" HEAD form does the same thing, but pass the explicit HEAD: with no revision given, git shortlog reads commit messages from standard input, so inside a script it silently returns nothing. Filter out the obvious bots in your head — Dependabot, release automation and translation bots pad these lists considerably. If you would rather not clone, GET /repos/{owner}/{repo}/stats/commit_activity returns a year of weekly commit counts, and the star history response was deliberately modelled on it.

Now read the result honestly. In the self-hosted-tool category, one human at eighty or ninety per cent of real commits is the normal case, not a disqualification. Almost every tool worth writing about in this space is one person plus bots. What that number should change is not whether you adopt the thing but where you put it. A single-maintainer project is a reasonable place for your internal documentation and a poor place for the workflow that has to work at two in the morning on the last day of the month.

Check three: the badge in the sidebar is a guess

GitHub shows a licence in the repository sidebar and most people read it as a fact about the project. It is a detection result. GitHub's own documentation explains that the licence is identified by the open source Ruby gem Licensee, which "compares the repository's LICENSE file to a short list of known licenses," and that a licence not listed on the Choose a License site will not be detected at all. The same page carries GitHub's disclaimer: the information is provided "as-is," with no warranties, and "we're not lawyers and ... we make mistakes like everyone else."

Which means a blank licence slot, or one reading "Other," is frequently not a project without a licence. It is a project whose licence is not on the short list — and in 2026 that set skews heavily towards the source-available terms that come with conditions about who you are allowed to run the software for. A missing badge is a prompt to open the file, not an absence of terms.

Check four: what you keep when it stops

Assume the project goes quiet eighteen months from now with the version you run in production. Three questions decide how bad that is, and all three are answerable before you go live:

1. Where does the data physically sit? A Postgres or MySQL database you hold credentials

for is a different proposition from an opaque application volume. If you can reach the tables with a standard client, you can get the records out with or without the project.

1. Is there an export that works without the application running? A documented dump

command, or a schema you could write a query against, is the difference between migrating and retyping.

1. Do you hold the exact build you run? If your deployment resolves a :latest tag at

build time, you do not have a pinned version, you have whatever was published most recently. Pin the digest and keep a copy of the image you are actually running somewhere you control.

None of that is exotic work. It is the same discipline as keeping a database backup you have actually restored once.

The honest take

The strongest argument against all of this is that it is a lot of diligence for a tool replacing a thirty-dollar seat, and that star count does correlate with survival — projects with a lot of attention attract contributors, sponsors and forks, which is exactly the mechanism that keeps software alive. Both of those are fair. The reason to be careful anyway is that the correlation is weakest at the moment you rely on it: when you are comparing two projects that both look plausible, and one of them is a launch spike.

So scale the check to the consequence. Something back-office that only you touch, where the worst case is an afternoon of re-entry: the star curve and pushed_at are genuinely enough. Something a client sees, or something holding records you would have to recreate from memory: run all four checks and write the answers down, because in eighteen months you will not remember which of the two candidates had the CLA.

And keeping the subscription is a legitimate outcome of this exercise. If a tool fails check one and check four — a single company can change the terms, and your data lives somewhere you cannot reach without the app — then the invoice you were trying to cancel is buying you something real, and the honest comparison is the subscription against the cost of the migration you would eventually have to run anyway.

The twenty-minute pass

For the next tool you are seriously considering, in this order:

1. Open the LICENSE file. Not the badge, the file.
2. Check pull requests for a CLA bot and the headers for a single corporate copyright holder.
3. Look at the releases page for the gap between the last two, and check the repository for

the archive flag.

1. Clone it and run the author count above. Note the top name's share.
2. Find the data store and the export path in the deployment documentation. If neither is

documented, that is your answer for anything client-facing.

1. Last, pull the star curve, and read it for the shape of arrival rather than the total.

Then write three lines somewhere you will find them again: who could change the terms, how many people are actually shipping code, and what you would do on the day it stops. If you cannot fill in the third line, you have not finished evaluating the tool — you have only finished liking it.