// log entry · npm

@v0idd0 has 3,963 weekly downloads and almost no stars.

the studio's npm scope is @v0idd0. it went from zero packages to twenty-five published in about six weeks. as of tonight the public npm api reports 3,963 downloads in the last seven days across the catalogue. the github repos publishing those packages have, between them, a number of stars you can count on one hand without using the thumb.

that is the entire post. the rest is just an attempt to explain why neither number bothers us.

what the catalogue is.

twenty-five packages, all single-purpose, all under a hundred lines of code where possible. the most-downloaded ones in the past week, in order:

the rest of the catalogue makes up the difference. some packages get fifty downloads a week. a few get under ten. one of them is @v0idd0/timecheck, which we keep alive because the timezone math is annoying enough that even ten people a week using it is worth shipping.

why nobody stars these.

three reasons, in order of how often we hear them:

they are too small to be impressive. nobody stars a regex tester. a thirty-line cron parser is not a project, it is a tool. people star libraries. they star frameworks. they star things they could imagine themselves needing in the future. they install our packages, use them, and close the tab.

npm and github are different surfaces. a download is a person typing npm i. a star is a person on github thinking "this might be useful later". those are different verbs. our catalogue is built for the first verb. the second verb requires a project shape — an open issue tracker, a roadmap document, a contributor culture, a discord. we do not have those. we have npm publish.

the studio name does not promise community. when you find a package by @vercel or @nrwl you star it because the org around it is something you want to know about. @v0idd0 is six engineers shipping things and not maintaining a discourse. there is nothing to follow.

does the gap matter.

occasionally. the gap matters when an investor or potential partner pulls up our github org and counts stars to decide if we are real. it does not matter to the user installing @v0idd0/cronwtf at three in the morning to debug a cron expression. they got what they came for. they will be back.

downloads are a more honest signal than stars for this kind of catalogue. stars cluster heavily on a few flagship projects and then taper off. downloads are a long-tail distribution that reflects actual use. the studio's shape is the long tail. four thousand downloads a week distributed across twenty-five packages is more interesting than four thousand downloads a week on a single hyped project that nobody actually uses.

what we are doing about it.

not much. the readme files are now uniformly long enough to be useful (a separate fight, recently won). the github org page is curated. cross-promotion between repos is automated. if someone lands on one package they can find the other twenty-four without effort. that is roughly all the discovery work that is worth our time.

asking for stars is a tax on every interaction. we do not do it. if a package is good enough that you want to star it, the star button is right there. if it is not good enough, no amount of "★ this repo if it helped you" footer will make it so.

the next number.

we expect the weekly download count to drift upward as the catalogue ages and search engines start indexing the readme files we just rewrote. we do not expect stars to follow. that is fine. the number we actually care about is the one that costs money: does anyone reach for the paid extension after using the free tool. we will write about that one when we have an answer.

← all log entries say something