For the last nine weeks I have been taking daily snapshots of GitHub stars for roughly 19,000 open-source projects. Every Monday I publish a top 10 based on star growth since the previous week. Each week gets a fixed page that is never edited afterwards.
I started the project because weekly trending lists are easy to read and hard to trust. A repository can get a burst of attention from a release, a conference talk, or one popular post. I wanted to know how often that burst lasted.
The answer so far: not very often.
The numbers
There are nine complete weeks in the archive, from 2026-07-27 through 2026-09-21. That gives us 90 slots.
- 47 distinct projects filled those slots.
- 30 projects, or 64%, appeared exactly once.
- The average overlap between one week and the next was 4.9 out of 10.
- The overlap ranged from 2 to 6.
The weekly carryover looks like this:
| Week starting | Projects still on the list |
|---|---|
| 2026-08-03 | 6 |
| 2026-08-10 | 5 |
| 2026-08-17 | 5 |
| 2026-08-24 | 5 |
| 2026-08-31 | 6 |
| 2026-09-07 | 6 |
| 2026-09-14 | 2 |
| 2026-09-21 | 4 |
Most weeks replaced about half the list. The week of 2026-09-14 was more extreme: only two projects stayed from the week before.
Long streaks are rare
Three projects lasted seven weeks in a row: mattpocock/skills, stablyai/orca, and DietrichGebert/ponytail.
All three dropped out in the same week, 2026-09-14. That was also the week with the highest turnover in the sample. The result looked like a clean end to the only real streak in the data.
It was not. stablyai/orca returned to the top 10 the following week.
That single reversal is useful. It shows why one week in a trending list is a weak signal. It also shows why dropping out for one week does not prove that interest has disappeared. With nine weeks of data, I can describe what happened in this period. I cannot use it to predict what a repository will do next year.
How the ranking is calculated
Each week compares two daily snapshots: the one nearest the Monday boundary and the one nearest the Sunday boundary. Both snapshots must fall within 36 hours of the boundary. If either one is missing, the repository is dropped for that week rather than estimated.
Archived, mirrored, and unlisted repositories are excluded. A week only enters the archive when it has ten projects. The first week in the source data had seven, so it is not part of the nine complete weeks.
The project list leans toward AI and developer tooling. It is not a random sample of GitHub.
Stars are also noisy. A popular post can move the number by thousands in a day, and not every star represents a user who will keep using the project. The ranking measures attention, not maintenance, code quality, or long-term adoption.
What I look at instead
A weekly ranking is useful for finding projects I have not seen before. It is not a good reason to adopt one.
For that decision I look at the last commit, recent releases, open issues, and whether the repository has been archived. The license matters too. A permissive license, a copyleft license, and a source-available license can lead to very different outcomes for a product.
The weekly list is a starting point. The repository itself has to answer the rest.
Data and method
The archive is here: https://hysenlabs.com/en/weekly
The latest complete week is here: https://hysenlabs.com/en/weekly/2026-09-21
There is also a rolling 30-day growth table with a CSV download: https://hysenlabs.com/en/data/star-growth
If you find an error in the method, send me the details. I would rather correct the dataset than defend a bad number.
Top comments (0)