A repository has 80,000 stars. Another gained 4,000 this week. A third is new, smaller, and unusually active. Those are three different observations, but a generic “top projects” page often collapses them into one ranking. The result is easy to scan and hard to reason about.

I built AI Open Source Radar because I wanted a better first step—not an automated verdict, and not another permanent leaderboard.

The public site is here: AI Open Source Radar. It is free to browse and does not require an account.

A total is not a movement

Stars answer a narrow question: how many GitHub users have starred this repository so far?

They do not tell me:

• when that attention arrived;
• whether the project is still moving;
• whether a small project is accelerating faster than an established one;
• whether a jump came with releases, forks, documentation, or only a burst of attention;
• whether two similarly named entries resolve to the same upstream repository.

That is why the Radar starts with dated views rather than one master score. The current interface separates daily, weekly, and monthly trends from seven-day breakouts, new-project activity, trending streaks, fork momentum, classic comebacks, and a China-focused view.

These are not decorative tabs. Each represents a different question.

“What moved today?” is not the same as “what has sustained attention for a month?” A mature project returning to activity should not be presented as a new breakout. A repository with fast fork growth may be interesting for a different reason than one accumulating stars.

Repository identity comes before enrichment

Project discovery becomes unreliable when display names are treated as identities. The stable unit is the upstream owner/repository path.

That sounds obvious, but it affects the rest of the product:

1. Every card needs a direct route to the upstream repository.
2. Summaries and labels must remain attached to the same repository identity.
3. Historical observations need to resolve to that identity before movement is compared.
4. Renames, archived repositories, and missing fields should remain visible as data problems rather than being silently patched with confident prose.

The Radar therefore treats its own text as a discovery aid. The GitHub repository remains the primary place to inspect code, releases, issues, documentation, and the complete license terms.

A useful card needs more than a rank

A rank can earn attention, but it cannot support evaluation by itself. I wanted each project card to reduce the cost of deciding whether a repository deserves a closer look.

Depending on the available evidence, cards can expose:

• repository identity;
• a practical summary;
• project type and likely use case;
• primary language;
• star and fork observations;
• license information;
• intended audience;
• a direct upstream link.

The important part is not filling every field. It is refusing to invent certainty when a field is absent or ambiguous. Unknown license evidence is more useful than a guessed license. A missing suitability judgment is safer than a generic “production-ready” label.

Categories and collections answer different questions

Rankings are good for movement. They are poor at answering “show me tools for this kind of work.”

The Radar also provides categories and collections so users can move from a signal to a problem space. An AI coding tool, an MCP server, an agent framework, a RAG project, and an image workflow may all be active at the same time, but they are not interchangeable candidates.

Separating category, type, and use case keeps comparison from starting too early. The first useful decision is often not “which repository is best?” but “which class of project am I actually looking for?”

The website deliberately stops before adoption

This is the boundary I care about most.

The Radar is not:

• a security audit;
• a license opinion;
• an endorsement;
• proof of maintenance quality;
• a prediction of future adoption;
• permission to run third-party code.

It is a discovery and inspection interface. Before adopting a project, users still need to review the repository, documentation, releases, open issues, security posture, dependencies, and complete license text.

Popularity is evidence of attention. It is not evidence of fitness for a particular environment.

Why the site is bilingual and account-free

Discovery tools lose value when the first action is account creation. The Radar is public because opening an upstream repository should be a low-friction action.

The English interface lives at useaistation.com/githubai, and the Chinese interface is at aiworkstation.cn/githubai. They share the same product idea while keeping interface language and entry points appropriate for their audiences.

What I am trying to improve next

The difficult work is not adding more cards. It is improving how movement and evidence are explained without turning them into a fake universal score.

The questions I am currently testing are:

• Which time windows help people distinguish a breakout from accumulated popularity?
• How should fork momentum be shown without implying code quality?
• Which missing fields should be explicit on the card rather than hidden?
• How much explanation is enough before the interface becomes slower than GitHub search?
• When should a project leave a “new” or “breakout” view?

If you work with open-source AI projects, I would value feedback on those decisions. Try the AI Open Source Radar and tell me which signal helps—or misleads—you first.

This article was drafted with AI assistance, then checked and revised against the live product by its builder. I am responsible for the claims, links, and final text.