Nudging for a Better Default
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 (See the Nudge Theory by [TS09]). 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:
Select an open source license (whenever you can).
Acknowledging contributors visibly.
Set standards for shared ownership.
Open Source License¶
More awareness around open licensing is required as many researchers who currently own code might not be completely aware of how open source licenses can protect the openness and identity of a project. More code might be licensed if researchers were given a basic introduction into how different open licenses work (for example, copyleft vs permissive) and which to choose, although this will only help projects that are maintained enough for a license to be added (see Licensing) for reference). There should be a push for code to be openly licensed by default. This can be applied by many 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 for example, 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: Select a license for your project
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/). You can read more about it in the Licensing chapter.
Meaningful Acknowledgement of Contributors¶
Ownership should be more accurately shared with contributors by ensuring that the ways of working, contributing and recognising contributions are properly defined in the project. Details on people and practices should be transparently documented and communicated so that not only existing contributors can build a sense of ownership but new contributors can also identify what pathways they can take in the project. There are many kinds of contributions possible in open source projects that go beyond writing code or documentation. Each of these contributions should be acknowledged transparently and fairly. 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 described in The Turing Way Acknowledge chapter, allow people to capture their contributions in a way that is most meaningful for them. A more structured programme can be developed that recognises, rewards and incentivise contributors who are crucial for your project’s sustainability.
Call to action: Acknowledging contributors visibly
Recognising contributors by recording their names in visible locations (like a contributors file) should be added to the admins’ or maintainers’ workflows. Announce and celebrate all kinds of work by communicating them openly in official community forums and channels. You can use GitHub actions, bots or a continuous integration pipeline to automate the process. To take another easier approach, 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. See it working on The Turing Way repository.