Community Governance Considerations of Open Source Projects

Posted on Mon, 06/05/2017 - 16:25

DrupalCon was a great way to connect with the community and gauge the pulse from recent events involving Crell. After writing blog posts, I engaged with many people to share thoughts and hear perspectives. One common question that came up: what do other communities do for governance?

This motivated me to do some research of my own. I wanted to be better informed in discussions to know what other communities are doing in an effort to identify where our communal gaps might be. I am a firm believer that the Drupal community doesn’t need to “reinvent the wheel” or think we are “special snowflakes”. There are countless other projects out there dealing with the same problem space. I explored online documentation for other projects and open source communities. I also found research and blog posts on governance topics for communities. I’ve included all of my references below. This blog post is a simple effort to summarize and share what I learned about community governance.

Premise

There is a great deal of diversity in community governance of Open Source Software (OSS) projects. There are various considerations unique to each project and subsequently each project leverages different governance concepts and structures. While the use of governance structures may differ, there is a substantial amount of concepts shared among them. As such, my emphasis is to highlight a set of objectives/motivations and an associated set of governance concepts communities have hand-selected. Please note, I did not research every open source project and the ideas presented are likely not exhaustive.

I extracted a summary quote to provide a satisfactory overview defining the need for governance in line with my findings:

"OSS is best understood neither as primarily a technical development or social process perspective, but instead as an inherent network of interacting sociotechnical processes, where its technical and social processes are intertwined, codependent, coevolving, and thus inseparable in performance "

Chris Jensen and Walt Scacchi, “Governance in Open Source Software Development Projects: A Comparative MultiLevel Analysis”, OSS10

Effective governance must understand the diverse technical and social needs of the community to effectively serve members. Members of the community need governance to ensure the communities’ values are upheld by other members. Governance ensures fairness and helps the community establish and maintain an identity. This identity must be made clear so community members, often volunteers, feel confident they are participating in something that aligns with their value system. The need for community governance shares a similar argument presented by The Tyranny of Structureless written by Jo Freeman.

Community governance is not one-size-fits-all between communities. There are many factors and motivations. Community governance can change based on the size of the community, financial support, application of free and open source ideologies, desired leadership, and much more. Community governance influences include operational management, health and sustainability, distribution of both centralized and decentralized decision making, and separation of duties.

Community Governance Objectives/Motivations

The following list represents a set of objectives and motivations that seemed present in one or more of the communities I researched.

Shared Purpose - As a community, there needs to be a shared purpose that is the foundation for all community governance activities. This shared purpose is often a function of serving the community.
A Representation of Values - Members want community governance to be a representation of community values.
Simple - Community members want straightforward governance to understand how the community operates.
Transparent - Community members build trust through openness and governance activities should strive to be as transparent as possible.
Clarity - All aspects of the community governance should be clear and easy to understand.
Consistent - Community governance structures and processes need to be consistent to build member trust.
Evolving - As the needs of the community change, so must the communities’ governance.
Involvement - All governance activities need to involve the entire community in governance participation to ensure broader interests are represented.

Concepts

Leaders

Open Source projects are often founded by an individual that started with an idea and ran with it. When small, a leader can maintain a much larger and active role in contribution and direction as the principal decision maker. As open source projects grow, leadership often morphs into technical vision, product roadmaps, and high level prioritization of initiatives. As an enabler, a leader should understand the strengths of the project and community to ensure priorities are clear and the community is empowered to deliver on that vision. While the leader may still make decisions (mostly technical), he/she should aim to be representative of, and engaging with, the community members he/she represents.

Foundations

Many open source projects associate with a non-profit “foundation” that performs a variety of supporting oversight functions across one or more projects aimed at stewardship, growth, stability, health, operations, and advisory. The functions vary between foundations, but can represent project infrastructure (tools), manage project financing, sponsor events, and navigate licensing needs. Foundations often establish data and metrics to help evaluate project health. Examples include the Linux Foundation and Apache Foundation.

Special Interest Groups

