Building a community around your company-initiated open source projects is hard. Communities require interactions with other humans, and humans aren’t mindless automatons. We have feelings and bad days. We can be squishy, unpredictable, and irrational. But you can’t have a community without the people, so you need to find ways to encourage people to participate. Sometimes it can be really difficult to get people to contribute to your project, and unfortunately, there is no magic bullet or one size fits all solution. In this three part series, I’ll focus on some things that you can do (or not do) to increase the chances of successfully building a community for your project.
Defining “company-initiated open source project”
Before we dive in, let’s talk about the type of project that this blog focuses on. Keep in mind that these are loose ideas with a lot of overlap, and not every project fits cleanly into just one of these:
- Grassroots open source projects: These tend to have more people who contribute out of a personal interest in the project. They usually have independent foundations with elected governance to help with coordination of the project (e.g., Gnome and Debian)
- Ecosystem projects: These also tend to be under neutral foundations for governance, but those foundations often look more like collections of companies, and a large percentage of the contributors are usually participating as part of their day jobs (e.g., Linux Foundation and CNCF projects, like Kubernetes)
- Company-initiated open source projects: This is the focus for this series of blog posts. These are open source projects that are maintained within a company, rather than being under a foundation. Governance usually starts with mostly the employees who made the initial contributions.
To clear some of the roadblocks to building and sustaining a healthy open source community for your company-initiated project, a good place to start is by building an open source strategy if you don’t already have one, which is covered in more detail in my previous blog post.
Openness and Transparency are Critical
One of the most important things you can do to encourage involvement from people from outside of your company is to run your project using open and transparent processes.
It’s all too easy to rely on internal meetings and tools for communication and decision-making; these tools and practices apply for your other work, so why not for this project as well? While leveraging internal processes simplifies contributions from within your company, it builds barriers to all other potential contributors and community members. A great starting point to building a vibrant community is to discuss and make decisions in a public forum, like a mailing list, or in public meetings that anyone can join or watch later. As a community member outside of the company, I want to be able to have input and influence decisions.
Next, use a public issue tracker that contains all, and I mean all, of the bugs and features that are currently being worked on, and for your team to use pull requests and the same process as any other community member when making contributions. These bi-directional communication channels give users, contributors, and maintainers a place where everyone can get together to discuss use cases, get direct feedback on features, and talk about the project, which can help build your contributor funnel to turn some users into contributors and contributors into leaders.
If you want people to contribute to your company’s open source project, transparency and openness are vital. This includes making sure that you have open and transparent governance with a documented process for who makes the decisions along with how and where decisions are made.
As an external community member, I might eventually want to move into a leadership position, so it can help to document the process for becoming a leader. This doesn’t necessarily mean that every leadership position is available, but it should be fairly easy to move people into maintainership positions where they are responsible for some component or to give them commit or approval access. Ultimately, if people feel shut out or constantly surprised by new directions or changes within the project, they are less likely to stick around, which is why having a clearly documented, open and transparent governance process is so important.
In some cases, having open and transparent governance involves being honest with yourselves and with the community. For example, you may want to keep the leadership for certain key roles within the company, but by being transparent about your reasons and documenting it, people can understand why and avoid being frustrated about it later. There may also be areas where you prefer to have contributions and areas that are harder for people to contribute. Put this in the documentation and make sure that you are encouraging people to contribute in the areas where their contributions are desired and more likely to be accepted.
I hope that this post has convinced you of the importance of openness and transparency when building a community around your open source project. Stay tuned for the next post in the series, which will be focused on community growth.
Dawn Foster is the Director of Open Source Community Strategy in VMware’s Open Source Program Office. You can learn more about Dawn by visiting her blog or following her on Twitter.
