This is the third and final post in this series, which began with the importance of openness and transparency followed by a second post focused on growing a community around your company-initiated open source projects. Finally, this last post contains some corporate benefits and challenges to help you make effective use of your company’s other resources and avoid a few pitfalls while building your community.
One of the benefits of working on a company-originated open source project is the existing network of partners and customers that may be interested in your project. I think sometimes we feel that participation in open source projects can only come organically – but that’s not true. Some of these companies might have employees with relevant expertise or they may be interested in using and later contributing to your project, so don’t be afraid to use your corporate connections to expand your community.
In addition to reaching out to other companies, you’ll need to promote your project. This is an area where company driven open source projects have an advantage. Companies have existing marketing and communication channels and people who can help, so don’t try to do this by yourself. And don’t think that “marketing” is evil or will somehow taint your project’s reputation. Marketing is more than t-shirts and stickers. So get to know your company’s marketing team. The really amazing marketing folks will take the time to partner with you, understand your goals, and provide suggestions to promote your project in a way that resonates with your audience. Your marketing team can help you take advantage of a variety of communication channels – from blogs to social media and event planning and help you build a strategic communications plan.
You should also see if you can get an open source community manager for your project to help get people interested in your project and make them more likely to stick around to become regular contributors over time. Good community managers have spent years honing the skills required to build successful communities, so it might be worth it to have some professional community help. They can take the time to welcome new community members and help them find the resources and documentation that they need to get started. They can lead community meetings and drive the agendas to make sure that those meetings are productive and interesting for your community members. Community managers are often involved in gathering, maintaining, and figuring out how to use metrics dashboards to better understand the community’s strengths and weaknesses. Community managers can also run programs designed to improve the experience for new and existing contributors.
While there are some benefits to maintaining an open source project from within a company, there are also a few challenges.
Planning and product management is something that company driven open source projects struggle with the most. Most companies have established product planning processes and teams of product managers who use those processes to plan for new features and upcoming releases. In a lot of companies, product managers are in a separate product team outside of engineering, and some of those product managers may have never worked in open source communities. Moving to a transparent process in the open with tools that allow anyone to participate is a big change for some teams, and it might require some extra training, mentoring, and practice to get it right. The goal is to move away from using your internal tools and private meetings by moving as much as possible to public issue trackers, GitHub projects, and similar open tools where anyone can see and contribute to the features that are planned for upcoming releases.
Where I see companies underestimate the amount of effort required is usually related to the time it takes to collaborate with the community. You’ll need to have people available to answer questions, discuss new features, and provide feedback on new contributions. Every company I’ve ever worked for has struggled to manage incoming pull requests for open source projects, since it takes quite a bit of time to evaluate contributions and provide feedback. One of the problems is simply time. It takes time to thoughtfully reply and coach people through making improvements to their contributions. However, it isn’t just time. The people working on pull requests need to be comfortable providing tough feedback. Some pull requests will contain poor quality code or possibly never be merged because of fundamental conflicts with the project architecture. It’s important that employees respond to these in a way that is clear about the future of the contribution, but also shows empathy and appreciation for the hard work someone put into the contribution. Providing feedback is a skill, and your employees might not magically have those skills. They may need some training and mentoring to help them provide constructive feedback.
You will also need to make sure that you have a great team for your open source project, and this team needs to be staffed with people who are willing and able to run a project in the open and build a community around it. If you don’t have the skills internally, you might be able to find existing contributors that you can hire. However, people with open source expertise tend to be in high demand, and they can be expensive, so it might make sense to train or mentor some people from within your company. Also, make sure you don’t stop thinking about building the team as soon as you have some developers. You’ll also need people at least part time for documentation, community management, marketing and other roles.
By making good use of some of the benefits of working within a company, like relationships with other companies and access to marketing resources, you can use them to your advantage while you build a community as long as you work proactively to address the challenges of working in the open, managing incoming contributions, and building your team.