How starwire works
Where the repos come from, how they're checked, and exactly how every list is ranked. If something here doesn't match what you see, tell us.
Last changed November 8, 2026. Every change to the method is listed at the bottom.
- Where repos come from
- What gets listed
- How often it updates
- Categories and descriptions
- How Trending works
- The other sorts and labels
- What never affects ranking
- Worth a look, the default order
- Vital signs on repo pages
- Setup effort
- Use the data
- What we count
- Known limits
- Changes to the method
Where repos come from
A repo lands on starwire when someone points at it. We collect five kinds of picks:
- Developer curators who post open source projects for their followers. We read the repo link from each post.
- Reddit communities where developers share projects. A post counts when it's about a repo: it links the repo or names it in the title, not just mentions one in passing. Each community counts as one curator, and posts need at least 20 upvotes.
- Hacker News stories that link to a GitHub repo and reach 30 points, or 20 for Show HN.
- GitHub Trending, the weekly list.
- Reader submissions through the submission form. Your own projects are welcome; the form asks you to say so.
Each of these counts as a separate source. A repo picked by several of them is shown as picked 2×, picked 3× and so on.
What gets listed
- The repo must be public on GitHub and not archived.
- Submissions need at least 10 stars. Every submission gets a reply on its issue with the result.
- New repos are reviewed on each update. Anything that looks like spam, malware or isn't open source software is hidden.
- A repo that is deleted, made private or archived drops off on the next refresh.
Listing a repo isn't an endorsement or a security review. Read the code and the license before you run anything.
How often it updates
| What | How often |
|---|---|
| Looking for new repos, handling submissions | Every two days |
| Stars, forks, open issues and pull requests, last commit, license, renames | Every day, for every listed repo |
| Star history used by Trending | One count per repo per day, kept daily for 90 days and weekly after that |
The data behind the site is public: repos.json, and an RSS feed of new picks.
Categories and descriptions
Each new repo is put in one of 15 categories and gets a one-line description, written by an AI model (Claude) from the repo's own description and README, following fixed rules: say what it does in plain words, no hype. Submitters can suggest a category. These are the parts most likely to be wrong, so if one is, open an issue with the repo link and we'll fix it.
How Trending works
Trending shows repos gaining stars fastest right now for their size. It uses only stars we measured ourselves.
Hidden gems is the same list, cut down to repos that still have fewer than 1,000 stars: the ones rising before most people have heard of them.
1. Stars gained in the last 7 days
Every day we record each repo's star count. The gain is today's count minus the count from 7 days ago.
- A repo created less than 7 days ago gained all its stars this week, so its gain is its star count.
- While we have fewer than 7 days of counts for a repo, it shows only the days measured, as
+255 in 1 day. Nothing is projected forward. - For a repo under 30 days old, the missing days are filled with its own average since it was created. That's an estimate, so it's marked with a
~, as in~+700 a week.
2. Adjusted for size
A repo with 200,000 stars picks up hundreds a week out of habit. A small one gaining the same is far more remarkable. So the ranking divides the gain by the square root of the repo's size:
heat = stars gained in 7 days / √(stars + 100)
The square root keeps big repos in the running without letting them drown out small ones, and the + 100 stops a brand new repo with a handful of stars from jumping to the top on its first few. A repo needs at least 50 stars in the week to appear in Trending at all.
Example: +2,000 stars on a 3,000-star repo scores 2,000 / √3,100 ≈ 36. The same +2,000 on a 100,000-star repo scores about 6.
The other sorts and labels
| Sort | Order |
|---|---|
| Worth a look | The default. Stars gained in the latest day, weighted by five signal checks. How it works |
| Most stars today | Stars gained in the latest day of our daily counts, with no weighting. The arrow beside the rank compares it with the day before. |
| Most picked | Number of different sources that picked the repo. Each source counts once, however often it posts. Ties go to more stars. |
| Trending | Heat, as above |
| Most stars | Current stars |
| Newest picks | The date a repo was first picked by any source |
| Recently updated | The last commit to the repo |
| Recently saved | Your own saves, newest first. Saves stay in your browser. |
| Label | Meaning |
|---|---|
| new | A new project: first picked in the 7 days before the latest update, and created on GitHub in the last 90 days. Older repos picked for the first time join the list without this label. The same rule picks "New this week". |
| picked 3× | Picked by 3 different sources |
| Green dot, updated 5d ago | Last commit under 30 days ago |
| Amber dot, updated 4mo ago | Last commit under a year ago |
| Grey dot, quiet 2y | No commits for a year or more |
What never affects ranking
- No one can pay to be listed or ranked higher.
- The StarDash card in the list and in repo panels is our own project, made by the same person who makes starwire. It's always labelled and never changes the order.
- There are no accounts and no ads. Your saves stay in your browser.
- Visit counts (below) don't change the ranking. If they ever do, it will be listed under changes first.
- The README previews load from GitHub, and the two libraries that render them load from cdnjs with integrity checks, so a tampered copy is refused.
Worth a look, the default order
Stars are easy to get for a week. A new repo with a polished README can collect thousands before anyone has used it. So the default order isn't raw star gain. It is stars gained per day, weighted by five checks on whether that attention looks earned:
| Check | Passes when | Why |
|---|---|---|
| Picked | More than one independent source picked it | One mention can be luck or a friend; two rarely are |
| Aged | The repo is older than 90 days | It has outlived its launch week |
| Active | Code was pushed in the last 30 days | Someone is still working on it |
| Forked | At least 3 forks for every 100 stars (repos with 200 stars or more) | People who use a project fork it; stars with almost no forks are attention, not use |
| Steady | No single day holds more than 60% of the week's new stars (when the week brought 50 or more) | A one-day spike is a post going round, not a trend |
A repo that passes every check it can be judged on keeps its full daily gain. Each one it fails takes an equal share off, down to a quarter of its gain for a repo that passes none. A check with too little to go on is left out instead of counted against the repo. Nothing is hidden or removed: a repo with weak signal sinks in this one order, and still shows in search, in its area and in every other sort. "Most stars today" is the same list without the weighting.
The checks say whether attention looks earned. They don't say a project is good, and a young project from one source can be excellent. Every repo page shows which checks it passed, and the rules are in one short file you can read or challenge.
Vital signs on repo pages
Each repo page shows four signs, measured from GitHub about once a week. They describe the project's recent activity; they aren't a rating of its quality. They only break ties on alternatives pages, and never change the order of any other list.
| Sign | What it shows | Green when | Amber when |
|---|---|---|---|
| Momentum | Its place among repos in the same subarea, by stars gained this week | In the top quarter | Below the top 60% |
| Activity | Commits to the main branch in each of the last 12 weeks | Commits in at least 6 of the 12 weeks | No commits in 12 weeks |
| Releases | Time since the latest GitHub release | Within 90 days | Over a year ago |
| Issues | Issues closed in the last 90 days, as a share of issues opened (capped at 100%) | 60% or more | Under 30% |
Anything between is shown in a softer green. Some signs are left out instead of judged: no releases (many projects never use GitHub releases), fewer than 5 issues opened and closed in 90 days, or a repo with no measured star gain. "How it compares" puts the same numbers next to repos that replace the same tools, or its closest neighbours in its subarea.
Setup effort
Not everyone who wants an open source tool runs servers. The Setup label, shown on repo pages, alternatives pages and collections and as a filter on the list, says how much know-how a project takes to get running. It is read from how the project is packaged, taking the easiest route it offers:
| Label | Shown when the project is | What it means |
|---|---|---|
| Install like an app | A desktop app, mobile app or browser extension | Download it and open it. No server, no terminal. |
| Hosted, free plan Hosted, paid Hosted version | A server or browser project whose makers also run it for you | Sign up on the project's site, nothing to install. The label says whether it has a free plan, is paid only, or doesn't state a price. Running it yourself still needs a server. |
| Runs in a browser | A web app with no server packaging | Opens in a browser, but you may have to start it yourself. |
| Uses the terminal | A command-line tool | Installed and run by typing commands. |
| Needs a server | A self-hostable service | Someone technical sets it up on a server, usually with Docker. |
| For developers | A library, framework, plugin or similar | A building block for people who write code. |
We haven't installed these projects, so the label describes packaging, not how smooth the install is. The hosted label is judged from each project's own README and website, so far only for projects listed as an alternative to a paid product, and it is checked again when either text changes. Plans and prices move, so confirm on the project's site. A project without the label may still have a hosted version we missed. Setup never changes any ranking.
Licenses
Every repo shows the license GitHub finds in it, and the License filter groups them into four kinds. They say what was found, they aren't legal advice, and nothing is left off the list because of its license.
- Open source: a known license that lets anyone use, change and share the code, such as MIT, Apache-2.0 or GPL.
- Source available: a known license that publishes the code but limits commercial use, changes or reselling, such as BUSL or a non-commercial Creative Commons license.
- Custom license: the repo has a license file, but GitHub can't match it to a known one. It may be an open license with edits or the project's own terms, so read it before you build on it.
- No license: no license file was found. By default that means the author keeps all rights, even though the code is public.
How well an alternative fits
Every product on the alternatives pages has a short checklist of the jobs people use it for, 5 to 8 of them, with the 2 or 3 core jobs marked. Notion's include pages and docs, databases with views, and real-time collaboration. Each project listed against a product is then read against that checklist, from its README and its website: yes, partly (planned, basic, or needs a plugin) or not shown, with the line that backs each yes or partly.
- The score is the share of the checklist covered. Core jobs count double, partly counts half.
- A project that doesn't show one of the core jobs is held under 50%, so one that does the main thing always ranks above one that doesn't.
- Each project is also tagged as replacing the product, covering one part of it, or doing the same job a different way.
- Stars and activity play no part in the score. Ties go to the more active project.
The checklists and the reading are done with Claude and checked against a hand-made set of pairs before each change. A feature that neither the README nor the website mentions scores as missing, so a project that documents little can rank lower than it deserves. A project is read again when its README or website changes.
Use the data
Everything starwire publishes is free to build on. The list and its data are CC0: no key, no sign-up, no credit needed. All of it refreshes once a day.
| What | Address |
|---|---|
| Every repo, as JSON | https://raw.githubusercontent.com/boffti/starwire/main/data/repos.json |
| The day's best, as RSS (one item a day) | https://starwire.foo/top.xml |
| The 100 newest picks, as RSS | https://starwire.foo/feed.xml |
| Past issues of the weekly email, and as RSS | https://list.starwire.foo/archive and /archive.xml |
| One area as a Markdown list | https://github.com/boffti/starwire/tree/main/lists |
| A repo's badge for its README | https://infinityrepo-share.infinityalgo.workers.dev/owner/repo/badge.svg |
| A repo's share link and card image | /r/owner/repo/ on this site, and its /card.png from infinityrepo-share.infinityalgo.workers.dev |
repos.json is one array with an entry per repo. It can be fetched from a web page, since GitHub serves it to any site.
| Field | What it holds |
|---|---|
repo, url, page | The owner/name, its GitHub address and its page on starwire |
line, description | Our one-line summary, and the repo's own description |
area, subarea, category | Where it sits in the list |
forms, platforms, worksWith, tags | What kind of thing it is, where it runs, what it plugs into, and its themes |
alternativeTo | Products it can stand in for |
stars, forks, language, license, topics, homepage | Facts from GitHub. license is an SPDX id, Other for a custom license, or null for none |
createdAt, pushedAt | When the repo was created and last pushed to |
firstSeen, picks | The day it was first picked, and how many sources have picked it |
starsThisWeek, trending | Stars gained in the last 7 days as we measured them, and whether it's on the Trending list |
starsWhenPicked | Stars it had on the firstSeen day, or null when we couldn't measure it |
Fields are only ever added to this file. None will be renamed or removed, so anything you build on it keeps working. The files under starwire.foo/data/ are the site's own and can change shape without notice; use repos.json instead.
What we count
starwire counts visits with GoatCounter to learn what's useful: no cookies, nothing stored in your browser, no IP addresses kept, no way to follow you to other sites. The numbers are public, so you see exactly what we see.
- Page visits, without the link's settings or saved lists.
- Searches, once you stop typing, and whether anything matched. This shows where search falls short.
- The view or area you open, repos you open, save or share, and clicks through to GitHub. This shows which repos people actually look at.
If your browser sends Do Not Track or Global Privacy Control, nothing is counted and the counting script isn't loaded at all.
Known limits
- Daily star counts started on November 6, 2026. Until about November 13, many repos show fewer than 7 days of gains.
- Bought or fake stars can't be detected reliably from public data yet. Since mid-2026 GitHub no longer shows who starred a repo, and the largest study of fake stars (He et al., ICSE 2026) found that even good detectors can wrongly flag honest projects. A sudden jump or few forks isn't proof either: a Hacker News launch looks the same. We're researching this internally, and nothing on starwire is ranked, hidden or labelled because of it. If you believe a listed repo bought its stars, tell us.
- Picks come from what curators and readers find, so some corners of open source are better covered than others. Submissions help fill the gaps.
Changes to the method
- Nov 12, 2026. Collections only recommend established projects: a pick needs 100 stars and to pass half of its signal checks, or the need is shown as open.
- Nov 12, 2026. Setup knows about hosted versions: a project that needs a server but is also run by its makers is labelled "Hosted", with whether it has a free plan. How setup is read.
- Nov 12, 2026. Setup effort: a label and a filter for how much know-how a project takes to run, and collections open as a stack, need by need. How setup is read.
- Nov 12, 2026. The default order is "Worth a look": daily star gain weighted by five signal checks, so repos with a burst of stars and little else sink. "Most stars today" keeps the unweighted order. How it works.
- Nov 12, 2026. Vital signs are no longer called "healthy", and the issues sign is worded as issues closed against issues opened, which is what it measures. Alternatives pages show the reading in words, with the line behind each mark one tap away.
- Nov 8, 2026. "New this week" and the new label only cover repos created in the last 90 days. Before, any repo picked for the first time counted, so long-established projects showed up as new.
- Nov 8, 2026. Picks from Reddit communities where developers share projects.
- Nov 8, 2026. Repo pages with vital signs, how a repo compares with its alternatives, and how to get started. How the signs are read.
- Nov 7, 2026. Started counting visits, searches and repo opens without cookies. What we count.
- Nov 7, 2026. Started researching fake-star detection internally. It doesn't affect the list or the ranking.
- Nov 7, 2026. Trending uses only measured star gains. Before, a repo's lifetime average was projected forward, which made big repos look like they were still at their launch pace.
- Nov 7, 2026. Stars and repo facts refresh every day instead of every two days.
- Nov 7, 2026. Save repos for later, kept in your browser.
- Nov 6, 2026. Daily star history begins.