Why I stopped caring about GitHub stars
Stars measure attention, not usefulness. The repositories I'm proudest of have triple-digit stars and daily users; the ones with thousands taught me nothing.
By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer

GitHub stars feel like a scoreboard, and for my first year publishing code, I played that game: promoting repos, watching numbers, treating attention as validation. Then I looked at which of my projects actually mattered — and the correlation with stars was nearly zero.
What stars actually measure
A click. One. Not usage, not retention, not whether a single person ever ran the code. Trending pages, listicles, and one good screenshot can move stars more than a year of solid maintenance. Stars measure that the repository was seen.
What I track instead
- clones and downloads — the closest thing to actual use
- issues opened by strangers — people only file issues on software they depend on
- the emails and messages — "we use this in production" from one real team outweighs a thousand stars
- whether I still maintain it — a live small project beats an abandoned popular one
The reframe that freed me
A star is a candidate. A user is a relationship. Optimising for candidates made me build demos; optimising for users made me build tools. The stars followed the useful projects eventually — slowly, honestly — but they were never the goal that made the work good. Build for the person who needs it on a Tuesday. They never star anything; they just rely on you.
One email when a post lands
No schedule, no spam. Just the posts worth reading — new writing on software, AI, products, and the Pharmacy × Tech life.
Prefer a feed reader? Grab the RSS feed.
Keep reading
Open sourceYour first open source contribution doesn't need code
Docs, reproduction steps, and tested bug reports are contributions. The barrier you imagine is lower than the one that exists.
Open sourceReading the issue tracker: the skill nobody teaches
Issue trackers are where projects tell the truth. Learning to read them well reveals what to contribute and what to avoid.
Open sourceThe anatomy of a pull request that gets merged
Small scope, clean description, tests, and the maintainer's style. What separates merged PRs from the ones that die open.