Blog · 2026-04-25

How to launch an open-source project in 2026

The old launch loop was simple: post to Hacker News, hope for the front page, scrape some traffic off Product Hunt, and move on. In 2026 that loop still works on the rare day it works, but the majority of open-source projects launched this way disappear inside a week. The audience is bigger now, the surfaces are noisier, and the algorithms reward different things than they did five years ago.

This is the launch playbook we recommend to maintainers shipping their first project, or to a seasoned maintainer launching version 1.0 of something new. It is not a checklist of every venue. It is a sequenced plan that prioritizes durable visibility over the launch-day spike.

Step 1: Decide if you actually need a launch

If your project is a niche tool with a clear technical audience, a launch may not be the move at all. The single highest-leverage thing you can do is write a great README, add a license, and make sure your package.json or equivalent is filled out. Then post it where the audience already lives: a relevant subreddit, the Discord of the framework you built on, or a thread on the issue tracker of the tool you are extending. Don’t buy ads. Don’t shotgun every launch board. Match the venue to the audience.

If you do want a broader launch, the rest of this post is for you.

Step 2: Pre-launch (weeks -2 to 0)

The week before you launch is when the wins are made. Three things matter:

The repo itself. README at the top should answer in one paragraph: what it does, who it’s for, why someone should care. Add a screenshot or a short asciinema recording. List a license. Pin the right GitHub topics so it is discoverable from topic pages.
A landing page or live demo. A bare GitHub repo without a hosted demo loses to a project that has one. The demo doesn’t need to be polished. It needs to exist.
A short pitch. Two sentences. Practice writing it five different ways. You will reuse it on every launch surface.

Step 3: Launch day, in this order

The order matters because each surface drives different traffic with different expectations:

RepoRanker first. List your repo on{" "} RepoRanker the morning of launch. Listings go live immediately. The leaderboard is durable: your repo stays visible for weeks, not hours, and the long-form peer reviews accumulate over time. This becomes the page you link to from everywhere else.
Show HN. If your project is interesting to dev/founder Hacker News, post a clear, non-marketing title and stay in the comments for the first 24 hours. One shot. Don’t repeat.
Twitter / X and Bluesky. Your two-sentence pitch + a 30-second demo video. Tag people whose work yours builds on. They will retweet.
Relevant subreddits. r/programming if it is broadly developer-relevant. Otherwise pick the language or domain subreddit. Read the rules. Many ban self-promotion.
Newsletters. If you have time, email 5 newsletters that cover your space with a one-paragraph pitch and a link to your RepoRanker listing. The hit rate is low. The cost is zero.
Product Hunt. Optional, and only if your project has a polished product surface (web app, hosted SaaS, browser extension). Skip it for libraries and CLI tools. The PH audience is mostly consumer/maker; library launches die there.

Step 4: After launch (weeks 1-4)

The mistake most maintainers make is going dark after launch day. The compounding wins live in weeks 1-4:

Write reviews of other projects on RepoRanker. Each released review earns you credits, which buy boosts on your own repo. The system is built so contribution drives visibility.
Pick up reviewer feedback. The reviews left on your RepoRanker page are substantive (800+ characters). Read them. Cite the good ones in your changelog. Address the critical ones in your roadmap.
Post a "what we learned" follow-up two weeks in. Hacker News loves a "I shipped and here is what happened" post almost as much as it loves the launch itself. Twitter loves it more.
Aim for one PR from a stranger. The first external PR is the moment your project becomes a community project. Lower the bar: tag good-first-issue, write a tight contributing guide, respond to issues within a day.

What we recommend skipping

Paid ads. The conversion math doesn’t work for free OSS unless you are also running a SaaS on top of the library.
Dev influencer outreach with a pitch deck. Most won’t reply. The ones who will reply will reply to a one-paragraph email about a project they would have noticed anyway.
Cross-posting the same announcement to 30 subreddits. Mods will ban you, Reddit will shadowban you, and your launch will end before it started.

The compounding surface

The goal of this whole sequence is to build a launch where week 4 traffic is higher than week 1. That happens when your project keeps showing up: on a leaderboard that doesn’t reset every day, in reviews that don’t fade after the launch window, on topic pages that index by tag, in newsletters that include your project six weeks after you forgot you sent the pitch.

RepoRanker is built for that compounding surface. Submit your repo for free{" "} and the rest of this playbook gets easier.

← All posts