Standard public licenses are the popular and widespread method for sharing code. They are necessary because software and its underlying source code are protected by copyright, automatically, upon creation. If you don’t attach a license to source code that you post on a hosting site (such as Bitbucket, GitHub or GitLab), readers must assume it is “all rights reserved,” and they cannot do anything with it. Anyone who writes code, or is interested in using code written by others, needs to  know a few things about open-source licenses. For a quick overview, click through the slides of “A short lecture on Open Licensing” \citep*{barba2017}; also recommended is the article by \citet*{Morin_2012}.
Free and open-source software (FOSS) is under a license that grants the users freedom: to access, use or modify the software for their purposes. The most important distinction between the various FOSS licenses is whether they are permissive or copyleft. These terms are often confused. A permissive license gives more freedoms: the only restriction of use is that the original authors receive credit in any distribution of the software or any derivative works. Copyleft licenses (like GPL) require that any derivative works be under the same license (a.k.a., "share-alike"), and thus they are more restrictive. Academic software benefits most from permissive licenses, which originated at academic institutions, including the Berkeley Software Distribution or BSD License, the MIT License and the Apache License. As a researcher, you benefit from the widest dissemination to more users—including commercial users, who in general are averse to copyleft. I recommend the BSD-3 clause license for all research software (https://opensource.org/licenses/BSD-3-Clause).
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.