Shared Ownership Models

At the time of writing this chapter, We have identified the following models of shared code ownership:

Roles Based on Level of Access

For the GitHub users contributing to an open source project, folloing roles are defined by the access levels: “Read -> Triage -> Write -> Maintain -> Admin” (see GitHub page for reference). The different access levels define the increasing order of rights and responsibilities a contributor has in a project (see GitHub documentation for details).

For GitHub organisations, there are options to organise members into teams with different roles and access levels. Owner permissions for a GitHub organisation can be given to a group of people who manage the organization account such as granting permission levels to contributors as needed (see details).

The default minimum permissions for members allows reading, forking, creating issues, fixing bugs and suggesting minor changes. It is an easy pathway for new contributors to enter a project, however, not sufficient to feel like a part of the community. To foster a sense of shared ownership, the basic level of access should be ‘writers’, who can review new contributions, and make and approve changes allowing them to share responsibility for the development and maintenance of a project.

If these roles are not explicitly defined, the burden will be put on contributors to find out what level of access they have and how they can be promoted to the next levels.

Open Source Leadership and Governance

Unlike the previous example, where the roles are ‘assumed’ based on access level, a more intentional approach can be taken to formalise roles for all contributors under the leadership and governance aspect of an open source project. This allows contributors with specific interests or availability to identify and step into the project. The Open Source Guides project provides a basic framework for setting roles for the maintainers, contributors and committers. Furthermore, they describe how to meet contributors where they are to facilitate shared ownership. In bigger communities, roles can be expanded to include members of different committees, working groups, special interest groups, mentors, trainers and community managers who focus on different areas of development, maintenance and sustainability. In addition to the roles, governance also includes the decision-making processes - how different stakeholders are involved and how these are transparently communicated.

Defining Roles and Pathways for Contributors

As discussed, a clearly defined set of roles and responsibilities allow individuals or groups to build a sense of common purpose and set a clear expectation around shared ownership in the project. These roles can be developed based on the tasks, responsibilities and skill requirements in the project.

Fig. 36 A “Mountain of Engagement” for Open Source project starts with (1) A list of people’s interaction with your work, and (2) 3-5 deepening bands/levels of engagement. (3) Then you can brainstorm and group your interactions into bands of engagement, and give each band a name. (4) With your work you can then identify what works and what doesn’t work. (5) This gives the insight to prioritise your work to create more opportunities for your contributors.

These roles can be contractual or informal, taken by paid or non-paid volunteers, and supported by legal or social policies. These roles and pathways for engagement for the contributors can be understood using Mountain of Engagement as described by Mozilla Open Leadership and Open Life Science. The purpose is to identify levels of engagement of contributors as they move from their roles as “observers”, “endorsers”, “contributors”, “leaders” and finally, “owners”.