If you were ever inclined to doubt how strong an OSS community can be, look at one that feels betrayed. 

A major example has been playing out since March 2024: Redis adopted a dual-source-available license, and much of the Redis community revolted. Some lambasted them on social media, and others forked an open-source alternative that many have pledged to use instead. The same story played out with MongoDB and Elastic when the former invented the SSPL and the latter adopted it.

More organizations than ever are making open-source work, but there seem to be endless headlines about organizations running afoul of their communities in big and small ways. 

Now is a great time to step back from the controversies and ask a question that underlies these issues: What does it really take to start, build, and maintain a strong open-source community? All the possibilities – both the good ones and the bad ones – depend on this first step. 

Measure community strength in two dimensions

I worked at Hashicorp for over three years, and before that, I regularly contributed to Vagrant (which is where I became friends with Hashicorp founder Mitchell Hashimoto). 

Over time, before and after mine, both communities scaled and transformed along the way. I was there while those communities changed and watched many more in other ways. Everyone cared about the “strength” of the community, but few, if any, had a clear way of defining strength.

“Strength” is ultimately a subjective term, and not all strong communities will be strong in the same way, especially over time. Growing projects face the choice (whether they realize it or not) to focus on depth or breadth. As projects widen and scale, community strength can change, and projects can become healthy or unhealthy.

Breadth

In a breadth-focused community, maintainers open the community to many contributors and to many types of contributions. Maintainers have a lower bar for who can join but often need more governance procedures to scale sustainably.

Kubernetes is a perfect example. Even before it became a CNCF project, Kubernetes had many external contributors from many different companies. Other Hashi products, such as Envoy or Istio, are also good examples of breadth-based communities.

Sometimes, these communities start small, grow, and then subdivide. Kubernetes, for example, has a range of special interest groups, allowing an otherwise diffuse community to specialize and for contributors to bring some level of focus to their work. If these broad communities didn’t subdivide at all, you’d likely have most contributors running around like chickens with their heads cut off – resulting in little “community” to speak of. 

With a breadth-focused community, going an entire month without having contributions from new people could mean the project is no longer healthy or that people don't feel welcome. At this point, projects of this scale are also running meetups, employing regional captains, and events, providing many more ways to think about and evaluate community health. 

Depth

In a depth-focused community, maintainers keep the community somewhat exclusive. Maintainers keep a high bar for who’s allowed to participate in the community.

Linux is the clear example here. Linux's culture infamously prizes “hardcore” programmers and sets a high bar for coding talent. Just look at Steven Rostedt, a software engineer at Google, who tried to contribute to Linux and faced, like many contributors before him, criticism from Linus: “You copied that function without understanding why it does what it does, and as a result your code IS GARBAGE.”

Unlike in a breadth-focused community, where mere days without a contribution could be a red flag, a depth-based community seeing little to no increase in the number of contributions month over month is likely not a problem. The community is relatively small, by definition, so the quality of contributions and community engagement matter more.

Community strength depends on project sustainability 

Open-source projects are not sustainable without communities. The first reason is obvious: No users means no usage. 

The other reasons are less obvious: Without financial support, the amount of hours maintainers can spend on the project is limited, and without advocacy from community members, the community can’t grow. And perhaps most importantly, most open source maintainers are not in it for the money. They build these projects because they’re excited by the technology and passionate about the community; if the community part of the equation isn’t there, these people will eventually disappear.

Leverage your community by turning them into advocates and ambassadors

As a maintainer, one of the best things you can do is to give your community opportunities to spread the word about the project. The further you lower the floor on contributing in this way, the more people will participate without you even having to ask.

Part of the work here, and this might be difficult for some maintainers, is embracing the need to brand and market yourself a little. You don’t need to “go corporate” per se, but if you want to help your community grow, small details can go a long way. For example, prepare and offer:

• Pre-made slide templates that include your brand, logo, and contact information for contributors looking to make presentations based on work involving your project.
• Provide visual assets, such as diagrams, charts, and videos, to help contributors explain their work and your project. 
• For the most determined contributors, you can also provide messaging templates and guides to help them spread the core message of the project. This is less about getting them to stick to a script and more about saving them from having to invent messaging on their own. 

