You shipped your open source project. The code is solid, the README looks good, and it solves a real problem. But the repo sits at 12 stars (half from friends), zero contributors, and nobody's opened a discussion. The code isn't the problem. Nobody knows it exists.
The distribution problem for open source
Open source has a discovery paradox: the best way to find users is to already have users. People trust projects with stars, active issues, and recent commits. A repo with 5 stars looks abandoned, even if the code is excellent. GitHub's trending page, Hacker News, and Reddit all amplify projects that already have momentum. So your first job isn't writing more features. It's creating the initial wave of attention that makes the rest compound. And that wave almost never happens organically.
Channels that actually work
1. Hacker News (Show HN)
Show HN is the single highest-leverage launch channel for open source projects. A front-page post can drive 10,000+ visitors to your repo in a single day. Link directly to GitHub, not a landing page. Write a plain title that explains what the project does. "Show HN: Plausible, lightweight open-source alternative to Google Analytics" works. "Show HN: The privacy revolution" does not. Post Tuesday through Thursday, US morning time. Respond to every comment, even the critical ones. Supabase hit the HN front page two days running in 2020 and went from 80 to 800 users overnight.
2. Reddit (niche subreddits, not r/programming)
Generic subreddits will ignore your project. The real traction comes from the specific communities where people look for tools like yours. r/selfhosted (380k+ members) is the best subreddit for self-hostable open source tools. r/commandline works for CLI projects. r/webdev, r/node, r/reactjs, r/golang, or r/rust will reach developers using your specific stack. For privacy-focused projects, r/privacy and r/degoogle are gold. The post format that works: explain the problem you solved, show a screenshot or GIF, link the repo, and ask for feedback. Don't cross-post to five subreddits the same day.
3. GitHub itself as a distribution channel
Your repo is your landing page. Optimize it like one. The README needs a "get started in 30 seconds" section with a single copy-paste install command. Add a demo GIF or screenshot above the fold. Label issues with "good first issue" and "help wanted" to attract contributors. Respond to every issue within 24 hours, even if it's just "thanks, looking into this." Submit your project to awesome-lists in your category (awesome-go, awesome-python, awesome-selfhosted). List it on openalternative.co if it competes with a commercial product. These directories send a steady trickle of traffic that compounds over months.
4. Technical blog posts and Dev.to
Write about the problem your project solves, not the project itself. If you built an open-source analytics tool, write "Why Google Analytics is overkill for most websites" and mention your tool where it's naturally relevant. Plausible's blog post "Why you should stop using Google Analytics" drove 48,000 unique visitors in a single week and more than doubled their GitHub stars. Cross-post to Dev.to, Hashnode, and Lobsters. These posts rank in Google and keep sending traffic for months. One strong post per week is more effective than daily short updates.
5. Launch Week format
Instead of trickling out improvements, batch three to five features into a single week. Announce one per day on X and Hacker News. Supabase pioneered this format and it works at any scale. Even a solo maintainer can save up a month of improvements and release them as a coordinated push. It gives people a reason to re-check your project and generates multiple chances to hit the front page of HN or trending on GitHub.
Common mistakes open source maintainers make
- Waiting to promote until the project is "ready." There's no ready. Ship early, get feedback, iterate in public. The projects that grow fastest launch with rough edges and fix them alongside real users.
- Ignoring the README. For open source, the README is your pitch, your docs, your onboarding, and your landing page. A wall of text with no install instructions kills adoption instantly. Add a GIF, a one-liner install, and a "why this exists" section.
- Building features instead of distribution. After launch, the default instinct is to go back to coding. But the first six months of an open source project should be 50% distribution work: posting in communities, writing content, responding to issues, and showing up where your users hang out.
- Launching on Product Hunt and expecting developers. Product Hunt traffic skews non-technical. For open source devtools, it's a vanity metric. Put that energy into Hacker News and Reddit instead.
Real examples
Plausible Analytics grew from $400 to $2,750 MRR in 135 days through community-driven distribution. Their blog post challenging Google Analytics drove 48,000 visitors in one week. Top traffic sources: Hacker News (43,600 visitors), Twitter (10,000), Indie Hackers (4,800), Dev.to (2,200). No paid ads. Just consistent content and genuine participation in privacy and web development communities.
Supabase launched with back-to-back Hacker News front-page posts and grew to over 100,000 customers without traditional marketing spend. They invented the Launch Week format, shipping one major feature per day for a week while coordinating announcements across X, HN, and their Discord. They hired contributors from their own community and built in public from day one.
PocketBase gained massive traction as a single-developer project. The pitch was the repo itself: one Go binary, zero dependencies, embedded SQLite. The README sold it in seconds. A Show HN post and organic sharing in r/selfhosted and r/golang drove the initial wave. The simplicity of "download one file and run it" made it easy for anyone to try, which turned first-time visitors into advocates.
Find your distribution channels
Every open source project has a different ideal distribution map. It depends on who exactly you're building for and what problem you're solving. The channels that work for a self-hosted analytics alternative are different from what works for a JavaScript framework or a CLI tool for DevOps teams.
Want to find out which channels will work for YOUR open source project? Stride's free audit analyzes your product and audience to surface the gaps.