Many technology firms are turning to open source tools to accelerate innovation and growth. As these firms work to influence open source projects, governance practices sometimes shift from coordination among a small group of developers and firms to management by large communities of contributors and organizations, often with competing priorities.
Sustainable projects require sustainable communities. Adapting to a larger, more competitive open source landscape requires organizations to invest in community building. This demands a view of source-code availability that's inextricably connected to the social engagements of contributors and organizations in open source projects. Many organizations now consider open source community engagement as both a social and a technical—or "sociotechnical"—investment.
The CHAOSS project seeks to improve the transparency and actionability of open source projects and community health. CHAOSS has identified and defined metrics that meaningfully assess open source community health.
Some CHAOSS metrics provide indicators of a wide range of social factors now essential for understanding the shape of sustainable open source communities. Social metrics require more sophisticated collection and interpretation strategies, such as machine learning, as well as techniques like surveys and the specification of proven practices for attracting and retaining new contributors. Analyzing the social dimension of open source projects focuses on understanding the dynamics of human relations and communities.
The insights into open source community health below result from approximately 36 interviews with corporate open source participants. The names of interview subjects quoted here have been withheld to protect their privacy.
Community building
Corporate open source participants must recognize that community building is central to sustaining open source projects. Answers to such questions as "Is the community welcoming?" and "Whose voices are heard?" are important considerations when building and joining communities:
One thing we definitely look for before we're going to engage [in an open source project] is what's the vibe here? And that's often a very social thing. Do they seem to enforce the code of conduct? Are there people in this community that seem abusive … in various ways?
Community activity
Most project contributors recognize the growing significance of community as part of successful open source projects. They want active communities that continue to advance the project's goals in ways that support all members and reflect the variety of opinions found in community work. They want members that are nice to see and work with regularly. Frequent and positive engagement is becoming so important that a lack of activity or proliferation of toxic interactions are common reasons people exit a community. In fact, it can even be more important than any technical support the community provides:
I worked with the [project] board for a while, and it is such an active one. Unfortunately, there's just a lot of derogatory terms used. The thing about open source, it's all usually text-based, [and] that can be harmful. We'll pull people away from contributing if they don't feel comfortable. I've seen people leave different communities based on how things were handled. I think that the [worst] I've seen is basically just derogatory terms, not necessarily based on race, religion, or gender, just somebody angrily lashing out based on the code they don't want to see or do want to see.
Diversity and inclusion
Equally important is how the community addresses diversity, equity, and inclusion (DEI). Potential contributors ask themselves questions such as, "How will I be treated?" and "How will I treat others?" People understand attention to DEI (or lack thereof) as a critical part of project risk and sustainability. Failure of a community to center DEI in the sociotechnical work of a project influences contributors' decision to join or leave an open source community, regardless of what a community may provide technically:
The moment you see any bullying, like racism, bigotry, or anything that looks like excluding others from the conversation—if that gets called out and dealt with, I mean, it's not great that it happened, but either the person took the feedback and improved their behavior, or they were told to leave. [Either is a good outcome.] But if you see that stuff's happening and no one's doing anything about it, and everybody is just sitting on their hands and waiting for somebody else to do something about it, that's problematic. I don't have time for that. That would cause me to leave.
Community culture
The importance of nurturing a sense of community in open source connects closely to contributor expectations of a welcoming environment for people from diverse backgrounds. In response to these considerations, open source projects must constantly reflect on how to signal that the community is healthy, build trust among community members, and lower barriers to community participation in the interest of their own sustainability.
The way an open source community responds to issues is a very strong indicator as to their balance between [being] receptive to feedback and not receptive to direct contamination. I think that a successful open source project is a balance between the confidence that your code can be scrutinized by others and the humility that random people you don't know can improve your code. That balance between confidence and humility is reflected in the way people respond to issues. So that's what I look for.
Healthy competition
The pressures to align corporate interests with project interests can result in oversteering. A business trying to exert a degree of control that undermines a sense of community is harmful to a project and its maintainers. Creating a healthy community requires a balance of corporate control through paid contributions alongside thoughtful community building.
[One large open source company, for example,] has resources assigned to the project that are being driven by their own internal teams, and their priorities are very much not in our control. Collaborating in that situation is not as attractive as finding a way to do our own thing.
Building sustainability means building community
A technical open source asset's significance and quality depend on a mutually respectful social system, and that is a new reality for most corporate open source participants. Effective corporate engagement with open source projects demands attention to a set of paradoxes. To be competitive, a firm needs to contribute to a set of open source projects they don't control, and competitors are working side by side in these projects. To create a communal environment where a project becomes and remains sustainable, participants must set aside their competitive instincts and foster trust. A rising tide of both social and technical concerns floats all boats.
Open source software's role in creating value for technology firms continues to grow because sharing the costs of creating and sustaining core infrastructure is not only attractive but arguably a requirement for doing business. Sustaining these critical technology assets demands such a high number of talented contributors that forming and nurturing communities around open source software is vital.
Healthy open source communities engender a sense of purpose and belonging for their contributors, so that people continue to want to participate or join. Such communities are made of real and diverse people, with their own interests, concerns, and lives. Open source contributors—whether individual or corporate—must build real communities with participants who are interested in each other as well as the project. That requires a thoughtful, attentive, and often retrospective focus on how we build and manage our open source communities.
We would like to thank Red Hat for its generous support of this work.
[ Explore why companies are choosing open source: Red Hat's State of Enterprise Open Source Report ]
Comments are closed.