There’s a feedback loop here—if contributors consistently help you on this level, then you should reward them. Give back by giving contributors free tickets to your annual conference (if you have one) or giving them access to enterprise-level Slack channels.

Of course, not all of your contributors and fans will be so proactive – but they can still help. Give your contributors and fans merch to help them spread the word with little to no effort. Stickers, in my experience, offer the best ROI. By spending just a couple hundred dollars, you can generate thousands of marketing impressions as people see your brand adorned on laptops, water bottles, and conference badges. 

At HashiCorp, for example, our stickers were such a hot commodity that people treated them like collectible Pokemon cards. 

Monetize your community by selling to them and their companies

People participating in a strong community are also often willing to pay for the product they’re contributing to. That said, maintainers need to introduce monetization carefully and transparently.

In open source, monetization lends itself to a bottom-up approach instead of a top-down sales approach. Typically, especially if you provide a SaaS option, this will involve offering a free tier that gradually ramps up to charging more per month or year for users to access more features. 

More often than not, the driving goal isn’t to squeeze your way to profitability dollar-by-dollar but to get developers involved enough in the project that they’re willing to advocate for enterprise-level licenses. You can also pursue sponsorships from big companies to achieve a similar effect. 

No matter your approach to monetization, communicate your choice transparently and as early as possible. Developers tend not to be upset about sheer monetization but about feeling like their contributions have been taken from them and paywalled (see Redis). 

Identify churn and burnout risks

Monetization can help a project become sustainable, and community engagement can make a project more popular, but if key maintainers burn out or churn along the way, formerly strong communities can falter. 

Burnout, especially, is a huge topic amongst open-source maintainers. But the risk of burnout isn’t the same across projects. To prevent burnout, as well as churn, you first need to identify which is more likely and then work to safeguard the project. 

Nights-and-weekends open source

In what I’m calling “nights-and-weekends open source,” there’s a low risk for churn but a high risk for burnout.

Churn, when maintainers leave the project for another, is relatively unlikely because the maintainers tend to be hobbyists who are passionate about what they’ve made. Of course, passions change, and the demands of life change, but because the churn is unlikely to be under pressure (like in burnout), maintainers can prepare for it. 

Burnout, however, is much more likely because these maintainers typically have full-time jobs and can burn through many nights and weekends if they don’t set boundaries. Here, the strength of a community can be a danger if maintainers worry about disappointing contributors. 

The maintainers of nights-and-weekends projects need to learn how to say no to, for example, feature requests that would create more work than they’re worth. They also need to learn how to say no early and firmly. 

Company-sponsored open source

Company-sponsored open source has a low risk for burnout but a high risk for churn.

Burnout is unlikely because maintainers tend to be employed, and their contracts or roles set limits on their work hours. With the company’s backing, it’s also easier to set boundaries. 

Churn, however, is much more likely because companies, especially larger ones, tend to think of employees as fungible resources that they can move around as necessary. A company can suddenly replace a great maintainer with a worse one, it can move a great maintainer to a different project while an open role maintaining the project sits vacant, or important maintainers can leave for greener pastures (e.g. Dan Abramov recently leaving Meta). 

These maintainers, and their employers especially, need to prioritize the health of the community. There’s a financial bottom line perspective that should make sense to corporations here: If you’ve built a strong project on a strong community, then that community needs at least some level of tending to keep going. Otherwise, the investments already made will flame out. 

Indie developer open-source

Indie developer open source is an emergent category that seems, at least so far, resistant to churn or burnout. 

Typically, the developers maintaining these projects have already had a successful career and have earned a nest egg they can live on. Their projects become true hobbies.

Burnout is unlikely because there’s little pressure to take on too much work, and churn is unlikely because they have full control over the project. Both are still possibilities, of course, but the maintainer likely has the resources to prevent either.

