Open Source Organization.md

TLDR

Companies will usually take a hybrid approach when producing open source software. Open Source projects eventually outgrow a single repository and will benefit from having a dedicated Organization.

Background

Many applications start by consuming open source software before finding it necessary to contribute back to the projects they depend on. Additionally, for a variety of reasons, teams often decide to launch new open source projects. GitHub provides guides that helps individuals, communities, and companies embrace open source software : https://opensource.guide/

These documents provide guidance on topics ranging from how to start a new project and build communities to an overview of best practices covering legal and maintainer responsibilities. This information can be used to help your company define policies and processes that encourage open source contributions while protecting your intellectual property and encouraging participation.

Lastly, the ToDo Group.org (http://todogroup.org/) is an example of large enterprises working together to improve open source programs and share ideas. They can be a great resource as your organization defines your open source policies: https://github.com/todogroup

Contributing

Most first-time contributors to open source software start with a Fork and Pull collaboration model. Commits in a Forked repository are done in isolation and allow anyone to quickly modify a project. A pull request back to the source repository provides project maintainers control over how to incorporate requested changes.

Over time, repository owners and project maintainers may provide frequent collaborators with write access to the repository to enable collaboration in branches, shared repository model. There is flexibility when considering how to set up repositories and organizations for open source contributions.

Producing

The open source guides provide detailed questions and steps to determine when and why to open source a project. Part of the considerations include whether a project maintainer can commit time to the project, whether the project is relavant to a larger community, and whether the project includes company IP.

A Single Organization

Pros

Ease of administration - all organization members and teams can access the project
Clarity - all public repositories under the organization are considered open source projects
Branding - Company gets recognition of open source contributions
Corporate TOS

Cons

Unclear which public repositories are being actively developed or maintained.
Adding non-organization contributors should be done carefully:
- Adding a non-organization contributor as a user or team to your organization would consume a paid seat, or
- non-organization contributors must Fork and Pull, or
- they are added as outside collaborators - free for public repositories
- May not have access to @mention teams
Forces project maintainers to be an employee

Separate Organization

When an open source project tool or community outgrows a single repository, it is better as a separate organization. This provides the flexibility to grow under a single organization and enable members of the open source community to help them manage the project.

TensorFlow, which was originally developed by Google, eventually became its own project with its own policies and maintainers who may or may not be a Google employee.
Other examples projects include Electron and Atom. The license is owned by GitHub but are maintained in the open by the community.

A separate organization also allows a project to have its own namespace, so other related repositories can be better organized (i.e. electron, electron-compile, electron-api-docs, etc.) and access managed by related teams.