The community is the backbone of an open-source project. It establishes a framework for collaboration, innovation, growth, and sustainability. In order to for an open-source project to be a successful, it needs to develop a community.

Let’s have a look at what makes a good community, how communities are structured, and how to build them. I’ll also try to point out common pitfalls when developing communities.

Asking the Right Questions

There are pros and cons to building a community. Let’s have a look at why you should or shouldn’t invest in building a community:

Why should you build a community?

The following are good reasons to build an open-source community:

  • Attract attention to your personal self or your company

    Believe it or not, but selfish motives are a common theme in open-source. Open-source can enable you to be recognized and be seen as an industry leader. Open-source provides attention across organizations and corporate environments.

    If you run your own company, you could build a community to attract attention, then offer services around the open-source product, e.g. selling subscriptions, consulting, or proprietary products related to the open-source project.

  • Innovation and ideas

    Lively open-source communities allow for a rapid exchange of ideas. This drives innovation in open-source software. Releases can be made often and interaction with users is possible at any point in time. This can yield a very effective feedback loop which accelerates innovation.

  • Recruitment

    Companies or organizations which have a good reputation in open-source are popular amongst many developers. This can be a factor for driving people to your project. Many communities are built on top of existing communities, or relate to existing open-source communities because they share code with each other. This allows bootstrapping a community more easily by collaborating with existing communities.

  • Saving costs

    By building a community, you can share the costs for maintenance, testing, and innovation. In a perfect community you get all this from the community and you just have to invest a small part in it. Initially, building a community will be work but can very rewarding.

  • Forking

    You may have forked a project whose community is dying or controlled by an actor which does not play fair. There are many cases where that’s not a good idea but it can make sense. A good example where forking worked is the CI server Hudson which was backed by Sun. After Sun was acquired by Oracle, the community forked the project and it became Jenkins. This was a success and allowed the project to grow independently of Oracle’s interests.

  • Open-source is fun.

    Exchanging ideas, making new connections, working together towards a goal, sharing resources - all that is great fun. Being open is a modern mindset that makes solving many problems easier.

Why shouldn’t you build a community?

There a legitimate reasons why building a community might not be a good idea. Let’s have a look at some of the counter-arguments:

  • You think the community is going to build itself

    Nope. Building a community will be a lot of work. How much precisely depends on the momentum of your project (demand) and how you effectively generate it (marketing). The more people you have initially and how well they are connected to the industry or other open-source projects will make a big impact.

  • The technology is not innovative or useful to people

    It is going to be hard to build a community around software which people do not really want to use. You may ask yourself, “Who cares about my project?” If you can’t think of a handful of people who would find your software immensely useful, chances are that nobody does.

  • You want to offload the maintenance and development.

    Things will likely not turn out the way you intended. If you do not want to participate in leadership of a project, it will likely not go anywhere, or you’ll lose influence over it.

  • (Hostile) Forking

    People will not like forks unless there is a good reason for it. Consider Open Office, which was open-sourced by Sun. When Sun was acquired by Oracle, Oracle decided to not invest into Open Office anymore. This led to a fork which was called Libre Office. The fork couldn’t use the name Open Office because Oracle owns the brand Open Office. Even though Libre Office can be considered a successful fork, to this day it suffers from the popularity of the Open Office brand. Yet, there are many examples of (hostile) forks which never went anywhere.

  • You think open-source itself is a business model

    Through OSS, one can find great way to build a business, but do not expect open-source to generate money if you haven’t developed a good business idea. Nowadays, many people talk about big players like Amazon offering open-source products as a service and not contributing back to them. Although one may criticize that, please take this possibility into account when you develop your business idea.

  • You are afraid of having IP stolen.

    Generally speaking, you should be comfortable with sharing IP. Not sharing it usually leads to licensing problems, which can hinder adoption. Open-source is not a one-way street, you get something in return for your ideas, but you may have to start sharing first.

  • You are a control freak.

    Just don’t.

What about existing communities?

