How an open project's governance model evolves

As open projects mature, their governance models inevitably change. Here's how we're evolving ours.
73 readers like this.
A two way street sign

Opensource.com

As we continue renovating the Open Organization community, we've been asking hard questions about how we want that community to function. What do we expect of one another, and of the new contributors yet to join us? How will we work best together? And how will we keep one another accountable for achieving our shared goals?

When open projects and communities discuss expectations like these, they're talking about "governance." In this case, "governance" refers to the various processes by which rights and responsibilities get distributed throughout a group. As community member Jen Kelchner puts it, "it's the framework that creates the structure of the organizational system and the rules by which the parts of that structure can and do interact with one another."

A community's governance model explains how that community functions. Maintaining a system of governance often helps a community define and describe the roles people play in that community.

Those shared definitions and descriptions are important. First, they allow community members to speak a common language about values and ambitions. They also advance community members' ability to contribute, because they make explicit the rules everyone is playing by. And they ensure community members receive the various types of status and social capital they need and deserve.

The best governance models are flexible and adaptable. They grow with their communities. As the Open Organization community grows, so does its governance model. We've needed to revisit how we describe our community and the opportunities for contribution it affords people. (We also fix typos.)

Let us describe what we're doing.

New commitments

Through this conversation, we've been able to update the Open Organization project description and vision.

That vision initially took shape nearly five years ago, when the Open Organization Ambassador team first formed. At the time, Red Hat community architects Jason Hibbets and Bryan Behrenshausen drafted a document describing what a community of passionate advocates for open organizational principles might look like. The vision was entirely aspirational, describing what could be—rather than what was. It served as a beacon to attract passionate contributors to a still-nascent project.

As soon as the community did attract new members, however, those members promptly wrote their own mission and vision for the Open Organization project, articulating their identity and purpose. And as we've grown, we've realized that we're all committed to even more than we originally described. Our community is adept at translating open organization principles for various audiences and contexts, and at helping different communities connect to our language and culture through their own languages and cultures.

The best governance models are flexible and adaptable. They grow with their communities.

For example, Laura Hilliger has long seen an overlap between openness and cooperatives (as have others in the community). She's spoken about that overlap and lived it through her career—serving as a translator between two "radical" economic and communal ideas that use different terminology but are seeking the same kind of fair-mindedness in their activities and collaborations. Other Open Org community members have written about Agile methodologies and their association with open principles, open principles at work in educational organizations, and more.

Our commitment to this sort of "translation work" wasn't highlighted in our working project description, so we updated the description to include it.

Role playing

Another hole we wanted to fill was a better description of the types of contributions one can make to this community. We wanted to talk about our contributors in a slightly more nuanced way, which we indicated in the initial project vision and then extrapolated into a fully fledged "Community Roles" wiki page.

Being specific about community roles helps us make the project more inclusive. It also gives us a method to codify policies and procedures because we can associate them with individual roles people can play in the Open Org community.

So we've made some decisions about how contributors get read/write access to community repositories, and how certain kinds of contributors can nominate people to "level up" in the community.

Just as people join communities, they also leave. Everyone's interests and passions change over time, and sometimes what brought them to your community is no longer meaningful to them. And that's okay.

We've also established a new kind of contributor, the "Maintainer," which gives Ambassadors expressing interest in leading and maintaining community-driven projects a way to show ownership and initiative around a particular project the community is working on. In short: It opens an important new contribution pathway and helps existing community members play an even more influential role in the Open Organization project.

And we're also recognizing the regular flux and flow that marks an open community like ours. Just as people join communities, they also leave. Everyone's interests and passions change over time, and sometimes what brought them to your community is no longer meaningful to them. And that's okay.

Sometimes, people will stay involved in a community because they feel a sense of belonging or status, even if they're not interested in doing the work anymore. And they carry with them important project history and context, which no one wants to see evaporate. So we're also adding another community role, the Open Organization Ambassador Emeritus. By giving community members emeritus status, we give Ambassadors the freedom to move on to something else without "kicking them out" of the project altogether.

All in all, defining and documenting roles and responsibilities will help our community attract contribution because it clearly explains what getting involved means and the benefits of doing so.

Next steps

We've come a long way. But there's more to be done.

The next bit of work we'd like to tackle is developing a code of conduct. Want to share your experience in this area? Why not join us and help out?

Read the previous part

What to read next
User profile image.
Laura Hilliger is a writer, educator and technologist. She’s a multimedia designer and developer, a technical liaison, a project manager, an open web advocate who is happiest in collaborative environments. She’s a co-founder of We Are Open Co-op, an Ambassador for Opensource.com, is working to help open up Greenpeace, and a Mozilla alum. Find her on Twitter and Mastodon as @epilepticrabbit
User profile image.
Ben Cotton is a meteorologist by training, but weather makes a great hobby. Ben works as the Fedora Program Manager at Red Hat. He is the author of Program Management for Open Source Projects. Find him on Twitter (@FunnelFiasco) or at FunnelFiasco.com.
Bryan Behrenshausen
Bryan formerly managed the Open Organization section of Opensource.com, which features stories about the ways open values and principles are changing how we think about organizational culture and design. He's worked on Opensource.com since 2011. Find him online as semioticrobotic.

2 Comments

Thanks for sharing this. The article is a very interesting look at how a community's members can help that community morph into something the people who founded the community never considered or expected.

Not that many authors can make a structured article like this, thanks

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Download the Open Organization Leaders Manual

The nature of work is changing. So the way we lead must change with it.