Getting the Word Out Without Neglecting the Code

You've finally made your open source project public. The hard part, you might think, is over. But for many developers, the real challenge has just begun: telling people it exists.

Most maintainers would rather ship features than write announcements. But unless your project catches on by sheer luck, building awareness takes deliberate effort—especially in the early days. Experienced maintainers who have been through this offer a few practical habits that make promotion less painful and more effective.

Own the Promotion

The first step is simply getting comfortable with talking about your work. Post to social media, and submit to Hacker News, Reddit, Product Hunt, and similar platforms. Watch for people describing the problem your project solves, and point them to it. Reach out to podcasts, YouTube channels, and conference organizers. Offer to speak at meetups.

Continue this as the project evolves. People do want to hear about useful tools, provided you're offering genuine help rather than spamming. Self-promotion can feel awkward, but it's necessary. As Sidecar maintainer Aaron Francis put it in a Q&A with GitHub: "You shouldn't feel icky about it. You put a lot of time into making something helpful."

Lead with the Problem, Not the Tech

When you do promote, resist the urge to dive into technical details. A common mistake, says Chakra UI maintainer Segun Adebayo, is using too much technical terminology. Even though your audience skews technical, buzzwords can obscure the actual value of what you built.

Tasha Drew, co-chair of Kubernetes' Working Group for Multi-tenancy, makes the same point. Your project might rely on clever underlying principles, but what people need to know is why they should care. "What's the message you want people to take away from your webpage or your README?" she asks. "It's probably not related to the theory behind the code."

That core message should appear consistently across your README, social profiles, blog posts, and tutorials.

Documentation Beyond the Basics

Catching someone's attention only gets you so far. To turn that interest into usage and contributions, you need clear, current documentation. "Write as much as you can stand to write," Francis advises. The effort pays off in more ways than one: if a feature is hard to document, that's often a sign it's too complicated and should be simplified.

Go beyond API references. Include quick starts, tutorials, and screencasts. "Video is really helpful for a lot of people," Adebayo notes. "People learn in different ways so it's important to provide different types of content."

Respond Promptly to Engagement

No matter how thorough your docs are, questions will come—and, if you're lucky, pull requests. Being responsive matters most when your project is young. "Time is finite, we only get one life, so value those people who are willing to spend some of their precious resources on you," Francis says. That includes anyone pointing out problems or making suggestions on social media, not just those submitting code.

You don't need to be available around the clock, but issues and comments shouldn't sit unanswered for long. Prompt replies signal that the project is active and that you value input. "It might be intimidating at first to interact with people you don't know, but you have to do it if you want to grow," Adebayo says. "This is a sure way to meet new people and make new friends that might be helpful to you in the future."

Make Onboarding Easy

Documentation should cover not just usage but contribution. Create CONTRIBUTING.md and CODE_OF_CONDUCT.md files that outline your guidelines and expectations. These files signal that you're open to collaboration and have thought through how it should work. A list of specific tasks you would and wouldn't welcome help with is especially useful.

Keep in mind that non-code contributions—docs, support, design—are essential to any healthy project. You can't assume contributors have deep technical knowledge. "You want to make your language and project easy to understand so that people of various technical skill levels will be interested," Drew says.

Finally, use the "Help wanted" and "Good first issue" labels. They help people actively seeking ways to contribute find your project and get started.