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

Many an open source project is created to scratch an individual developer’s itch. But when other people contribute to—and depend on—a project, it stops being just about the original creator or creators’ own needs. As some projects grow, so does interest and volume of opinions. They become communities. When this happens, maintainers often find themselves having to draw-on or grow new skills, switching suddenly from simply coding to tasks like traffic control, governance, and project management. This means a maintainer must take an expanded approach to their work.

To answer your questions about how to adapt from maintaining projects to maintaining communities, The ReadME Project’s senior editor Klint Finley gathered a group of open source developers who have done just that. Let’s meet our panelists:

Chrissy LeMaire is a PowerShell developer, author, SQL Server expert, and the creator and maintainer of dbatools, the popular PowerShell module for SQL Server professionals. Originally from Louisiana, she currently works and lives in Europe.

Fred Schott is the co-creator of Astro, a static site builder that helps developers build faster websites by shipping less JavaScript. He now lives in Oakland, often writes about his journey through the tech world, and is currently trying to adopt a dog.

Jem Gillam co-maintains Graphile, a suite of powerful open source tools to help developers build the backend of web and mobile applications. Graphile’s flagship project is PostGraphile, a tool for creating well-structured and standards-compliant GraphQL APIs.

Klint: When you started your projects, did you have the community in mind from the beginning? Or were you trying to build something useful, with the community aspect coming later?

Chrissy: I didn’t start dbatools with the idea of building a community. I’d started communities before and I’d started open source projects before, but I hadn’t thought to mix them. But I did know that I wanted a team. I’m not an expert at SQL Server, so I wanted others involved to make it a fun and useful tool. The community emerged organically.

Fred: When we started Astro we were coming at it to scratch our own itch. But we’d seen communities grow, so from the get-go, we knew the importance of community. It was one of the first things we focused on once we had a minimum viable product (MVP) together. We started a Discord, started getting documentation and policies in order, and it took off from there.

Jem: My partner Benjie Gillam and I came to PostGraphile after it had already been around for a while and ended up becoming the maintainers after the previous maintainer changed jobs and moved on to other things. We’d had quite a lot of community experience before this, for example, founding a maker space in Southampton, but we didn’t realize we were building a community when we got involved in PostGraphile.

Klint: When did you realize you had a community and not just users?

Jem: I think it was when we had people reaching out wanting to sponsor the project. We started out using Gitter for chat, but we outgrew it and moved to Discord so we could add more structure to our discussions. We started doing more intentional community management, but it really felt like a community when we realized that people were serious enough about Graphile to want to put money into it to ensure its continued existence.

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.

Chrissy: dbatools generated a lot of excitement early on because it simplified incredibly tedious tasks. Within a month of starting the Slack channel, I knew we had a community. But it wasn’t until six months later that I knew we’d built a community that would last for years. At the six-month mark, we all got together and used a kanban board to standardize our coding techniques. It brought so many of us together and resulted in a higher-quality project we could all really feel proud about.

Fred: I don’t know what point it was for us. Just seeing the first couple of people find their way to our Discord was a huge moment. It was super early days, but they were excited. They saw the vision we were building towards. There was an immediate feeling that we’d found our people, so to speak: people who cared as much about what we were doing as we did.

Klint: Beyond organic growth, can you share any proactive steps you’ve taken to grow your community and attract more participants?

Fred: We weren’t very proactive at first. We didn’t want to grow too fast. We already had an audience from projects we’d done before, so we were lucky enough not to have to go out of our way to promote Astro. But, one thing we’ve done recently is that we’ve changed our expectations for core maintainers. 

Our documentation used to assume that core contributors were technical contributors, so we had some technical requirements. But people contribute in lots of different ways, from documentation to community support, so we’ve updated our expectations accordingly. 

Jem: We started off using f5bot to keep an eye on our name cropping up on different social media channels, which let us meet our users where they were already discussing us. Once we had a Discord server we started pointing people to that. The outreach flows rather naturally from the way we do things. Rather than writing out a strategy, it’s about how we want to interact with the developer community and doing things the way we’d want to see them done.