Do you really need to start a new community? Maybe there is already a community that would fit your needs. Think about joining one. Building a community from scratch can be much harder than joining an existing one. You can start making an impact in the project and focus on the things that matter most to you.

The 4 Pillars of a Successful Open-Source Community

For a strong open-source community you need the following ingredients:

1. Code

Why code? A community can only evolve about a meaningful piece of software. If you don’t provide value to people, nobody is going to care about your project. So think about the existing open-source software and how you will provide value to motivate others to join and participate.

Code also attracts a certain type of community. Innovativeness, ease of use, complexity, and the programming language play an important part in what kind of community evolves around a project. For example, compare a Lisp project with a Javascript project. Compare system software like a database to a web framework or a JS library. The type of code has a huge impact on the type of community that grows around a project.

You should ask yourself:

  • “Do I know the type of people that could contribute?“
  • “Is there a demand for a community around your code?”

2. People!

Code aside, of course a community is all about the people. If you look up who is part of an open-source community, you usually find this definition:

  • Users
  • Developers
  • Contributors (most of the time these are both Users and Developers)

In reality, things are much more complicated:

Take software developers as an example. They are part of the community but they are rarely employed by the project — the open-source funding dilemma. Instead, they work at companies whose corporate goals vary. As a project you need to acknowledge this.

Don’t expect that everyone can spend the same amount of time in the community, but still give everyone a chance to participate.

Do not rely on a single person to maintain a project, build in some redundancy by having a second maintainer or at least document things well. Otherwise you have a single point of failure for your project. Maintainer burnout is a very real thing, so acknowledge the work of developers and find a way to balance the work the developers have to do.

Recognize that your community can span outside the code domain. This makes your community more diverse and can significantly grow it. Consider the following roles:

  • Decision makers

    Every project has people behind the scenes which vouch for open-source projects. Knowing who that is finding a way to eventually recognize their contributions can be very valuable.

  • What about writers / bloggers / organizers / evangelists / influencers / enthusiasts?

    Make it easy for non-developers to reach out. It is the stories that lead people to using your software or joining your community.

  • Think about all the roles that you need in your community and whether all of them currently exist:

    What could be those roles? For example: Coders, architects, reviewers, leaders, organizers, supporters, helpers, questioners, explainers, moderators. Having a diverse set of roles is crucial for a functioning community.

The Critical Mass

Every community needs a group of people which takes responsibility for a project. I call that the critical mass. What does the critical mass do? They are the project managers of the project. They are self-motivated with a long-term interest. They build structures and delegate responsibility. They promote the project in the industry, they are active in the day-to-day business of the project. They help to organize offline meetings, such as meetups and conferences to foster the relationships.

What would be a good example of a things done by the critical mass?

  • Starting off the project
    • Donating the code / licensing it appropriately
    • Creating bylaws / code of conduct / contributions guidelines
  • Day to day business
    • Foster open discussions (e.g. mailing list)
    • Ensuring the project stays relevant (technology)
    • Getting rid of technical debt
    • Ensure project’s infrastructure works correctly
    • Meditating conflicts
    • Recognize contributions and recruit new community members (!)
    • Highlight achievements e.g. reaching milestones 1000 PRs, new committers, anniversaries
  • Outreach
    • Organize meetups and conferences
    • Write books or articles
    • Promote on social media
    • Being excited

How do you find a critical mass? To give you an idea, here’s a great quote by Jan Lenhardt:

I tried to be involved with every thread on the mailing list, showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with answering as well, and to my complete delight, they mimicked my style.

Quote taken from

The critical mass is the role model of the community. It all starts with a few people but it grows over time.

3. Processes

Every community needs clearly defined processes for:

  • Workflows
    • How do you contribute to the project?
    • How are changes reviewed?
    • How do we document changes?
    • How do we test changes?
    • How do we release software? How often?
    • What tools do we rely on?
  • Communication
    • How do we communicate with each other? (Tools, code of conduct, work flows)
    • How do you earn merit?
    • Who takes care of recognizing contributions?
  • Decision-making
    • How do we decide?
    • Consensus, majority-based?
    • Who has the final say?
  • Legal
    • What do we have to watch out for?
      • licensing,
      • use of libraries, logos
      • compliance

