Stars, Views, and Clones Across 63 Repos

I released version 0.2.0 of stargazers last week, a CLI I use to pull the event data sitting behind a GitHub star count, and ran every command against my own account. Then I ran it again, because an account-level query misses the largest thing I have worked on. category_encoders lives under scikit-learn-contrib, so as far as /users/wdm0006/repos is concerned it does not exist.

Including it roughly quadrupled the numbers and reversed one of my conclusions. Here is the whole picture, plus how to get the same for yours.

What it does

A star count is a running total with no shape to it. Stargazers pulls the underlying events and writes them out as CSVs with a summary in the terminal. There are seven commands:

• repos fetches every stargazer of a repository and enriches each one with their profile, so you get followers, company, and location rather than a list of usernames.
• forkers does the same for forks.
• account-trend walks every repository an account owns and reconstructs a daily star history across all of them.
• traffic pulls views, clones, and referrers per repository.
• contributors and issues summarize who is doing the work and how fast things close.
• plot charts any of the resulting CSVs in the terminal.

Two limits worth knowing up front. GitHub’s traffic API retains 14 days and requires push access, so traffic covers repositories you can push to and nothing else. Star history is reconstructed from the starred_at timestamp on surviving events, so anyone who starred and later unstarred does not appear.

Running it

It installs from my Homebrew tap:

brew install wdm0006/tap/stargazers

Give it a token, or you will hit the unauthenticated rate limit about four repositories in:

export GITHUB_TOKEN=$(gh auth token)

The account view is two commands, and both take --include-repo for anything you maintain outside your own namespace. That flag is the entire reason the numbers below are right:

stargazers account-trend wdm0006 --include-repo scikit-learn-contrib/category_encoders
stargazers traffic wdm0006 --include-repo scikit-learn-contrib/category_encoders

Individual repositories take a full owner/repo, and most commands accept several at once:

stargazers repos wdm0006/pygeohash
stargazers issues wdm0006/git-pandas wdm0006/keeks

Everything lands as CSV in the working directory.

Two curves going opposite directions

Across 63 repositories there are 3,626 stars. category_encoders is 2,495 of them, so one repository in another organization accounts for 69 percent of everything. Of the 62 I own, 24 have any stars at all.

Splitting the yearly history into category_encoders and everything else is the most useful thing this exercise produced:

        everything   category_encoders   my own repos
2015        105              13                92
2016        405             134               271
2017        324             186               138
2018        449             333               116
2019        583             451               132
2020        452             369                83
2021        327             270                57
2022        363             319                44
2023        234             204                30
2024        138             116                22
2025        114              64                50
2026        132              36                96  (through August 8)

category_encoders peaked in 2019 at 451 stars and has fallen every year since, down to 36 so far this year. My own repositories bottomed out at 22 in 2024 and are at 96 with a third of the year left. 2026 is the first year since 2016 that the things in my own namespace took more stars than category_encoders did.

Looking at the combined column alone, I would have concluded I peaked in 2019 and have been sliding ever since. That is true of the aggregate and false of both components.

Lifetime stars against recent ones

                                lifetime   last 12 months
category_encoders                   2495          56
flink-python-examples                251           5
git-pandas                           191           3
pygeohash                            177          12
python-skills                         77          77

A star never expires, so the top of that list is mostly a record of when I was writing things people were searching for. flink-python-examples is a set of examples for a version of Flink’s Python API that has since been replaced. Those 251 stars are 2015 and 2016, preserved.

Then the clone counts

I expected traffic to broadly agree with the star ranking. Fourteen days across all 63 repositories:

Account-wide that is 3,853 views against 8,676 clones. git-pandas is the sharp one: 30 page views and 1,935 clones, a ratio of sixty-four to one, or twenty-nine to one counting only unique visitors.

Clone counts include CI runs, mirrors, package builds, and crawlers, so plenty of that is machines rather than people. The comparison still holds, because every repository sits under the same bot weather, and flink-python-examples got 36 clones while git-pandas got 1,935.

Which sorts things into three groups. Old repositories with stars and no traffic. Quiet ones with heavy clone counts, because they stopped being interesting a while ago and became something other projects depend on. And whatever is currently new, which has views and stars and no history yet.

category_encoders is the only one that lands in more than one group. It has 231 unique viewers, second only to python-skills, and 520 unique cloners, more than anything else I have. Its stars have been declining for six years while actual usage stayed put, which is the clearest evidence I have that the two measure different things.

Where the traffic comes from

Of the views GitHub could attribute to a source:

Google              2,424  (694 unique)
github.com            224
Bing                  205
search.brave.com       86
DuckDuckGo             50
claude.ai              36
pypi.org               15
perplexity.ai           5
chatgpt.com             1

Google is 78 percent of attributed referrals and 63 percent of all views for the fortnight. Everything else combined, including GitHub’s own internal discovery, comes to 703 views. Nothing arrived from social media in a quantity worth printing.

The assistants total 43 views once you add doubao.com, a bit over one percent. Worth noting that 36 of those came from three unique visitors on claude.ai, so that is somebody working through several repositories in a chat window rather than a trickle of one-offs.

Issues and contributors

Running issues across five of my own repositories covers 416 issues and pull requests. Nineteen issues and eight pull requests are open. Median time to close is 0.84 days and the ninetieth percentile is 49 days, so things either get handled that afternoon or sit for two months. I opened 339 of the 416, Dependabot opened 16, and the largest outside contributor opened five.

category_encoders is a different kind of repository, and the same command makes that obvious. It has 496 issues and pull requests, 31 issues and 6 pull requests open, a median close time of 12.86 days, and a ninetieth percentile of 522 days. I opened 32 of the 496, which is under seven percent. The top author is janmotl with 34.

The contributor split says the same thing. My own repositories have 26 contributors across 491 commits, and the largest one who is not me has 11. category_encoders has 55 contributors across 711 commits, of which I wrote 52. janmotl wrote 197.

The oldest open item on my own repositories is git-pandas issue 9, filed 2,641 days ago. On category_encoders it is issue 46, at 3,145 days.

What I do with this

Clone counts are the adoption signal I did not previously have, noisy as they are. git-pandas and pygeohash have real dependents and flat star growth, which is a combination I was reading as decline.

Splitting category_encoders out of the aggregate is the change I would recommend to anyone with one project much larger than the rest. A single big repository dominates every account-level number you look at, and the aggregate keeps telling you a story about that one repository rather than about anything else you are doing.

And since roughly two thirds of discovery arrives through Google, the README is the landing page, which is worth remembering when writing one.

All of this was already in the GitHub API. The only reason I had not looked was that it comes back one page at a time in a shape nobody wants to read.