Ghost Repos: The Most Dedicated Projects Nobody’s Ever Heard Of

I’ve been building CodeWeaver for eight months. It’s a semantic code search MCP server — hybrid dense/sparse search, tree-sitter parsing across 170+ languages, support for 20+ embedding providers. It has 1,300 tests, a DI system, a failover architecture, and a plugin system. It has 8 stars.

That’s not a complaint. But it made me wonder: how many projects like this are sitting on GitHub right now? Not abandoned repos or weekend experiments — projects where someone has been showing up, month after month, writing real code, filing issues, merging PRs, shipping releases — and the world hasn’t noticed.

It turns out GitHub can’t answer that question. So I did.

Why GitHub search fails here

GitHub’s discovery mechanisms — stars, trending, Explore — are social signals. They measure awareness, not effort. And the most direct measure of sustained effort, commit count, isn’t searchable through the API at all.

You can filter repos by stars, language, size, and last push date. You can’t filter by how many commits someone has made, how many months they’ve been active, or whether they’re filing issues and merging PRs like someone building a real product.

Someone actually asked GitHub to add this. They acknowledged the idea. It hasn’t happened.

How I found them

The raw data exists. GH Archive records every public event on GitHub and makes it available as a BigQuery public dataset. I queried about 5 TB of event data spanning all of 2025 and early 2026.

The query itself went through six iterations before it produced useful results. Each round taught me something about how much noise exists on GitHub:

v1 summed commit counts from push events. Every result had 100M+ “commits” because pushing a full repo clone reports the entire history as a single event. Useless.

v2 switched to counting push events instead. Got the 500 most hyperactive automated repos on GitHub. Every row was a cron job.

v3 added an upper bound on pushes. Still mostly uptime monitors and data scrapers that push exactly within the “human” range.

v4 required PR and issue activity. This killed most bots — but Renovate and Dependabot create PRs too.

v5 required meaningful thresholds (10+ PRs, 5+ issues opened, 30+ total project workflow events). Combined with a two-stage quality inspection via the GitHub API — checking for real programming languages, tests, CI, releases, and commit message diversity.

v6 extended the date range and tightened noise filters further.

The insight that finally cracked it came from thinking about my own project. Even though I’m the only human contributor to CodeWeaver, it has ~230 issues and ~120 PRs — because that’s how modern solo development works. You use AI agents, you use proper branching workflows, you file issues to track work. A cron job pushing data every hour will never have that. PR and issue activity turned out to be the strongest signal separating a real project from an automated data dump.

What this analysis can and can’t tell you

Before I get to the results, I want to be honest about what this data actually measures.

There are three axes worth thinking about when it comes to a GitHub project:

• Distribution — how many people have found it. Stars measure this.
• Effort — how much sustained work has gone into it. Commits, PRs, issues, and time measure this.
• Quality — how good the code, architecture, and design actually are. Neither stars nor commits measure this well.

This analysis found projects in the far corner of the effort/distribution plane: high effort, low distribution. That’s interesting on its own. But I want to be careful not to swap one bad proxy for another. Saying “these projects must be great because they have a lot of commits” is the same error as saying “these projects must be great because they have a lot of stars,” just inverted. Someone can pour 39,000 commits into something that’s architecturally questionable. Someone can maintain a library for 12 years out of stubbornness rather than excellence.

Some of these projects might be invisible for perfectly good reasons. Not everything deserves an audience.

What is true: there’s an entire dimension of work on GitHub — sustained, dedicated, month-over-month effort by real people — that current discovery mechanisms can’t surface. We can’t even evaluate most of these projects because the tools to find them don’t exist. That’s the actual problem this analysis reveals. Not that these projects are all great. That we have no way of knowing.

The numbers

Metric	Value
Ghost repos found	401
Combined commits	578,822
Combined stars (all 401 repos)	5,001
Commits per star	116
Average repo age	3.7 years
Repos with 0 stars	52 (12%)
Repos with ≤ 5 stars	182 (45%)
Repos with tests	178 (44%)
Repos with CI	385 (96%)
Repos with a license	331 (82%)
Repos with releases	235 (58%)

The CI, license, and release numbers indicate that many of these developers are working with professional habits — not that the outputs are necessarily high quality. Process and results aren’t the same thing. But it does mean these repos aren’t slapdash weekend experiments. Someone cared enough to set up a pipeline.

