I shipped a thing recently. An open-source project — a self-hosted CMS I built for my own blog — and once the code was clean, the tests were green, and the README had actual screenshots in it, I hit the real wall: how do I tell people about this without being the person who drops links in every conversation and wonders why nobody clicks?
Everyone who builds something for the public internet eventually faces this question. The advice online is split between two unhelpful extremes. One camp says "if you build it, they will come" — which is a movie quote, not a strategy, and was wrong even in the movie. The other camp says "growth hack your way to distribution" — which produces exactly the kind of behavior that makes everyone hate tech Twitter.
The actual answer sits in the middle, and it's simpler than most people think: there are channels designed for sharing what you built, and the difference between spam and genuine engagement is whether you're answering a question someone actually asked.
Where "I made a thing" is the whole point
Start with the channels whose entire reason for existing is discovering new projects.
Show HN on Hacker News is the obvious one — a single post, weekday morning Eastern time, title that tells people what it does and what it's built with. You stay in the comments and answer questions honestly. That's the entire playbook. You get one shot, so make the title descriptive rather than clever, and be present in the thread for the first few hours.
Reddit's r/selfhosted has weekly self-promotion threads where new software is explicitly welcome. Nobody will report you for posting there — it's sanctioned. The same goes for showcase channels on Discord servers for Next.js, self-hosting, and homelab communities. These places exist because communities want to discover new projects. You're not crashing a party — you're showing up to one that sent you an invitation.
Then there are the directories and catalogs. The awesome-selfhosted list on GitHub is probably the single highest-leverage pull request you can make for a self-hosted tool. Thousands of people browse it when they're looking for exactly your category of software. OpenAlternative lists open-source alternatives to commercial products. AlternativeTo, StackShare, selfh.st — each one is a passive discovery channel that works forever. Submit once, maintain the listing, and people find you through search for years.
These channels don't require clever marketing. They require accurate descriptions and honest categorization. The work is showing up, not selling.
Content that pulls people in
The slower, more powerful engine is content. Not "Top 10 Reasons to Use My CMS" — nobody reads those, and the people who do don't trust them.
Write the story of why you built it. What problem did you have that made you start? What did you try first? What tradeoffs did you make and why? A launch post on your own blog that's honest about the build process will get shared more than any feature list. People share stories. They bookmark reference material. A good "why I built this" post compounds: it surfaces in searches for the problem you solved, it gives people who discover your project a human reason to care, and it anchors the project in a real need rather than a feature matrix.
Dev.to posts with real technical substance work similarly — "Building a multilingual blog engine with Next.js and TipTap" or "Designing a permission-scoped API key system" — where the repo link appears naturally because it's the artifact of the lesson. Those posts get indexed well and bring people in through search for months. The key is that the post has to stand on its own as useful content. If someone would get value from it even if they never visit your repo, you've done it right.
Contextual mentions: the hardest and best channel
The last channel is the hardest to do well and the most effective when you nail it: contextual mentions.
Someone on Reddit asks "what's a good self-hosted blog platform with an API?" and you built exactly that. Answering with your project isn't spam — it's the answer they were looking for. The difference between helpful and annoying is entirely about whether you're responding to a real question or manufacturing one. Same product, same link, completely different reception depending on whether it lands as "here's what you asked for" or "here's what I'm selling."
This requires patience. You can't force the questions to appear. What you can do is set up alerts for relevant discussions, follow the communities where your users already are, and only speak when you genuinely have the answer. One well-placed, genuinely helpful comment is worth more than a dozen unsolicited link drops. People can tell the difference instantly.
The reality nobody wants to hear
OSS traction is a slow drip, not a launch spike. A Show HN post plus a couple of directory listings plus a few good content pieces will get you the first few dozen stars and users. The rest comes from shipping visibly over months — release notes, changelog activity, responding to issues. The projects that grow are the ones that look alive when people check back.
The graveyard of open-source projects that were great ideas but got one announcement post and then silence is enormous. Don't join it. The best marketing for an open-source project is continued development. Every merged PR, every closed issue, every changelog entry is a signal that says "this project is worth your attention."
Building the thing was the hard part until it wasn't. Getting people to care is a different muscle — slower, softer, more about listening than broadcasting. But if you built something that solves a real problem, you don't need to convince anyone. You just need to be findable when they go looking.
So: submit to the directories. Write the story of why you started. Ship visibly and consistently. And the next time someone asks for exactly what you built, you're not spamming. You're answering.
