The overall success of an open source project often depends on the community. Is the community active, engaged and responsive? Are they helpful? Are they welcoming to new contributors? Do they treat each other with kindness and respect? If the community isn’t healthy, participating in or using an open source project could be a big risk.
This third post in the Navigating Open Source Risk series is focused on community risks (the other posts in this series cover licensing risk and contributor risk). If you are actively using an open source project, you’ll want to contribute fixes back upstream, so you need to make sure that maintainers and other contributors typically respond in a timely fashion. Seeing large numbers of neglected issues and pull requests on a project is a red flag, since it could mean that you won’t be able to get your contributions merged in a timely fashion.
In some cases, you can help solve this problem and mitigate the risk by helping with pull request reviews or issue triage that reduces the backlog of contributions. This is also a nice way to begin contributing to a new project. By helping reduce the backlog of neglected issues and pull requests, you are helping the project as a whole while quickly getting a sense for how open and welcoming the project is for new contributors. The reason this is so important is because there are some projects that don’t actually want contributions from people outside of their company or inner circle of maintainers. These projects are a much higher risk, since you are way less likely to be able to get any of your changes incorporated into the upstream project, and you won’t want to maintain separate patches with bug fixes or features forever.
An open source project’s contribution documents can also have a significant impact on the community, since new contributors bring new ideas and innovation into the project. The contributor documentation should provide enough details about the contribution process so that someone new to the project can make their first contribution. The communication process for contributors should also be clearly defined so that people know where and how to communicate within the project. If everyone understands how people within the project communicate with each other, it avoids frustrating experiences for both new and experienced contributors. One way to mitigate these risks is to volunteer to help with this documentation. In established projects, long-term contributors may not notice that their contribution documents are incomplete or incorrect, and someone new to the project can often be a big help in finding the problems and improving the documentation. The better this is documented, the lower the risk since your contributors will know what to expect and how to navigate the project while also making it more likely that the project will have a sustainable flow of new contributors coming into the project bringing fresh perspectives and increasing innovation within the project.
This final point is possibly the most important and the most difficult one to mitigate. You’ll want to look at how people treat each other in their daily interactions with other contributors in mailing lists, GitHub reviews, Slack / IRC and other communication channels. Projects with a culture of treating each other with respect and kindness are going to be a lower risk because your employees will want to continue to contribute. On the other hand, projects with toxic cultures put your employees and other contributors at risk. There could be real health risks (mental and physical) for your employees, and these toxic environments can impact retention, since employees might be eager to leave in favor of an employer where they won’t need to work in this toxic community. At a minimum, the project should have a code of conduct that you can easily find with details about how to report incidents along with the consequences of violating the code of conduct. If people already treat each other with respect and kindness, but are missing a code of conduct, you might be able help the project implement a code of conduct. If the culture is too toxic, it will be very difficult or even impossible to mitigate this risk.
Because an open source project has some community risks doesn’t necessarily mean that you shouldn’t get involved or use the software, but you should approach it with caution and understand that there are risks. In the case of community risk, things could go terribly wrong with the project as a whole if key contributors start disappearing, or for your company if your employees leave to avoid working on the project. As I’ve mentioned in previous posts in this series, risk exists on a continuum with projects having more or less risk across a wide variety of categories. You’ll need to weigh all of these risks against your business needs to make a deliberate decision about whether to use or contribute to any particular project.
This is the third in a series about assessing the risks of open source software. Next, check out our blog post about leadership and governance.