Special Interest Groups represent a significant way to distribute communal responsibilities for both decision making and focus areas of the community. They serve both social and technical needs and can be considered in technical, working, or advisory capacities. For instance, Kubernetes uses Special Interest Groups like “Documentation” and “Apps” to provide dedicated community focus in those topics. Groups are often sanctioned by the community with a charter and a defined focus area and often serve as a way to help a community evolve as needs arise. Group size and structure vary depending on the amount of activity, but group activity is intended to be both open and inclusive of community member needs. Groups engage the communities through the use of issue queues, open meetings, posting of meeting notes, and more.

Boards

Boards serve communities in advisory capacities. While a foundation helps steer operational needs of a community (sponsoring tools, events, etc), a board works with both the leader and the various groups to help steer and inform community efforts. Boards can be viewed as an escalation from groups and an overall thinktank to help inform community strategy. Board composition should be diverse and consider periodic elections to ensure membership routinely changes and there is an influx of new and diverse ideas.

Other Community Roles

Communities clarify the different ways people can be involved. I’ve summarized roles I found:

BDFL - A type of community leader which often helps define overall communal direction.
Board member - Council member to serve in broad consultation.
Group member - Often a subject-matter expert or contributor assigned to nurture a specific focus area.
Foundation member - Individuals (paid and unpaid) tasked with helping support the work of the community.
Contributor - Someone who provides work back to enhance the efforts of the community. This is often code, documentation, or thought leadership within communal discussion
User / Consumer - People that use the open source project.
Corporate sponsor - A company that helps financially support an open source project through paid contribution, funding for the foundation, or sponsoring events.
Evangelists - Individuals that promote the work of the community.

Governance Documentation

Open Source community participants often seek alignment with their value systems. Communities leverage documentation to help communicate the identity of the community. This is represented in many different ways:

Mission statement - Captures the overall goal and purpose of the community.
Vision statement - Defines the communities’ aspirations and long-term objectives.
Diversity statement - Describes the intent of the community to promote inclusivity and equality across all walks of life.
Code of Conduct - Guidelines that define expectations of community members with respect to the community.
Conflict of Interest statement - Guidelines to mitigate or remove motivations or decision-making that may reflect the interests of one individual or organization exclusively.
Community guidelines - Operational guidelines that describe the tools available to community members and set foundational expectations community members are expected to follow.
Contribution guide - Guides that aid community participation and describe how to get involved.
Contribution standards - Clarifies expectations of contributions.
Conflict management policy - Articulates processes and guidelines for managing conflict (social and technical) within communities.

Engagement

Open Source projects rely on various activities and tools from community members to be vibrant. Engagement can be performed in many different ways:

Code - Code contributions are one of the primary ways technical people give back to communities, which are often measured in commits.
Open meetings - Groups and boards hold open meetings that often allow community members to be informed and participate.
Elections / Voting - Community voting is a means of collecting feedback from community members on initiatives or membership.
Retrospectives - Members need opportunities to provide feedback (and not just through issue queues). Retrospectives share what people have learned and help identify next steps to evolve community efforts.
Meeting notes - Notes should be shared to allow non-present community members the ability to review at a later time.
Issue participation - Community members help to organize bugs, plans, and documentation needs inside of issue tracking systems. This also allows members to collaborate and test work (patches, pull requests) before finalizing an approach.
Wikis / documentation - Communal knowledge should be captured within wikis that, 1. Should be routinely updated by any community member, 2. Afford information sharing that
E-mail Lists / Notifications - Threaded communication and notifications over email and/or web archival tools.
Direct Messaging channels - Tools like Slack, IRC, and more provide the ability to set up both generic and specific channels (groups) and one-on-one messaging that allow for community members to communicate more directly.

What About Drupal?

As many of you know, I am a member of the Drupal open source community. As I noted, my intent of this blog post is to see what other communities do for community governance. I have intentionally left out Drupal-specific details such that others can form their own opinions. My next step will be a follow-up blog post that captures my observations on current Drupal governance with respect to my research.

Resources

Please note that many of the resources identified below have auxiliary links that further clarify the concepts I mention. I have captured a subset of these links for pages that I found particularly informative.

drupal people