Publishing software
As a first step, take inventory of any software created throughout the lifecycle of your citizen science project. Did you create a website or a web app? Is there code for data analyses? Maybe you wrote a mobile app for data collection? Simply publishing any code you wrote - big or small - to a repository like Zenodo is a great first step. What follows are some best practices for integrating open science processes into software development for your project.
Git logo by Jason Long from Wikimedia Commons, CC BY 3.0
Adopt a version control system
One of the most popular open science practices is organising your software code with a version control system. Version control for software is roughly analogous to the “tracked changes” feature that you might have used in word processing. Version control tools allow you to take snapshots of code as it is being written. They help you manage contributions from different developers and resolve possible conflicts between them. The complete history of these snapshots reveal a wealth of information on how people worked together to create the final product. Remember, this history of changes helps you reflect on your work and is valuable for others to learn from: it is an example of opening up the processes, not just the outputs, of open science.
One of the most popular software version control systems is called Git. You start by putting all your source code files into a repository (which is just a folder), then you tell Git to track all the changes that happen within. The Software Carpentry Foundation has a great short course on the basics of using Git. Feel free to take a quick look before moving on.
There are several popular online platforms for Git users to collaborate remotely on the same software project, such as GitLab, Savannah, or GitHub. These platforms provide additional features to facilitate open science processes, such as discussion threads (called “issues”) that accompany the code to help contributors work together. Also know that open science publishing platforms such as Zenodo or OSF can be linked to your Git repository and assign it a DOI.
Reproducibility
In the spirit of open science, reproducibility is paramount. When publishing your code, whether on a software-focused platform like GitHub or on Zenodo, remember to include detailed documentation. This documentation should explain the different parts of your code, what dependencies are needed, and steps needed to take source code and turn it into the final usable programme. One of the most effective ways to see if you have good code documentation is to leave it for a few months.
After that, read over your code and see if you can still understand it with the help of your documentation. If so, that’s a good sign your documentation is thorough. You should also ensure your code will run without problems on different computers or devices, and document what is needed to achieve that. It is easy to forget what needs to be set up on a computer before your code will successfully run.
There are many ways to improve software reproducibility. One resource for beginners is the Guide to Reproducible Code published by the British Ecological Society [1]. This Guide is aimed at anyone who writes code, not just ecologists. There a more resources discussed in the Further information section.
Citizen science examples
Many citizen science projects publish the software they wrote. The Zooniverse has multiple Git repositories hosted on GitHub with all the code and documentation for someone else to set up an identical and independent copy of the Zooniverse. The iNaturalist platform has a similar set of repositories. Notably, the source code for the iNaturalist mobile apps are also published there.
The UNESCO Recommendation on Open Science cites “Equity and Fairness” as a core value of open science. By publishing the complete source code to all the software related to your project, you are opening another venue for citizen scientists to participate on an equal footing, increasing transparency and reproducibility of the scientific process, and taking responsibility for the code you write.
References
1. Croucher, M., Graham, L., James, T., Krystalli, A., & Michonneau, F., 2017. Guide to Reproducible Code (N. Cooper & P.-Y. Hsing, Eds.). British Ecological Society. Available from: https://www.britishecologicalsociety.org/publications/guides-to/