All these processes should be formalized and documented as much as possible. This not only helps the existing community but also allows others to understand how the community works and whether it is safe to rely on the produced software.

4. Ownership

Ownership is often associated with the license of the code, so let’s review some common open-source licenses:

Open-Source licenses

  • Public domain

    Not actually a license but a statement which permits free use. This can be problematic in some countries because of the jurisdictional consequences if the license does not state that the software comes without warranties.

  • Permissive: Apache, BSD, MIT, etc.

    This is still pretty much “do whatever you want” but with a legal framework for warranty, branding, distribution and attribution.

  • Copyleft: GPL, Eclipse Public, etc.

    These require you to contribute back your changes if you ever were to distribute the Copyleft licensed code.

  • Propriertary-ish: Open core and other custom licenses.

Licenses are important for communities because they set the legal framework for contributions. They also influence the type of communities which built around them because they allow for different use of the software.

For example, the Apache license doesn’t require you to contribute back if you make changes and distribute/sell them. That may seem bad for the community but it is also a great way to grow the adoption of the code and help the community.

For a community to grow, contributing back upstream and engaging with the community is necessary. There should be an incentive for individuals or companies to stay relevant in the project and participate in it. If you make it easy for people or companies to do that, the license may be secondary.

Beyond the license

Ownership is not only limited to the license. It also applies to:

  • Infrastructure (repository, mailing list, chat, servers)
  • Name (Trademark)
  • Decision-making / governance

The two most prominent models are:

Owned by a single person / company

Often these projects are owned and led by a “Benevolent dictator”. Prominent examples are Guido van Rossum (Python) and Linus Torvalds (Linux).

There are pros and cons to this model. For one, it’s easy to stay in control and keep the project focused. On the other hand, the dictator can become the bottleneck of the project which will slow down its growth. This happened to Linux in the early 2000s when Linus Torvalds was still reviewing and approving all incoming changes.

Foundation owned

Famous foundations for open-source are:

  • Apache Software Foundation
  • Python Software Foundation
  • Linux Foundation
  • Eclipse Foundation / Mozilla Foundation
  • Free Software Foundation

In my eyes, the ASF and the FSF are the most open although they are quite different in terms of defining freedom in code. They both accept monetary donations, but the only way to influence projects is by gaining merit in them.

What does that mean? It means that you based on your contributions to the project you will be granted responsibility (comittership) which gives you power in the project. At the ASF, there is an incubation process which teaches and probes new projects on good behavior inside Apache.

At the Linux and Python software foundation there is also a merit-based model, but contrary to the ASF or FSF, you can also donate money to have a saying in the project’s decisions.

In the end, it doesn’t matter what model you choose but it does look like the open governance model in software foundations has the most potential to grow a large community.


There is not easy recipe for open-source communities. This probably shouldn’t come as a big surprise. Building a community is a not something that happens overnight. Rather it takes a continuous effort to nourish a community. The level of effort may decline once the community is more mature, but there are inevitable going to be challenges which the community will face. To succeed with building a community you need to invest long-term.

A good community is one which develops a good standpoint in all four domains: Code, People, Processes, and Ownership (COPP).

The mindset for success

We have learned about the 4 pillars for a successful open-source community (COPP). In addition, here are 5 important principles which you should watch out for in the course of building a successful community:

  • Communicate openly
  • Document well
  • Innovate frequently
  • Recruit always
  • Foster relationships, e.g. via Meetups/Conferences

With a critical mass, you can build the foundation for your community. Your critical mass might be small to begin with, so keep an eye open for potential new members. Remember, relationships are the core of every strong community.

This post is based on talks given at Fossbackstage 2020 and Berlin Buzzwords 2020.