The ghost repos

I visited many of these by hand. I can’t vouch for code quality in most cases — I’d have to read the code, and that’s a different project. What I can tell you is what the commit history, the project structure, and the human story behind each one look like.

The Warhammer Engineer

tomwillis608/thicker-stl

533 commits · 0 stars · Python · 1 year

“Today’s TTRPG mini figures are too dainty. Make those STL thicker.”

Someone had a specific, personal frustration with tabletop miniatures being too fragile to print and spent a year building a Python tool to proportionally scale them. Zero stars. But when you look inside, this person is clearly holding themselves to a standard. Full test coverage, CI, docs, MIT license.

And then there’s the Definition of Done file:

• Architecture is screaming
• Code reviewed by external agents
• Tech debt eliminated to current understanding of domain

This person is running a one-person engineering org, using AI as code reviewers, holding themselves to standards that would pass review at a real company. For a tool to thicken their Warhammer figures.

I love everything about this. Zero stars.

The Spreadsheet From Scratch

mP1/walkingkooka-spreadsheet-dominokit

~13,338 commits · 1 star · Java · 3 years

This is the most striking find in the dataset. And it’s only half the story.

GitHub user mP1 isn’t just building a spreadsheet. They’ve built an entire software ecosystem from scratch in Java. walkingkooka-spreadsheet is the core engine: ~15,712 commits, 6 stars. walkingkooka-spreadsheet-dominokit is the browser frontend: ~13,338 commits, 1 star. There’s a server abstraction layer (~4,306 commits), a core utility library (~5,418 commits), and then a constellation of supporting libraries — a tree graph library, a JSON library, a color library, an expression parser, a plugin system, a currency system.

Seventy-four walkingkooka repositories in total. Nearly 39,000 commits across the four main repos alone. 390 MB of source code. 95 out of 100 public repos are Java. 34 total stars across everything.

One person, building a browser-based spreadsheet application from the ground up — not reaching for existing libraries, but writing every dependency from first principles. For years. With essentially nobody watching.

I’m not going to tell you this is a hidden masterpiece — I haven’t read the code. Building everything from scratch could be a sign of deep expertise or of not-invented-here syndrome. But the sheer commitment is extraordinary. Whether you admire the approach or question it, 39,000 commits with 34 stars is a level of dedication that deserves to be seen, if only so people can form their own opinion.

The Seven-Year Accountant

orange-buffalo/simple-accounting

1,471 commits · 1 star · Kotlin + Vue · 7 years

Bogdan Ilchyshyn has been building an accounting application for seven years. Kotlin backend, TypeScript/Vue frontend, Docker-deployable. From what I can tell, it’s essentially self-hosted QuickBooks as open source. CI, docs, five releases.

That’s 210 commits per year, every year, for seven years, with one star.

The E-Invoicing System

rossaddison/invoice

1,937 commits · 1 star · PHP · 2 years

A professional e-invoicing system built on Yii3 with UBL 2.1 and Peppol support — this isn’t a toy invoice generator. Translated into 30+ languages. Thirteen million bytes of PHP. Tests, CI, docs. The topics list reads like a product spec sheet. One star.

The Rust JVM

hextriclosan/rusty-jvm

1,321 commits · 50 stars · Rust · 1 year

A JVM implementation written in Rust. Over a million bytes of Rust, 387K bytes of Java test code. Tests, CI, docs, MIT license. This scored the highest quality-signal rating in the entire dataset — though that measures project structure, not code quality. Fifty stars is the ceiling of our filter. For a JVM written in Rust, that feels low regardless.

The Nine-Year Swiss Army Knife

OpenAF/openaf

1,197 commits · 13 stars · JavaScript/Java · 9 years

A “swiss-army knife” scripting tool for DevOps automation. Tests, CI, docs, Apache-2.0 license, five releases, its own package ecosystem (opacks). Nine years of development. Thirteen stars. This is the kind of tool that, if it had landed on Hacker News in the right week, might have thousands. Or it might not — I genuinely don’t know. That’s the point.

The Invisible AI Agent

srtab/daiv

671 commits · 19 stars · Python · 1 year

“Your AI-powered SWE teammate, built into your git workflow.” An AI coding agent with 880K bytes of Python, tests, CI, docs, Apache-2.0, five releases. In a category where projects routinely get thousands of stars for a wrapper around an API, this one has 19.

