How to promote your open source project on X (without begging for stars)
By Naod Tadele · · 5 min read
You built something useful, pushed it to GitHub, and posted the link. A few likes, then silence.
That is the normal first result. Open source projects don't spread because they exist. They spread because people see them solve a problem, again and again, in posts that are worth reading on their own. This guide covers what to post, when, and how to make each post pull its weight.
Stop asking for stars
"Please star my repo" posts rarely work. They ask for a favor and give nothing back. Readers scroll past.
A star is a side effect. People star a project when they think "I will need this later." Your job is to create that moment. Show the problem, show the fix, and make it easy to try.
Lead with the problem, not the project
Most launch posts start with the name. Nobody knows the name yet, so it means nothing. Start with the pain your reader already feels.
Weak:
Introducing Nightshift, an open source CLI written in Go.
Better:
Getting paged at 3am and reading 40 alerts to find the one that matters is the worst part of on-call. Nightshift is an open source CLI that groups related alerts and writes a short incident summary. Runs locally, no account.
The second version tells the right reader "this is for you" in one line. The project name comes after the reason to care.
Show it working
A developer decides in seconds whether a tool is worth a look. Help them decide.
- A terminal screenshot or short clip of the tool doing its main job.
- Before and after. The messy input next to the clean output.
- The install command, so trying it costs almost nothing.
Keep the visual focused on one thing. A wall of output is as hard to read on X as it is in a terminal.
Turn every release into a post
Releases are the easiest content an open source project has. Each one is a reason to post, and each post reminds people the project is alive. Active projects get adopted. Stale ones get avoided.
A simple shape for a release post:
- What changed, in one plain sentence.
- Who it helps and why.
- A screenshot or snippet.
- A link to the release notes.
Nightshift v1.4 is out. Alerts from the same service within five minutes now merge into one incident. Fewer pages, same signal. Thanks to the contributor who opened the issue and wrote half the fix.
Notice the last line. Thanking contributors in public is kind, and it shows newcomers that their work will be seen.
Post the story, not just the changelog
Between releases, the most interesting posts are about decisions:
- Why you picked one approach over another.
- A bug that took a day to find, and what caused it.
- An issue from a user that changed your roadmap.
- Something you removed, and why.
These posts reach people who would never read a changelog. They also show your judgment, which is what makes someone trust a dependency.
Removed the YAML config from Nightshift today. Most users set three options and the file confused everyone. Flags only now, with sensible defaults.
Make contributing feel possible
Many people want to contribute to open source and don't know where to start. Help them:
- Label a few small issues for newcomers and post about them.
- Explain the codebase in a short thread: where things live and how a request flows.
- Celebrate first contributions by name, with their permission.
Looking for a first open source PR? Nightshift has three small issues labeled good first issue. One is adding a Slack output format. Happy to review and help.
Be useful in the right conversations
When someone on X asks how to solve the problem your project solves, a helpful reply beats any announcement. Answer the question first. Mention your project only if it truly fits, and say you built it.
Replying to every vaguely related post with your link does the opposite. People notice quickly.
Keep a steady rhythm
You don't need to post every day. A release post when you ship, plus a decision or lesson post most weeks, is enough to stay visible. Consistency matters more than volume, because each post builds on the last.
Point people to the right place
Make your profile and repo do the follow-up work:
- Put the repo link in your bio or pinned post.
- Keep the README's first screen clear: what it does, a screenshot, install in one command.
- If you also have a paid version or hosted service, say so plainly. Open source and a business can coexist, and being clear builds trust.
How Loudcode helps
The hard part of promoting an open source project is remembering to post after you ship. Loudcode reads your GitHub commits, pull requests and releases and drafts posts for X in your voice, so every release can become a post without starting from a blank page. You can add screenshots of your live app to visual posts, and you review and edit every draft before anything goes out. For more on turning commits into readable posts, see how to turn GitHub commits into posts.