Building an open source project is the easy part.
Getting people to find it, use it, and keep using it — that's the challenge. And it's one most developers never seriously address until the initial launch momentum fades and the stars stop coming.
Here's what actually moves the needle.
The distribution mistake
The default assumption: publish to GitHub, wait for organic discovery.
The reality: GitHub's search is weak for finding new tools. Trending is unpredictable and short-lived. Unless your project hits a major aggregator or gets shared by someone with a large following, GitHub organic traffic alone won't build a user base.
You have to go to where developers already are. Actively, not once.
The channels that work for early traction
Not all distribution channels are equal for dev tools. Based on what consistently works for early-stage OSS projects:
Hacker News "Show HN" — High signal audience, genuinely interested in new tools. A well-written Show HN post for the right project can drive thousands of visits. The key: lead with the problem, not the solution. "Show HN: I built X" is weaker than "Show HN: I kept forgetting to write changelogs, so I automated it."
Relevant subreddits — r/programming, r/webdev, and language-specific communities (r/rust, r/python, etc.) have large audiences who actively look for new tools. Share something useful, not just a link.
dev.to and Hashnode — Both platforms index well on Google and have active developer audiences. A post that genuinely solves a problem can generate inbound traffic for years. Write about the problem your tool solves, not the tool itself.
Direct outreach — More on this below, but targeted personal outreach to people who'd genuinely benefit is one of the highest-ROI activities for early adoption.
Discord and Slack communities — Framework-specific communities, language communities, and dev tool communities all have people actively looking for solutions to specific problems.
Pick two channels. Work them consistently. Spreading thin across five channels is less effective than doing two well.
Direct outreach done right
Direct outreach has a bad reputation because most of it is done badly.
The difference between spam and a welcome message:
Spam: "Hey, I built a tool for developers, check it out: [link]"
Welcome: "I noticed your project doesn't have a CHANGELOG — I built something that generates one from your git history automatically. Might save you 20 minutes per release."
The welcome version is specific, relevant, and makes a clear case for why this particular person would benefit. It's not a broadcast. It's a targeted observation.
For this to work at scale, you need a way to find people who match the profile. For WhatShipped, I built a script that queries the GitHub API for repos with moderate star counts, recent activity, and no CHANGELOG file — then the outreach is relevant by construction.
Content compounds. Outreach doesn't.
Cold outreach produces results proportional to effort. When you stop sending, it stops working.
Content is different. A good dev.to article that ranks for "how to write a changelog" will generate inbound traffic in two years without any additional effort from you. A good X thread that gets shared can drive hundreds of profile visits in a day.
The formula: write about the problem, not the product. Developers search for problems ("how to automate changelogs") and discover products in the process. If your content answers the problem, the product discovery is natural.
The star count trap
Stars feel meaningful. They're mostly vanity.
A repository with 800 stars and no activity in six months has fewer real users than a 60-star project that ships weekly and responds to issues within a day.
Stars measure a moment of interest. Active users, download counts, and issue volume measure real adoption. Track what matters.
The asset nobody builds early enough
An email list.
100 people who explicitly asked to hear from you when you ship something new are worth more than 1,000 GitHub stars. You own that list. It doesn't depend on an algorithm. You can reach them directly.
Put a simple opt-in in your README: "Get notified of new releases → [link]". A mailing list of 100 engaged users is a real distribution channel for every release you ship.
And when you do email them, have something worth sending. A well-formatted changelog — what's new, what's fixed, what changed — is the most credible thing you can include. If generating that changelog is the friction point, WhatShipped automates it from your git history. One free generation to try it.
The compounding loop
The projects that grow consistently tend to have the same loop running:
- Ship something real
- Communicate it clearly (changelog, release post)
- Share it where the audience is
- Respond to the people who show up
- Repeat
None of these steps is complicated. The compounding comes from doing all of them consistently, not from any single one being exceptional.
Start with the next release.
Top comments (0)