How to manage thriving company-led open source communities

Knowing what motivates people to contribute will help you foster an engaged community.
129 readers like this.
Teammates shaking hands and smiling in an office

CC BY 3.0 US Mapbox Uncharted ERG

When I first got involved in community management, I was working at the Linux Foundation, involved in the relatively new Open Platform for NFV (OPNFV) project. Over the next few years, I started to notice a lot of companies building their business around open source software and talking about building communities around their products.

My story from foundation to company

Being involved in a foundation-based project with dozens of member companies, I wasn't sure how a single company-led project would work and also who would join and contribute to those communities. I was especially curious about what contributors and wider community members would gain from getting involved in company led-projects.

Fast-forward several years, and I made a career transition to one of the company-led projects and got first-hand experience working with the wider community at GitLab.

One of the first things I did once I joined the company was talk to a lot of the regular contributors to find out why they decided to join the GitLab community and what keeps them coming back to continue making contributions.

Understanding the community by asking

In those early conversations, I repeatedly heard the following three motivations for participating in the community:

  • Passion for the technology/product: Not surprisingly, many contributors are GitLab users and enjoy the opportunity to improve the product. Also, a number of people say they are big Ruby fans, and they learned about GitLab while searching for open source projects that use Ruby.
  • Opportunities for career growth: Recently, I met several college students who told me that GitLab is their first open source community, and they became involved because they want to gain experience making contributions to open source projects. Even experienced contributors say that participating in the community gives them opportunities, which they can't get in their day jobs, to improve certain skillsets. For example, they may not have the opportunity to work with Ruby or even write code in general, so contributing to GitLab gives them the opportunity to work on things they are interested in and even helps with their professional growth.
  • Sense of belonging: What I hear, especially from experienced contributors, is that after a period of regular contributions, they start to form bonds with GitLab team members and with others from the wider community. Even if most of the interactions are virtual, they like the sense of being a part of a community.

It soon became pretty clear that these contributors' motivations for joining the GitLab community aren't very different from the reasons people are passionate about contributing to open source projects that involve many member companies and are typically hosted by a foundation.

You may already know that many open source contributors are driven more by intrinsic than extrinsic rewards, and I found this to be true whether contributors are part of a single company-led project or a foundation-based project.

Building a community that works for everyone

One of the differences from company-led projects is that the vast majority of wider community members are contributing in their own time. We do have a number of GitLab customers that encourage their employees to contribute to GitLab as part of their job. However, the vast majority of our contributors are investing time and effort outside of their normal jobs or academic work. Since it would be relatively easy for anyone to walk away from a project when they're not required or expected to do so as a part of their job or study, you could argue that it is even more important in company-led projects to cultivate an environment where people can continue to grow and feel a sense of connection.

So what do companies gain from the wider community? Many people focus mostly on code development, but even more valuable to us are the new insights they provide about how they are using our product and how it can be improved. We definitely appreciate and love code, but insights can be shared with us through many other means, such as discussions on issues, forums, blog posts, etc.

In order to help create an environment that wider community members want to stay engaged in and that helps them grow, I remind myself to pay attention to the following areas:

  • Lowering barriers to entry: I'm not talking about making it easy for new community members to onboard and start contributing, although that's undoubtedly very important for all communities. Instead, I'm talking about lowering barriers to information. Since wider community members do not work for the company behind the project, they won't be familiar with (or even have time to follow) all the decisions that are made in the company. In addition, some information (e.g., budget for an event sponsorship) is not shared publicly. However, important decisions that can have a big impact on the community (e.g., roadmap, product features, etc.) should be made as transparently as possible. Even after decisions have been made, you want to make it easy for the wider community members to review the decision-making process and feel comfortable raising questions. If they feel that the decision-making process is opaque or do not feel safe asking questions, they will start disengaging from the community.
  • Nurturing a sense of belonging: In order to form a close bond with wider community members, it's important to find ways to connect with them outside of tools and forums. Things like 15–20-minute video calls, office hours, or trying to connect with them in-person locally or at conferences can go a long way in building and strengthening relationships. I'm still amazed at how meeting someone face-to-face (even if it's on a computer screen) can make a big difference; one reason may be that online, asynchronous communication can sometimes feel transactional. I encourage everyone to find opportunities to interact with community members in real time, even if it's just a few times a month.
  • Highlight member contributions: As I mentioned earlier, open source contributors aren't necessarily driven by extrinsic rewards. However, everyone likes to be recognized and, more importantly, to feel appreciated. Also, if recognitions are framed more as a celebration in the community vs. an individual achievement, you will likely see a lot of community members joining in the celebration. In addition, recognitions are a good way to highlight important contributions and to provide learning opportunities for wider community members. Other great ways to highlight contributions are blog posts, interviews, and panel discussions (either at events or on YouTube videos).

Transparency, collaboration, and community

The motivations for contributors in company-led open source projects aren't very different from those of open source contributors in general. If anything, it's even more crucial in a company-led project to provide an environment where contributors have opportunities to grow and feel a sense of belonging. Even though each open source project or community may have differences and quirks, I think it's clear that the importance of transparency, collaboration, and community is universal.


This article is based on Ray Paik's interactive session, Building a thriving community in (for-profit) open source projects, at ScaLE18x in March 2020. Please watch the video and share your thoughts and feedback in the comments below.

What to read next
User profile image.
Ray is a Community Manager at PingCAP where he is helping to grow the TiDB community. Prior to PingCAP, Ray managed open source communities at Cube Dev, GitLab and the Linux Foundation. He has over 15 years of experience in the high-tech industry in roles ranging from software engineer, product manager, program manager, and team lead at companies such as EDS, Intel, and Medallia.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.