How To Build An Open Source Community: Sustaining Changes and Growth Plans

Perhaps one of the most memorable milestones in the scientific community this year was the release of the first image of a black hole. Like most technological advancements these days, this was made possible in no small part by open source software.

It took scientists years and a network of telescopes to process and produce the image of the supermassive black hole at the center of M87, a galaxy 54 million light-years away.

Over 21,485 direct contributors worked on the software that made the image possible, but over 74,000 community contributors worked on the top 1,000 open source projects used in total.

As an open source contributor, an open source maintainer, and the product lead for GitHub’s Community and Safety team, I’m always thinking about ways to better support the open source community. With the new year upon us, I decided to write down my resolutions for how I can continue to be a better member of the community—and thought to share in case they help influence the broader community as well.

#1: I won’t be a bus of one. I’ll make sure to pick up some supportive community members along the way...

In software development, there’s the concept of the “bus factor” (or the “lottery factor” as I like to call it). How many developers need to win the lottery tomorrow (or tragically get hit by a bus) for the project to fail? If it’s just you, that number is one.

As a project grows and matures, you want that number to be as high as possible.

Humans get sick or take vacations or get locked out of their account and a project shouldn’t grind to a halt as a result. It can be hard to know when a project goes from “my” project to a community project, but as early as practical, move the project to a dedicated organization and empower contributors you trust to take on additional responsibility.

Beyond better project longevity, most of GitHub’s community management tools are built with organization-owned repositories in mind, to encourage shared responsibility, so you’ll find more and more robust community management tools are suddenly available to your project.

#2: I will be a gracious dinner party host to the open source community.

Think of an open source project like the world’s most distributed dinner party. Just as you would at a dinner party, as the host, you want to welcome guests as they arrive, take their coat, offer them refreshments, and introduce them to other party goers to ensure they have a good time.

Open source is no different, except instead of taking coats or offering hour d'oeuvres, you’re offering documentation and your responsiveness. And just as a dinner party guest should take care to arrive on time or might consider bringing a small gift to thank the host, as open source guests, contributors should likewise be empathetic, supportive, and understanding of open source maintainers and what is often their volunteered time.

Being an open source maintainer is often closer to being a manager than it is to being an engineer. You often start a project to solve a specific technical problem, but as the community grows, in order to scale your own efforts and to have the biggest impact on your project, your role often shifts to solving the human and the workflow side of open source, rather than the technical. 

Specifically, community management (moderation, delegation, and organization), marketing, recruitment and evangelism, automation and tooling, and providing “white glove” support to high-profile users. The more sophisticated the project, the less likely it is that maintainers’ primary contribution is in the form of code.

#3: I will support maintainers in developing healthy, inclusive, and supportive communities.

Think about an in-person community you're part of. It could be the neighborhood or town you live in, the congregation at your place of worship, or your local bowling league. Communities are about groups of people coming together to solve a shared challenge (having a nice place to live, practicing one's beliefs, or socializing).

Each community has its leaders (elected officials, clergy, team captains) and some form of codified ideals (legal code, religious teachings, league regulations). When you move that community online, the social norms that build a sense of comradeship also follow.

Open source communities are no different from those offline communities. Just as offline communities have a neighborhood watch alliance, online communities require community moderation tools to police their members' behavior when it deviates from established norms.

As a member of the community, our role is to empower maintainers to grow healthy and welcoming communities around their open source projects.

The goal isn’t just to prevent or reduce the visibility of disruptive behavior (blocking users or hiding content), but to actively encourage inclusive behaviors, even if they don’t have previous community management expertise.

#4:  I will recognize the differences between communities—and look to support their specific needs. 

Smaller, independent projects don’t necessarily need sophisticated workflows or community management practices at the onset, and often, that premature optimization can stifle community growth. I think of project growth through a “community maturity model.”

Projects should often wait to establish formal or documented processes as they mature, and not before they need them.

If you’re prototyping a new library by yourself, you don’t need a code of conduct, mandatory forms for bug reports. If you get your first pull request, however, from an outside contributor, you may want to consider taking a critical look at your documentation, and if you’re fortunate enough to get additional contributors, beginning to formalize your contribution and review process.

That’s not necessarily true for organization-backed open source projects that can either anticipate the success of a project or have teams dedicated to establishing cross-project practices (an open source program office).

If you’re Facebook or Google and you’re starting an open source project, it may make sense to include a standardized code of conduct or contributing guidelines for all your projects on day one to start things off on the right foot and set yourself up for success as the project grows.

Whether it’s an image of a black hole or your favorite mobile app, software development is a team sport. When you import an open source library into your project, remember that you’re not just adding code.

You are adding a team of developers to your project. As we head into the new year, I hope these resolutions will help us all continue to work on being better members of the community together.