What to do when your open source project becomes a community?

From Maintainer to Community Leader

Many open source projects start as a solution to one developer's problem. But when others begin contributing to—and depending on—that project, it transforms into something larger. The original creator suddenly faces new demands: managing contributors, setting governance policies, and balancing competing opinions. The shift from writing code to managing people requires a different set of skills entirely.

Three maintainers who have navigated this transition shared their experiences: Chrissy LeMaire, creator of the PowerShell module dbatools; Fred Schott, co-creator of the static site builder Astro; and Jem Gillam, co-maintainer of the Graphile suite and its flagship project PostGraphile.

Communities Rarely Start by Design

None of the three maintainers set out to build a community. LeMaire knew she wanted a team around dbatools—she didn't consider herself a SQL Server expert and wanted collaborators to make the tool genuinely useful—but the community that formed around it was never part of the initial plan.

Schott was similarly focused on solving his own problems with Astro, though he and his co-creator understood the value of community from watching other projects grow. Once Astro had a minimum viable product, they set up a Discord server, drafted documentation and policies, and let it develop naturally.

Gillam and her partner Benjie came to PostGraphile after it had already been running for some time. The previous maintainer moved on to other work, and they stepped in. Despite prior experience building communities—including founding a maker space in Southampton—they didn't realize they were creating one until well into the process.

Recognition Comes Gradually

For Gillam, the turning point came when users began offering financial sponsorship. The project had started on Gitter but outgrew it, prompting a move to Discord where they could structure conversations more deliberately. Yet it didn't feel like a real community until people demonstrated commitment through funding.

Especially when you're first starting out, you don't know who's using your software. You only hear from people when they have problems, when they're filing issues or looking for support. So it was really validating to see how much people really cared about what we were doing.

LeMaire saw rapid enthusiasm for dbatools because it simplified tedious SQL Server tasks. Within a month of launching a Slack channel, she knew a community existed. But it took six months—when contributors gathered to standardize coding practices on a kanban board—for her to realize it would last. The collaborative effort improved code quality and forged stronger bonds among contributors.

For Schott, the first few people finding their way to the Astro Discord felt significant, even in the earliest days. Their excitement validated the project's vision and signaled that they had found people who cared as deeply about the work as the core team did.

Proactive Growth Strategies Emerge Later

Astro didn't aggressively recruit early on. Its creators already had an audience from previous projects and deliberately avoided expanding too quickly. Recently, however, they adjusted their expectations for core contributors: documentation had assumed technical contribution only, but people support projects in many ways—documentation, community support, and more—so they updated their guidelines accordingly.

Graphile took a monitoring-first approach, using f5bot to track mentions across social media channels and engage users where they were already discussing the project. As Schwitt said, rather than writing a formal strategy, it came down to interacting with the developer community the way they'd want to be interacted with.

LeMaire focused on lowering the barrier to entry and communicating tangible benefits. She attends conferences to recruit contributors directly and offers hands-on guidance through a first pull request. She framed open source participation as a stepping stone to larger opportunities, like contributing to Microsoft documentation. Early on, she even created a LinkedIn company page and invited major contributors to list themselves—which also let her recommend those contributors for job opportunities.

Fostering an Inclusive Atmosphere

LeMaire's experience in open source wasn't always positive. As a gay woman in tech, she saw exclusion as the norm and made inclusivity a core goal for dbatools from day one. Kindness is enforced, and bad behavior is kept from taking root. She also works to ease newcomers' intimidation around command-line tools, appearing on Twitch to show that even a Microsoft Most Valuable Professional makes mistakes and uses GUI tools regularly.

Graphile has maintained a code of conduct since its founding, but Gillam credits leading by example as the more effective tool. Being non-judgmental and encouraging questions helps people feel comfortable, since one person's "silly" question is often shared by many. As questions about GraphQL in general grew, the community became skilled at correcting misconceptions gently. Users mirror the tone the maintainers model.

Schott stresses fundamentals that are easy to overlook. Detailed contributor guidelines answer basic questions like how to clone a repository or install packages—knowledge that longtime maintainers may have forgotten is not obvious to newcomers. Codes of conduct are equally essential, even for small projects.

You Can't Start Too Early on Conduct Policies

To the maintainers who say their projects are too small for a code of conduct, Schott's answer is direct: not really. If a project is meant to be solo, skipping it is fine. But if outside contributions matter, a code of conduct signals intent and provides structure for handling gray areas before problems arise.

One Key Piece of Advice

Each maintainer distilled their experience to a single principle:

• Chrissy LeMaire: Diversity and inclusion demands action. Declaring everyone is welcome is easy; making people actually feel welcome is not. That means enforcing boundaries and calling out bad behavior without letting it escalate into pile-ons.
• Fred Schott: Meet contributors where they are. Too many barriers to participation will drive people away, especially early on. Helping newcomers over their first snags matters—first impressions can decide whether someone becomes a contributor or disappears.
• Jem Gillam: The responses you give set the community's tone. Negative situations warrant patience, not knee-jerk reactions. Language barriers can make well-intentioned messages sound harsh, so assuming good intent matters—though sometimes a direct message asking for a kinder tone is necessary.