The Protein Simulator

tkemmer/NESSie.jl

637 commits · 9 stars · Julia · 8 years

Nonlocal Electrostatics in Structured Solvents. A computational biophysics package implementing boundary element methods for protein electrostatics. Eight years of scientific computing work. Nine stars. Somewhere, a grad student or researcher could use this and has no way of finding it.

The EV Tracker

mthmulders/traqqr

502 commits · 0 stars · Java · 2 years

A web app for tracking electric car energy usage. Jakarta EE, OpenLiberty, deployed on Azure. Tests, CI, docs, MIT. Zero stars.

The Five-Language Karaoke App

Japan7/karaberus

1,829 commits · 1 star · Go + TypeScript + Rust + Python + C · 2 years

A karaoke file management application. Five languages. Tests, CI, docs, AGPL-3.0, five releases. One star.

The Twelve-Year PHP Library

mimmi20/browser-detector

1,040 commits · 48 stars · PHP · 12 years

A PHP library for browser and device detection. Twelve years of development. Over 3.5 million bytes of PHP. Tests, CI, five releases, MIT license. 48 stars for a library that’s been maintained longer than most developers’ careers. Whether it’s the best browser detection library out there, I have no idea. But someone has been showing up for twelve years.

The Lambda Framework Nobody Found

marvin-j97/lemna

196 commits · 0 stars · TypeScript · 5 years

An AWS Lambda scaffolding and deployment tool. Five years of quiet maintenance. Tests, CI, docs, MIT, five releases. Zero stars. It works. Nobody knows.

What this tells us

Stars measure distribution. Commits measure effort. Neither measures quality. This is the core takeaway. We tend to treat star counts as a quality proxy, but they’re really a distribution proxy — they tell you how many people found the project and clicked a button. This analysis found the inverse: projects with enormous effort and near-zero distribution. The missing piece in both cases is quality, which requires actually reading the code. Current discovery tools don’t give us that, and this analysis doesn’t either. What it does give us is a view of a dimension — sustained human effort — that was previously invisible.

Discovery on GitHub is almost entirely a marketing problem. The gap between effort and visibility is enormous. Some of these developers may be building something extraordinary. Some may not. But we can’t evaluate what we can’t find, and right now there’s no mechanism to surface projects based on the work that’s gone into them rather than the attention they’ve received.

These developers are solving their own problems. Invoicing. Karaoke management. Warhammer miniature printing. Electric car tracking. Handball season scheduling. Protein electrostatics. They’re building for themselves, and the outside world is a bonus. That’s probably the healthiest motivation for open source — it means the project survives regardless of whether anyone else notices.

AI is changing the workflow but not the visibility problem. Many of these repos show signs of AI-assisted development — high PR counts relative to pushers, automated workflows, definition-of-done files aimed at AI agents. The 2025 solo developer isn’t alone in the same way a 2020 solo developer was. But AI can’t generate stars. The marketing problem remains entirely human.

This is part one

I have 401 repos in this dataset, and I only profiled a dozen here. There are stories in the rest — I know because I’ve been scrolling through them.

I’m thinking of this a recurring series — every week or two I’ll pick a ghost repo from the dataset (or a new one submitted by readers), actually visit it, read some code, and write up what I find — including, honestly, whether it’s any good. The data found these projects. The follow-up series will try to evaluate them.

If you want to nominate a project — yours or someone else’s — I’d love to hear about it.

The methodology and the data

Everything is open source:

• Data exploration tool
• BigQuery SQL and Python verification scripts are available here
• The full scored dataset of 401 ghost repos is available as a CSV
• Total BigQuery cost: about $30 against Google Cloud’s free trial credit

The pipeline is designed to be rerun monthly. The query is parameterized — change the date range, star threshold, or activity filters and run it again.

If you find something in the dataset that looks interesting, star it. It’s one click. For the person on the other end, it might be the first signal in months that someone noticed.

---

I’m Adam, founder of Knitli. I build CodeWeaver, a semantic code search MCP server, and Thread, a Rust-based code intelligence platform. My projects are exactly the kind of thing this analysis was designed to find — and yes, I’m fully aware of the irony of writing a blog post about invisible projects as a way to make my own less invisible. It’s called content marketing and I’m told you have to do it.