The term open-source software (OSS) should be applied only to software released under a public license, and generally only one approved by the Open Source Initiative (OSI, https://opensource.org). Be aware that just because some source code is available on a website doesn’t mean that the software is open source! It must have a license to be OSS. In addition to a licensing model, however, open source is also a development model. The crux of this model is expressed by “Linus’ Law” (for Linus Torvalds, the creator of Linux): “Given enough eyeballs, all bugs are shallow.” Taking advantage of the Internet for distributed collaboration, and cultivating a community of users and co-developers, the quality of the software will persistently improve. This perspective is altogether consistent with the ideals of scientific practice, and the quest for truth.  As researchers committed to open source software, we not only reap the benefits of transparency, reproducibility and the ability to build from each other’s computational work. We also learn to adopt collaboration practices that lead to higher-quality results. 

An essential technology in collaborative code development is version control: a system to automatically record and manage changing versions of source code stored as text. It preserves a complete history of changes to a text file, it identifies who made the changes and when, and it allows one to roll back to a previous version. Because version control works on raw text, you can use it with other types of files, not just source code. In our research group, we use it when writing internal preliminary reports (using Markdown, or Jupyter notebooks), and for all our manuscripts (using LaTeX). Our system of choice to version-control files is git (a program written by Linus Torvalds), which we combine with GitHub for hosting and coordination functions. GitHub not only hosts your files (source code and other content), it helps coordinate your team and your interactions with readers and users of your research artifacts. The issue tracker allows anyone with a GitHub account to leave a message, pointing to a bug or suggesting an improvement. You and others can post responses, and link seamlessly to places in the files where you’ve made changes that relate to the issue. You can make checklists and add labels to organize your work-in-progress; and when a conversation is over, you can close the issue. Over the last few years, we began using the issue tracker to organize our responses to peer review on our manuscripts, which themselves are written publicly in a GitHub repository!

GitHub is a tool-of-the-trade in the open-source world that supports its workflow, and promotes a culture of collaboration. It not only reflects the culture of open source, it brilliantly delivered structure to it. The exemplar of this is the pull request: a vital coordination to work in the open model. In a pull request, a user or another third party wants the owner of a project to perform some action, like making a change to a piece of code. They start by making a copy of the origin repository to their own GitHub account (via a “fork”), they make the changes in their local copy, and open a pull request with the origin. The owner can decline the request—and that’s the end of it—, they can accept it and merge the changes within the original repository, or they can request changes before merging. In the process of reviewing the contribution, the project owner can start a conversation around code, via comments to the pull request. We use this pattern to coordinate all code development in our group: one graduate student making changes to an in-house code base makes a pull request, and another member of the group must review it (and sometimes a discussion ensues) before the changes are merged. Adopting this practice makes us more effective as a team and as a result our work is of higher quality and more reproducible.