Skip to content

Instantly share code, notes, and snippets.

@osowskit

osowskit/Open Source Organization.md

Last active August 22, 2017 17:21
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save osowskit/4435f46b8186fde121723b4262ae0040 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save osowskit/4435f46b8186fde121723b4262ae0040 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. Tom Osowski revised this gist Aug 22, 2017. 1 changed file with 14 additions and 13 deletions.
    27 changes: 14 additions & 13 deletions Open Source Organization.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,14 +1,14 @@
    ### TLDR

    Companies will usually take a hybrid approach when producing open source software. At some point, an Open Source project outgrows a single repository and benefits from a dedicated Organization.
    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 these projects. 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/
    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 a large enterprises working together to improve open source programs and share ideas. They can be a great resource to help define your policies: https://github.com/todogroup
    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

    @@ -18,20 +18,21 @@ Over time, repository owners and project maintainers may provide frequent collab

    ### Producing

    The [open source guides](https://opensource.guide/starting-a-project/) 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](https://en.wikipedia.org/wiki/Intellectual_property).

    #### A Single Organization

    **Pros**
    * Ease of administration - organization members and teams
    * Clarity - on where to create and find projects
    * 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](https://help.github.com/articles/github-corporate-terms-of-service/) -
    * [Corporate TOS](https://help.github.com/articles/github-corporate-terms-of-service/)

    **Cons**
    * Unclear which public repositories are maintained
    * Open Source projects are lumped together
    * Adding non-organization contributors:
    * Adding as a user or to a team would consume a paid seat, or
    * they must Fork and Pull, or
    * 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](https://help.github.com/articles/adding-outside-collaborators-to-repositories-in-your-organization/) - free for public repositories
    * May not have access to @mention teams
    * Forces project maintainers to be an employee
    @@ -47,7 +48,7 @@ When an open source project tool or community outgrows a single repository, it i
    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.

    **Pros**
    * Clear purpose of the organization
    * Clear purpose of each organization
    * Contributors can become Organization members
    * Teams can be used to control access to repositories
    * Non-company employees can become [repository owners](https://help.github.com/articles/repository-permission-levels-for-an-organization/)
    @@ -56,5 +57,5 @@ A separate organization also allows a project to have its own namespace, so othe

    **Cons**
    * Users must be manually added/removed to organization
    * Not covered by Corporate TOS
    * Not covered by Corporate TOS - though this may be agreeable
    * Branding not as clear
  2. Tom Osowski created this gist Aug 18, 2017.
    60 changes: 60 additions & 0 deletions Open Source Organization.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,60 @@
    ### TLDR

    Companies will usually take a hybrid approach when producing open source software. At some point, an Open Source project outgrows a single repository and benefits from a dedicated Organization.

    ### Background

    Many applications start by consuming open source software before finding it necessary to contribute back to these projects. 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 a large enterprises working together to improve open source programs and share ideas. They can be a great resource to help define your policies: https://github.com/todogroup

    ### Contributing

    Most first-time contributors to open source software start with a [Fork and Pull](https://help.github.com/articles/about-collaborative-development-models/) 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

    #### A Single Organization

    **Pros**
    * Ease of administration - organization members and teams
    * Clarity - on where to create and find projects
    * Branding - Company gets recognition of open source contributions
    * [Corporate TOS](https://help.github.com/articles/github-corporate-terms-of-service/) -

    **Cons**
    * Unclear which public repositories are maintained
    * Open Source projects are lumped together
    * Adding non-organization contributors:
    * Adding as a user or to a team would consume a paid seat, or
    * they must Fork and Pull, or
    * they are added as [outside collaborators](https://help.github.com/articles/adding-outside-collaborators-to-repositories-in-your-organization/) - 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](https://github.com/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](https://electron.atom.io/) and [Atom](https://atom.io/). 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.

    **Pros**
    * Clear purpose of the organization
    * Contributors can become Organization members
    * Teams can be used to control access to repositories
    * Non-company employees can become [repository owners](https://help.github.com/articles/repository-permission-levels-for-an-organization/)
    * Maintainers can use [Organization Webhooks](https://developer.github.com/webhooks/)
    * Integrations are separate from your company integrations

    **Cons**
    * Users must be manually added/removed to organization
    * Not covered by Corporate TOS
    * Branding not as clear