Where to Post Open Source Projects, and What Each Costs

A community that forbids self-promotion and fits your project perfectly is not a dead end. It is a different instruction: participate, do not promote.

Start from where you already are

Most advice on where to post open source projects starts from the project: read the README, infer the audience, go find them. That gets the order backwards. You almost certainly already have a room where people know your handle, where you've answered three questions about edge cases in the last month, where a post from you would read as an update rather than an ad. That room rarely shows up in a list generated from your manifest and your tags, because it isn't defined by the technology. It's defined by you having shown up there repeatedly and not been annoying.

If you have a Discord you help out in, a mailing list you reply on, a forum thread you've commented on for a year, start there. Not because it's the biggest audience, but because it's the only one where your post carries a track record instead of arriving cold. Everywhere else, you're a stranger asking for attention. There, you're a known quantity asking for five minutes of it.

Fit and permission are separate judgements

Three questions decide whether a venue is worth your time: are your users there, does the venue permit this kind of post, and what's the local form (a text post, a show-and-tell thread, a comment on an existing discussion). They're set out in our guide to promoting an open source project. What they don't say loudly enough is that fit and permission are not the same axis, and treating them as one leads to bad decisions in both directions.

A venue can be a perfect fit and still forbid what you want to do. A community built entirely around your problem domain, full of exactly the people who'd use your tool, with a standing rule against self-promotion. The instinct is to treat that as a locked door and move on. It isn't. The right move is to participate without promoting: answer questions, fix a bug someone mentions, be visibly useful under your own name for a while. Eventually someone asks what you use, or you get invited to post because a moderator has seen you be useful first. That's not a failure state. It's a slower, more reliable one than a cold post anywhere else.

The reverse also happens. A venue permits anything, loves self-promotion, upvotes everything with a GitHub link. That's not automatically a fit. If the audience doesn't overlap with your users, permission buys you a number that doesn't convert into anything, and a format (over-eager self-promotion) that gets noticed and discounted the second time you try it somewhere that matters.

What a removed post tells you, and what one upvote doesn't

Two things that look similar are not the same event. A post that a moderator removes or flags is information about the room: it has told you, specifically, that this format or this framing does not belong there. Don't repost a near-identical version somewhere that already flagged the first. That's not persistence, it reads as not having listened.

A post that gets one upvote and no comments is a much weaker signal. At the volume most open source launches run at, you don't have enough data to distinguish "nobody cares" from "posted on a Tuesday evening to a room that's busiest on weekend mornings" from "the headline buried the one interesting detail." Treating a quiet post the same way you'd treat a removed one, as a verdict on the venue, throws away places that might work with a different framing or a better time of day.

If you want an actual answer about which venue did anything, instrument it rather than guess from feel. Tag each link you post with a campaign parameter specific to that venue, one value per venue that you never rename or reuse, and look at the arrivals your analytics records under each tag. Expect rare, dated events rather than a clean rate, especially early on: a handful of visits on the day you posted, then nothing. Don't read star counts as the answer; a star costs a reader nothing, nothing ties it to the post that prompted it, and it tells you less than a single issue filed by someone who read the docs first.

The same logic gives you a short list of places to avoid, and the reason matters more than the list:

• Rooms with a standing no-self-promotion rule where you have no history of participating. You'll be removed, and you'll have burned the only shot you get there.
• Aggregators that reward headline tricks over substance, if your project has no interest in playing that game continuously. One post there doesn't build anything, it just exposes you to an audience with no memory of you tomorrow.
• Any venue where a near-identical post from you has already been flagged. Posting again, reworded, is the fastest way to get a reputation rather than a result.

The README is the first venue, every time

Whatever venue you choose, the link lands in the same place: your README, which has about ten seconds to do its job. A moderator approving a post, a stranger clicking through from a thread, a colleague following a recommendation, all of them hit the same page first, and none of them read your pitch again once they're there. If the README doesn't answer what the project does and why it's worth ten more seconds within the first screen, the venue did its job and your project still didn't convert.

That ordering has a practical consequence: fix the README before you expand the list of places you post it. Every additional venue sends more people to the same page. A README that loses people at the first fold loses the same proportion of people whether the link came from a community you've earned trust in or one you've never posted in before. Posting in more places before that's true just means more people see the same failure faster.