Open Science

Modern research relies on software, and building upon - or reproducing - that research requires access to the full source code behind the software. Open-source research software refers to the use and development of software for analysis, simulation, visualisation, etc. where the full source code is available. In addition, open-source software must be distributed in source and/or compiled from (with the source code available in the latter case), and must be shared under a license that allows modification, derivation, and redistribution.

An article about a computational result is advertising, not scholarship. The actual scholarship is the full software environment, code and data, that produced the result.

Buckheit & Donoho, 1995

Open access to the source code of research software helps improve the impact of research and allows developers to receive credit for their efforts, either through direct citation or via software meta-articles published in journals that publish software articles.

What are the qualities of open-source software? Here is a checklist to evaluate openness of existing research software:

• Is the software available to download and install?
• Can the software easily be installed on different platforms?
• Does the software have conditions on the use?
• Is the source code available for inspection?
• Is the full history of the source code available for inspection through a publicly available version history?
• Are the dependencies of the software (hardware and software) described properly? Do dependencies require only a reasonably minimal amount of effort to obtain and use?

Platforms such as GitHub can be used to manage version control and the management and tracking of changes in a particular piece of software. These services also provide remote storage services that can be used to maintain, share, and collaborate on research software.

It is also important to have a published and persistent identifier associated with your software, such as a DOI. You can use the UFS's figshare to deposit, version and create a DOI for your software. If you are using GitHub, it can integrate with Zenodo to archive the software and provide a DOI when developers make a formal release on GitHub.

Publicly shared software is not actually open source unless accompanied by a suitable license, because by default software falls under exclusive copyright to the creators. If you truly want to share your code with no restrictions whatsoever, you can dedicate it to the public domain. Or you can choose an appropriate license from sites like choosealicense.com, based on what you would prefer to let others do (or prevent them from doing) with your code.

Once you select a license, put the text in the software repository as a plaintext LICENSE file.

The open source principles above extend to hardware. Researchers often use proprietary instrumentation or hardware in their research that is not freely accessible, reusable or adaptable. Scientific hardware includes everything from sequencing tools and microscopes to specialised testing equipment and particle colliders. Open Science Hardware (OScH) is leading a push for the open source movement to include scientific tools, hardware, and research infrastructures through their Global Open Science Hardware Roadmap.

I can't share my software - it's too messy/it doesn't have good documentation/I didn't leave good comments!

Developers of research software around the world empathise with this feeling - people rarely feel their code is 'ready' to publicly share or that it is 'finished'. However, as Barnes (2010) put it, "if your code is good enough to do the job, then it is good enough to release - and releasing it will help your research and your field." In other words, if you feel comfortable enough with your software to publish a study or report results, then the code is sufficiently developed to share with your colleagues. Plus, sharing your code allows others to improve and build upon it, leading to even greater impact and innovation (and citations for you!)

What if someone takes the code I have shared and uses it for nefarious purposes, or claims they wrote it?

Selecting an appropriate license for your software will help protect you from any uses of your software by others; for example, the common MIT License includes both limitations of liability and states that no warranty is provided. If someone else tries to claim that they wrote the software you made available, then you can point to the timestamps on your repository or archived versions as proof of your prior work.

If I share my code in an online repository, I will be deluged with requests for user support.

Although potential users may ask you for help, either via email or (e.g.) issues filed on the online repository, you are under no obligation to provide support if you prefer not or cannot do so. An appropriate license even provides you with legal protection for this.

Common misconception: simply putting code online makes it open-source software. In fact, unless the software is accompanied by a license that grants permission for others to use, copy, modify, and/or distribute, then the developer(s) retain exclusive copyright. A open-source license needs to accompany the code to make it open-source software.