Chrissy: Yes, exactly. I thought about the things I personally value in a community. I go to conferences and let people know that we’re looking for contributors and that we’ll walk anyone through submitting their first pull request. I entice people by letting them know they can safely cut their teeth with us, then go on to contribute to things like Microsoft documentation. I talk about the benefits of open source and adding the skill set that comes with it to their resume. In the early days, I even set up a company on LinkedIn and let people know they were welcome to add themselves if they had contributed something major. I liked the LinkedIn setup because I could also recommend major contributors who were looking for jobs, and I’ve been told it helped a couple of people find their next opportunity.

Klint: Supporting the needs of a group of people is always going have its challenges. How do you make your community welcoming in terms of skill level, diversity and inclusion, and all-around friendliness?

Chrissy: When I started out in open source, it wasn’t always a nice place. Exclusion was pretty much the standard, but I always thought it was cooler to be welcoming to others. So inclusivity was a goal from the very beginning. As a gay woman in tech, inclusion has always been of particular importance to me. As our community has grown, kindness and inclusion has been emphasized while we’ve managed to keep bad behavior firmly kept at bay.

I also wanted people of all skill levels to feel welcomed within our project. dbatools is a command-line tool and I do recognize that the command line can be intimidating. So I try to address that by hopping on Twitch and showing people that I also use GUI tools, and that even as a Microsoft Most Valuable Professional and GitHub Star, I still struggle or make mistakes. I show people that it’s OK not to know everything and that they don’t have to use the most intimidating or complicated tools to be effective.

Jem: We’ve had a code of conduct since the beginning. But really our main approach is leading by example. We try to make everyone welcome regardless of who they are and their experience. We found what works is to be non-judgmental. It’s very easy for people to think they have a silly question, but we encourage people to ask them anyway because if one person has a particular question other people probably do as well. So we try to answer in a kind way or point to any documentation they might need. We’re getting more questions about GraphQL in general, rather than our project, so we’ve become quite adept at correcting misconceptions and pointing them in the right direction. Because we set the example, our users tend to also act that way, they understand the tone of our community.

Fred: Some things are table stakes now. You’d be surprised at how early contributor guidelines come in handy. You need to answer questions like “How do I clone the repo?” or “How do I get the packages installed?” Maintainers have been in their codebases for so long that they forget how hard it can be for new people to get started. A code of conduct is a must have. You’d be surprised how often it helps if you run into a sticky situation or a gray area.

Klint: I’ve seen maintainers say their projects are too small for a Code of Conduct. Is there a point where it’s too early?

Fred: Not really. If you care about outside contributions at all, you should have a Code of Conduct, regardless of size. It’s more about intent: If your goal is to build a community or encourage outside contributors on your project, then you’ll want a Code of Conduct. If your repo is meant to be a solo project, then I think you’re fine to skip it.

Klint: If you could give just one piece of advice for maintaining a healthy and welcoming community, what would it be?

Chrissy: Diversity and inclusion is not about what you say, it’s about what you do. It’s easy to say “everyone is welcome here,” but it’s hard to actually make people feel welcome. It’s hard to enforce boundaries. It’s hard to call out bad behavior without allowing it to become a pile-on. You have to take responsibility for doing what’s right, even when it’s hard.

Fred: I think the main thing I would say is to be accommodating to everyone. You don’t want to have too many bars for someone to clear in order to get involved, especially in the early days. If they hit a snag, help accommodate them. If you’re dismissive of the problems people face, they’ll leave. First impressions are important.

Jem: I think what has worked for us is that our own replies set the tone of the engagement. If there’s something that has come up that’s really negative, we tend to give it time–we don’t react in the moment. Sometimes someone might not speak English well so their tone doesn’t come across correctly, so someone might sound less kind than they intend. We strive to assume good intent, but from time to time we have to message someone to ask them to be kinder—or to use a more appropriate Discord handle. Leading by example has so far managed to give our community a friendly, non-judgmental atmosphere.

The ReadME Project is a GitHub platform dedicated to highlighting the best from the open source software community—the people and tech behind projects you use every day. Sign up for a monthly newsletter to receive new stories, best practices and opinions developed for The ReadME Project, as well as great listens and reads from around the community.