In the first post of this series, I talked about the importance of openness and transparency and how it impacts your ability to build a community around your company-initiated open source projects. Today, I’ll share a few other suggestions for how to grow your community and increase participation in your project.
Reducing Barriers to Contribution
A good first step is to reduce any potential barriers to contribution. For example, are all of your project meetings in a single time zone that isn’t likely to work for people in other locations? You may need to adjust your meeting times or make recordings and minutes available to make it easier for people to participate. Having amazing contribution documentation, training, and mentorship can also reduce information barriers and make it easier to contribute.
Do you have a Contributor License Agreement (CLA) process that requires developers to sign a legal agreement before they can contribute? If so, does it make it too difficult for contributors, or does the process make it difficult for your engineers to accept contributions? At a minimum, your CLA should be integrated into your source code repository in an automated fashion with a CLA bot that checks whether a contributor has signed the agreement and provides instructions if not. One way to make it easier for new contributors to get started is to have generous CLA exceptions for obvious or minor fixes that are built into your CLA bot, which can reduce the barrier for simple contributions.
You might be able to move from a CLA to a Developer Certificate of Origin (DCO) or signed-off-by process, which only requires that the contributor self-certifies that they have the right to make the contribution. This has a lower barrier to entry for contributors than a CLA.
For company-initiated projects, you will probably need to have one or the other, CLA or a DCO, but this decision should be made in context of the license. A few licenses have some protections built into the license, which tend to pair nicely with a DCO process. And it also helps to select a license that companies tend to like, so that they are more likely to allow contributions from employees. Apache, BSD, and MIT licenses tend to be pretty popular. Whatever you do, don’t make up your own new open source license. There are a bunch of OSI approved licenses, and your needs are not so special that you can’t make one of the existing OSI licenses work for you. I am not a lawyer, so don’t take any of this as legal advice. You’ll need to talk to your legal team and make a business decision about what type of license and process is the best for you, but I encourage you to do your own research to understand how your licensing and other legal decisions will impact your efforts to build a community around your project.
Encourage Participation in Your Project
It can take quite a bit of encouragement to help people become successful contributors. You should make sure that you are proactive about helping community members contribute in meaningful ways. One good way to do this is by labeling non-urgent and easy to solve issues as “good first issues” that new contributors can pick up. You can use “help wanted” labels for issues that your team might not have the expertise or time to fix right away. The key here is in making sure that your employees actually leave these for other people to work on.
Consider recruiting specific people who are involved in the community, but who work outside of your company, and ask them to provide feedback based on their expertise. This will help people see that you want their feedback and hopefully encourages them to offer it proactively the next time.
One of the things that I see far too often is over-eager employees who immediately answer every question or reply to every post. At first glance, this seems responsive and proactive, but it has a downside. It can inadvertently set the expectation that employees will be the ones who always answer questions and make decisions. You need to give the people who aren’t working on this full-time at your company the opportunity to participate and leave space and time for them to contribute. So wait, but not too long. You don’t want to leave issues and questions unanswered – that will also reflect poorly on the project. One technique to consider — when you respond, invite someone else (by name) in the community to comment on your response.
Mentoring other contributors is a great way to help people gain the skills they need to be successful. You can mentor people to become new contributors or existing contributors to grow them into leadership roles. Mentoring can also be used to help other employees learn the skills necessary to contribute to your project or other open source projects. Kubernetes, for example, has a fantastic mentoring program with elements that could be easily adapted to other projects.
Attend Events and Build Relationships
Don’t underestimate the value of getting people together to meet in person to help build deeper relationships and make it easier for them to collaborate online later. (While this is a challenging statement to make in the wake of event cancellations and social distancing, it’s something to keep in mind for later.) When you’ve met someone in person, they change from a disembodied avatar to a real individual. With face to face interaction you often gain a better understanding of their perspective and that context can help when you read messages from them online later. In addition to building deeper relationships, events and meetups can also help you promote your project. As someone who has organized a lot of local meetups, the hardest part is finding good presentations, so you can always volunteer to do a demo or talk about your open source project at a local meetup.
When talking about your company-originated open source project at an event or meetup, it’s critical to avoid making a sales pitch for your company. Don’t hide your employer’s identity or brand, but don’t make it the first thing you talk about either. As I like to say, bring the brand, but make it sit in the back row, sitting quietly. That restraint will be rewarded. In some cases, encouraging contributors from outside your company to deliver talks at conferences and meetups can bolster your project’s community reputation.
Reducing the barriers to contribution, encouraging people to participate, and building relationships at events can help you grow a healthy community around your company’s open source projects. Hopefully, you’ve found some of these tips useful in building your community. Stay tuned for the third and final post in this series covering how to best use your company’s resources to help you grow your community.
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.
