Project Ownership

Before we unpack how a project’s shared ownership affects research software’s sustainability, let’s define what we mean by ownership.

If a project is shared without any license, it is considered copyright by default, meaning, only the author can decide who can use the different components of their project. Therefore, the best practice is to add open licenses to a project that define the way the existing codebase, software or documentation can be used and shared.

An open source project is more than just the code and documents associated with the software. A major part of a project is about the people involved – the roles they play, the way they interact with each other, share responsibilities, make contributions and receive recognition. None of those is regulated by the license but is undeniably more important for the project’s success.

Project ownership is defined by responsibilities that are important for the success of a project. These include defining goals, identifying resources, working towards finding solutions, addressing challenges as well as benefitting from the overall outcome [GD20]. By defining project ownership, we can build a clear understanding of how the responsibilities of project implementation, maintenance and sustainability are shared among different stakeholders, including the volunteer contributors. Such operational processes in projects can make open source more meaningful, 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 ownership. Shared ownership for an Open source project should include the following aspects:

Who are the project contributors?

Contributors can be individuals, developer/research teams or an organisation. For example, researchers, funding organisations, and host institutes. These contributors can be paid members of the project such as the project lead and project coordinator, or volunteers from the wider open science ecosystem contributing in their own time. These contributors engage in the project either because they are recruited in the project or have successfully found the project due to their personal interest. To ensure that the project involves a diverse community of contributors, it is also important to make the project easy to find and access. Furthermore, contributors can be actively brought in by other contributors from their network.

What brings them to the project?

Contributors generally have some personal interest in the project or want to address a particular issue through their involvement. It could be either using a product generated by the project, receiving some technical support, helping other contributors, gaining personal skills or getting exposed to new practices that they can bring back in other projects.

By identifying these personal motivations of different contributors, the project and ensure that the overall vision is actively aligned with the needs of their contributors.

Why will they take responsibility and accountability as a contributor to the project?

For a project to be driven by a community, it is crucial to define why contributors will be excited to be a part of the project. Based on the motivation of people to collaborate and contribute, we can help them identify the roles they can take and the kinds of contributions they can make. Well-defined roles and opportunities help everyone make meaningful contributions to the project.

How are they are recognised for their contributions?

Contributors work towards advancing the project they contribute to. In open source projects, it could mean contributing to the codebase, documentation, community built around these or their personal leadership. These can be achieved by openly acknowledging contributions made by individuals in an informal way, such as by internal and social communication. This can be more effectively done in a more formal manner, such as by sharing authorships with contributors in publication, project repository or latest releases, creating pathways allowing individuals to move through the decision-making process, or creating incentivisation plans to give visibility and career boost outside the project.

Where can they learn about the project ownership in detail?

This should be openly shared in a document (or set of documents) that are easy to find and can be easily understood by its readers. Details will depend on the scale of the project, but the model of shared ownership with pathways for contributors roles and rewards should be clearly defined.