By Malvika Sharan, Andrew Brown, Warrick Ball and Ben Krikler.

This blog post is part of our Collaborations Workshop 2021 speed blog series. 

The open source and open research movements allow anybody to use, study, modify, and distribute software or research projects freely and for any purpose. Volunteer contributions are central to the success of open source projects and take many diverse forms. Therefore, ‘shared ownership’ is important for motivating contributors to collaborate but, unfortunately, the ownership model is not always described in the projects. Here we explore what project ownership means in an open source world. 

Open source project ownership

Software shared without any license is assumed to be copyright by default, meaning only the author can decide who can use the code. Best practice for sharing software is to add an open source license defining the way the existing codebase can be used and shared. But an open source project is more than just the code and documents. A major part of a project is about the people involved, how they interact and share responsibilities, and how they are recognised for their contributions - none of which is regulated by the license. By defining the project ownership, we can address these concerns, going beyond the software license itself. 

Similar to the copyright default of software, if ownership in a project is not defined, it is not shared. Shared ownership for an open source project should include the following aspects:

• ‘Who’ are the project contributors? 
• ‘What’ motivates them to collaborate and contribute, and what do their contributions look like?
• ‘How’ are they recognised for their contributions? 
• ‘Why’ will they take responsibilities and accountability as a contributor to the project? 
• ‘Where’ can they learn about the project ownership in detail? 

Example of “shared ownership” models

Roles Based on Contributor Access to the Project Repository: For GitHub users, a  familiar set of roles for code ownership includes access levels: “Read -> Triage -> Write -> Maintain -> Admin”. The different access levels define the increasing order of rights and responsibilities a contributor has in a project.

GitHub contributor roles

Open Source Leadership and Governance: A more intentional approach can be taken to formalise roles. This allows contributors with specific interest or availability to step into the project. The Open Source Guides project provides a basic framework for setting roles for maintainers, contributors and committers. In larger communities it can also include members of committees, working groups, special interest groups, mentors, trainers and community managers. Governance also covers the decision-making processes - how different stakeholders are involved and how decisions are transparently communicated.

Defining Roles and Pathways for Contributors: Roles can be developed based on tasks, responsibilities or skill requirements, and 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 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”.

Five steps for developing a “Mountain of Engagement” for Open Source project contributors

Nudging for a better default

Research has shown that humans making decisions have a strong tendency to go along with the status quo or default option. In the absence of an actively defined default, the prevailing cultural or institutional norm becomes the de-facto option of choice. And hence, the default options for ongoing and new projects should nudge strongly towards adopting a shared ownership model. 

The minimum default for an open source project should include the following documents:

1. Open Source License by default: This can be applied by stakeholders in the research ecosystem: funders can require that code produced by a grant is openly licensed and, similarly, publishers can require that code associated with a publication is openly licensed (open research data is already required by funders in the UK; this could easily be extended to cover software). The companies that host repositories can - as some do - make it easy to add a license, and gently encourage users to do so by adding a license by default. 
   
   Call to action: Plan your project from the beginning to be open throughout the lifecycle of your research.  When using personal or identifiable data, clearly state what measures are taken to ensure privacy and data security. For everything else in your work, choose an open source license and add it to your repository (see https://choosealicense.com/). 
    
2. Ways to acknowledge contributions: Ownership should be more accurately shared by ensuring that the means of contributing and recognising contributions are properly defined in the project. There are many ways to acknowledge all contributors, including those who do not code or write documentation. For example, we can learn from open source metrics like CHAOSS or CRediT - Contributor Roles Taxonomy, recognise the hidden labour using frameworks defined by HiddenREF or, as in The Turing Way, allow people to capture their contributions in a way that is most meaningful for them.
   
   Call to action: Recognising contributors by recording their names in visible locations (like a contributors file) should be added to the admins’ or maintainers’ workflows. GitHub actions or bots can be set up to automate the process. For example, you can install the all-contributors bot by https://allcontributors.org to your repository, which can help you recognise contributions including those that don’t involve pushing code.
    
3. Sharing project ownership with the community: In the case of shared ownership, the community builds the project and hence should be attributed as such. One way to do this is to have essential community documents demonstrating the commitment to fairly acknowledge and share ownership of the project with all contributors. 
   
   Call to action: Describe explicitly how someone can cite an open source project by giving credit to the community of contributors instead of attributing individuals administering the project. For example, use “Community” as the first author as practised by The Turing Way. As a simple first step, consider adding contribution guidelines, a Code of Conduct (see Open Source Guide for reference), and a ‘contributors’ page to your project repository to display the names of all the contributors.

A longer version of this post is added to The Turing Way as a chapter in this Pull Request: https://github.com/alan-turing-institute/the-turing-way/pull/1858. We invite you to join the discussion, add your thoughts on this topic or review the chapter.