An Overview of Open Source Communities

Open source projects usually employ unique collaborative processes and methods to work on a shared codebase or project for team members or individual contributors to ensure cohesive project advancement. To achieve this, the open source community has identified key aspects of managing such communities that ensure proper collaboration.

Management of Open Source Communities

Each open source project usually creates its own structure, with some common aspects:

• People

  Each open source community will have a few key people to drive forward the development of the project in the right direction. The leader of the project is usually the original author of the software or some designated by them and usually has the final say over decision-making in the project. For example, in the Linux kernel, Linus Torvalds, the original author, is still actively involved in development and controls every release of the kernel.
  Sometimes, project leaders will usually handover administration of the project to a technical steering committee or foundation that acts as the governing body of the project. Node.js is an example of such a project - with it being formerly managed by the Node.js Foundation, which has evolved to the current OpenJS Foundation.

  In large communities, the project might by divided into specific parts that are overseen by experienced developers known as maintainers. The maintainers usually oversee development of their components of the project and will usually be the final stop before code reaches the leaders.
  Other than the maintainers, there are also regular and irregular contributors to the projects. Regular and reliable contributors can be given special privileges in the project and are usually referred to as “committers” or “someone with commit rights”. These are generally developers who’ve regularly contributed high quality work to these projects and can be trusted with the ability to merge their own code. On the other hand, irregular contributors generally contribute infrequently to their preferred projects and do not have any special privileges.

  The Linux kernel, for example, is divided into specific subsystems that handle different aspects of the kernel. Each subsystem has a maintainer who will submit work in their subsystem to Linus for final review and inclusion in kernel releases. In particularly large subsystems, the subsystem is usually divided into smaller components or communities which will in turn have their specific maintainers. Individual contributors will send their work to be reviewed by these maintainers who will propagate accepted changes up the maintainer ladder until the changes get to Linus.

• Hosting/Tracking Infrastructure

  Each open source community will have a mechanism for tracking ongoing work, issues and documentation for their projects. Over the past couple of years, GitHub has become the leading hosting service for open source projects. GitHub and GitLab both leverage the Git version control system to manage development of shared projects. On GitHub and GitLab, communities have access to pull requests, reviews and issue trackers that are used to keep the development process sane.

  An example of a GitHub focused open source project is React. All work on React happens on GitHub, with any one being able to create an issue on the public issue tracker. Pull requests are usually submitted to address opened issues which can undergo review by the core React team and the general public. Accepted pull requests are usually merged into the master branch and closed.

  Other communities are able to leverage bug trackers such as Bugzilla for their development. Various Mozilla projects use their public Bugzilla instance to track issues and ongoing work. Bugzilla can also be used for code review for submitted work.
  The Wikimedia Foundation uses Phabricator for the same purpose.

  Despite having an active GitHub repository, the Linux kernel’s development process does not happen on GitHub. The Linux kernel is unique from most communities in that most of its development happens on mailing lists. Each subsystem will usually have its own mailing list where patches are sent to and reviewed for inclusion into the kernel. Active kernel mailing lists can be found here

• Version Control

  For remote collaboration, a good version control system is paramount.
  Git has become the defacto open source version control software in use, but Mercurial and Subversion offer similar functionality. The central Mozilla code repository an example of a large-scale project that uses Mercurial for source and version control.

  Using these tools, patches can be formatted and sent for review in the correct format to enable proper inclusion into the main code base happens.

• Code of Conduct

  As the number of people contributing to open source projects grow, certain behavior is expected from contributors to maintain healthy annd civil communities. A code of conduct included in a project is used to describe the expected behavior from the projects’ contributors and participants. The code of conduct is usually enforced by project maintainers.

  In 2014, the Contributor Covenant was released by Coraline Ada Ehmke. Since then, the covenant has been adopted by numerous communities and was even created into a convenient template that can be easily included into new repositories.

• Licenses

  Each open source project generally has a license included in the source code that explain the rights provided to the user for the software. There are a few popular open source licenses, but all open source licenses typically allow the software to be freely used, modified and shared.

  Popular open source licenses include the GNU General Public License, version 2 and version 3 and the MIT license.
  The Linux kernel, for example, is licensed under the GNU General Public License v2, with a copy of the license being available in every distribution of the source code.

  To contribute in certain projects, contributors might also be required to sign a Contributor License Agreement (CLA) to give the project the right to include your contribution to the project’s code. An example of a project that uses CLAs is React, which usually requires contributors to sign a CLA before their pull request can be accepted.

Each open source community will usually have a unique structure depending on its size and function. Contributing to a specific project will often require the identification of how the specific community is managed and how to utilize the aspects described above to become a productive and valuable contributor.