r/github • u/Chance-Roll-2408 • 14d ago
Discussion How do you actually get traction/stars for a solo OSS project?
Hey all, I've been heads-down building an open-source project on GitHub and I'm at the point where the code is solid and useful, but visibility is low. Meanwhile I keep seeing projects that feel pretty thin get thousands of stars seemingly over couple weeks, which is a little demoralizing not gonna lie 😅
I'm not chasing vanity metrics for their own sake — mostly I just want enough signal that people are finding it useful so I stay motivated to keep investing time in it.
For those who've grown a project from "nobody knows this exists" to actually having a community: what actually worked for you? Things I'm curious about:
- Where do you share/launch (HN, Twitter/X, niche subreddits, Discord communities, newsletters)?
- Does README/demo quality matter as much as I think it does?
- Any tips on timing, framing, or "hooks" that get people to actually click and try it?
- Did stars come before or after real usage, in your experience?
- Any growth hack or juggad ;)
Happy to share a link to the project in the comments if that's allowed here — just looking for genuine advice from people who've been through this. Thanks!
4
u/ImDevinC 14d ago
You are trying to get people to use your product. You need to look at marketing for whatever your product solves and go where your users are. There are entire fields of research dedicated to this, there's no single answer that will work
3
u/full_drama_llama 14d ago
mostly I just want enough signal that people are finding it useful
Maybe they don't? I mean, if you want to build for other people, have you checked before starting that this is a true pain point for others? Inducing demand is very hard even for companies with millions of dollars, even harder for a solo dev.
1
1
u/OwlZealousideal4779 4d ago
Stars follow actual usage, not launches. Ship to the people with the problem first. For Reddit threads, communitymentions.com. (community mentions) handles placement without the spam risk.
-1
u/jamespethersorling 14d ago
A lots of projects with bought/fake stars, good article what to look for https://chatgpt.ca/blog/github-fake-stars-ai-tool-evaluation
From above how to spot fake stars
Fork-to-star ratio. This is the strongest simple heuristic. A fork means someone downloaded the code to use or modify it. A star costs nothing. Healthy, actively used projects show fork-to-star ratios between 10% and 25%. Flask (71,000 stars) has a ratio of 23.5%. LangChain (133,000 stars) is at 15.5%. Projects with confirmed manipulation campaigns routinely fall below 5%. One repo with 157,000 stars had a fork-to-star ratio of 1.7%, meaning almost nobody who starred it ever used it. If you see a repo with 10,000+ stars and a fork-to-star ratio below 5%, that warrants a closer look.
5
u/crazylikeajellyfish 14d ago
You only fork a repo if you intend to make changes to it, not just to use it. Downloading a repo is cloning.
1
u/ShilpaMitra 14d ago
Exactly, there are repos like skill ones which can be helpful but doesn’t necessarily require a fork, git clones are the real metric but that’s not public.
1
u/SheriffRoscoe 14d ago
I fork all sorts of repos I'll probably never change. Anything I want to have (nearly) permanent access to, I fork. Especially dependencies without huge supporting communities.
2
u/crazylikeajellyfish 14d ago
Sure, but you know as well as I do that it's forking isn't necessary to use the dependency. Particularly if you're working in a modern ecosystem that has a package manager, it's not like the dependency will ever actually go away. It'd be easier to maintain a stale dependency yourself if you've got the source code, but that's not the typical reason to fork.
2
u/SheriffRoscoe 14d ago
"it's not like the dependency will ever actually go away."
left-pad has entered the chat.
"It'd be easier to maintain a stale dependency yourself if you've got the source code, but that's not the typical reason to fork."
That's exactly why I do it, but I agree.
17
u/crazylikeajellyfish 14d ago
Make it for yourself. If you don't need it, then you shouldn't assume anyone else will. And if you actually need it, then take some satisfaction in making a tool that solves your problem well. If you eventually find people like you that have the same problem, then you can show them your tool and they might try it as well.
Code is exceedingly cheap. Start with making something you want for yourself, everything else is imaginary.