This type of project sounds ideal, but the pipeline isn’t. There just aren’t many indie developers around to do this kind of work and run these kinds of projects. We should recognize and celebrate them when we can, but there isn’t a replicable model here to ensure burnout and churn don’t happen in other projects. 

Trace the origins of disagreements to resolve conflicts before they begin

The trick to making communities peaceful is that just focusing on getting everyone to be nice rarely works. 

As a maintainer, you have to work from the assumption that tension, conflict, and even arguments will happen – it’s just inevitable when you get enough people together in the same space. To keep things moving in a mostly peaceful direction, focus on the origins of any given conflict by figuring out why people are contributing in the first place. 

Newbie contributors can lack process knowledge

When I hear people talk about conflict in open source, I often see them misdiagnose the issue as originating from newbies. 

Certainly, this is possible. Sometimes, new contributors don’t know the culture and roll in with pre-made expectations anyway. More often, though, I see newbie contributors who make up for their lack of knowledge with humility and curiosity. If anything, it’s relatively easy to welcome newcomers.

Conflict as a result of newbies is more of a process problem. If your project picks up some attention, for example, an influx of newcomers could cause conflict just by overwhelming the project. The solution here is to set up some basic systems, such as good first issues, discussion boards, and Discord servers, to point people in the right direction.

Self-motivated contributors can be demanding

More often than not, I tend to see conflict emerging from the knowledgeable, self-motivated contributors who feel entitled to work from the maintainers. 

In these cases, the contributors tend to be self-motivated developers who’ve encountered a problem in the project they’d like to fix. Because they’re knowledgeable, these contributors can often be adamant that the right solution is to make their contribution upstream. 

These contributors are often the most resistant to “no” because they perceive this contribution as the solution to all their problems. Sometimes, the tensions can just be the result of priorities, too; if they’ve invested time in the project, they might expect changes they submit to happen immediately despite a maintainer’s competing priorities. 

In my experience, this situation is the one most likely to result in conflict and lots of back and forth, including arguments over principles and what is and is not the right thing to do. Boundaries are important to maintain, but codes of conduct can help, too. 

Intra-community conflict can be nuanced

The worst conflicts tend to result from intra-community tensions. 

Sometimes, this is because a long-standing contributor has unearned entitlement that they wield against others; other times, people are belligerent or stubborn, chilling the community; and other times, the culture itself can feel cold because people don’t know how to communicate well over text. 

This is a hard problem to unwind once it’s become the norm, so it’s better to prevent it. One of the best ways to prevent this kind of culture from settling in is to set up a code of conduct and regularly reference it. 

You don’t need to reinvent the wheel here because a code of conduct is more effective for displacing conflict than controlling how people act. Much of the time, conduct infractions are just people making mistakes. Contributors sometimes get emotionally attached to the code, and their passion can lead them to personal attacks. A code of conduct gives you a way to remind them of the behavior you want without making them feel attacked. 

That said, a code of conduct isn’t everything. They’re only effective when you’re prepared to distinguish between mistakes and bad actors. True bad actors will ignore a code of conduct just like a criminal will break a lock. These people need to be shown the door. 

In OSS, communication is everything

We’re in the golden age of OSS. We’ve proven that these organizations and businesses can be sustainable and profitable, and contributors and customers can be happy and engaged. Maintainers can look at examples and models of every kind of project at every size and scale. 

But when it comes to community-based controversies, a simple principle holds true: Communication is everything. People are rarely upset about a specific license; they’re upset about the transition from one license to another, especially when that transition is done without involving the community. 

As Vicki Boykis, a machine learning engineer at Mozilla.ai, wrote regarding Redis, “The problem is not only that the license changed suddenly, without warning, it’s the messaging behind the change, and the message is, even though there is extremely active community development, Redis is no longer in and of the community.”

For maintainers, there are two lessons:

• There’s nothing wrong with choosing a source available license, but you should do it earlier rather than later and set expectations as soon as you can.
• Empathize with your users and contributors. People stake their careers on certain products and projects, so messaging around changes has to be careful and nuanced.

Throughout, maintain open channels of communication. The more transparent you are, the stronger your community will get and the better positioned you’ll be to evolve.