Marketing for maintainers: Promote your project to users and contributors

Getting your open source project noticed

Shipping code to GitHub is only the first step. If you want people to actually use your project—or contribute to it—you have to explain why they should care. That means shifting from writing code to writing about it, which can feel intimidating. Three maintainers with experience promoting their own projects shared practical advice on how to do it well.

Segun Adebayo, a GitHub Star and software engineer at Vercel, created Chakra UI, an accessibility-focused React component library. Tasha Drew leads VMware's xLabs and co-chairs Kubernetes' SIG Usability and Working Group for Multi-tenancy. Aaron Francis is a marketing engineer at Tuple and creator of Sidecar, a serverless Laravel deployment tool.

Start with a specific problem

When launching a project, the first question isn't how to market it—it's what problem it solves for a specific audience. Adebayo spent months after Chakra's launch sharing short demos and screenshots that showed what the library could do. "You need to let people know what tangible benefit your project provides, whether that's helping them work faster or saving them money or something else," he says.

Francis found that targeting a narrow use case worked better than pitching a general-purpose tool. For Sidecar, he focused on one scenario it handled especially well: using Inertia.js with Laravel's Vapor service for server-side rendering. That got the Laravel and Inertia.js communities talking. "Addressing the problems of existing communities is a powerful way to get noticed," he says.

Drew recommends thinking about whether your project is a leader or a challenger in its space. Kubernetes launched with Google's backing but still had to convince people to switch from Docker Swarm or Mesosphere. Challengers can afford to be more open to feedback and extensible—or they can pick a niche and solve it significantly better than the incumbent. "What you want is for people to have a reason to try you," she says.

Documentation is the real marketing

All three panelists emphasize that documentation matters more than any promotional campaign. "Write as much of it as you can stand to write," Francis says. Good docs lower the barrier to entry, and the process can improve the code itself—if a feature is hard to document, it's probably too complicated.

A common mistake is showcasing cleverness instead of usefulness. Drew has seen landing pages link to distributed systems papers and protocol implementation details. "That sort of information is only interesting to other distributed system builders, not to users," she says. Adebayo agrees: too much technical terminology focuses on features rather than tangible benefits. Talk about the "why" behind the library first, then what users gain, in the simplest language possible.

Written docs aren't the only format that matters. Adebayo adds that video helps reach people who learn differently. Even small investments in different content types expand who can understand your project.

Making it easy to contribute

Attracting contributors means lowering the barrier to entry at every step. Adebayo suggests clear contribution guidelines, walk-through videos, and reducing setup processes. Documenting the roadmap and known bugs—and explicitly asking for help in certain areas—also signals where people can jump in.

Drew notes that most contributors won't be experts in your core technology. A sophisticated distributed systems project won't attract many people with deep distributed systems experience right away. "Most of your contributors will be pitching in other places, where the barrier to entry is lower," she says. Making the project extensible helps too. Chef, for example, lets people contribute Cookbooks without understanding the inner workings of the core software.

Responsiveness matters most in the early days. "Be responsive, especially to the first few people who are taking a risk by investing time in your unproven project," Francis says. Thank people for pointing out problems or making suggestions, even if you don't implement them right away. Acknowledge parts of the software that are painful right now. "Kindness is key. You can't always be responsive or helpful but you can always be kind."

Adebayo encourages maintainers to get comfortable interacting with strangers, including jumping on video calls to walk someone through an issue. "You have to do it if you want to grow," he says. Making the first pull request as frictionless as possible increases the odds contributors stick around.

Developing a communication style

Consistent, honest communication is something maintainers can deliberately cultivate. Francis tries to be kind, empathetic, and confident online—even when disagreeing with someone. "In engineering circles being kind has been sacrificed at the altar of being correct, and I think it's a huge false dichotomy," he says. That matters for enterprise adoption too: large organizations won't want to deal with people who have bad public personas.

Adebayo thinks of personal branding as what people expect when you walk into a room. He chose an area of expertise—design systems, state machines, and accessibility—and freely shares helpful tools and ideas. "The biggest thing I try to do is to be open and vulnerable. I admit what I don't know," he says.

Drew, by contrast, doesn't claim a personal brand. Her communication style is upfront, consistent, and transparent—something she discovered by working with an executive coach who told her to lead with that directness rather than soften it. "People respond well to up-front feedback when they're expecting it," she says.

Speaking events build momentum slowly

Public speaking is a powerful but slow way to promote a project. Francis's first Sidecar talk was at a meetup with 80 to 100 people watching. It didn't make the project an overnight success, but four or five attendees started using it—and each of them could spread the word further. "Each event you do, or each podcast you do, makes it more likely you'll be invited to another event or interview," he says.

Drew points to Docker as a cautionary tale about "overnight success." The company sent evangelists to tech meetups worldwide for at least two years. "People underestimate the power of focused evangelism," she says. Face-to-face interaction makes people more willing to try new technologies.

Adebayo emphasizes timing and balance. Talks and podcast interviews are best after a release when the project is stable, not while it's changing rapidly. If you don't enjoy speaking, build a team of collaborators who do. "Having a team helps give you the space to take breaks," he says.