Important! The content of this resource is provided -as is- for educational purposes and it is not part of GitHub's official documentation. For GitHub's Official Documentation, please visit GitHub Docs
What GitHub options are there for companies delivering purpose-built SaaS to their customers? What solutions meet the need of both vendor and customer collaborating on the code in the same place?
Questions to consider first:
- Direction of code flow
- Are both parties collaborating on the code?
- Are they collaborating on the same codebase at the same time, or will the customer be coding on top of the custom software after it's delivered?
- Does the vendor need to be able to update the delivered code?
- Authentication needs
- Is SSO required?
- Are both parties comfortable with customer users being added into the vendor's internal IdP, and vice versa?
- Who should drive the actual configuration of authentication?
- Cost/licensing
- Which party will be responsible for purchasing additional GH licenses?
- What is the appetite on cost to achieve this collaboration?
Some solutions:
Collaborate in a Free Organization
- Direction of code flow
- Vendor delivers code to repo in Free Org, customer receives it and moves code out
- There is the option to collaborate in the Free Org, but would be limited by Free account lacking features found in Teams or Enterprise accounts
- Alternative: customer contributes to the code in their own private environment after moving it out of Free Org
- Authentication needs
- Both the SaaS vendor and customers access the Free Org
- Authentication happens based solely on Free Org membership, no SSO capabilities
- Cost/licensing
- Good for massive user counts because no paid GitHub licenses are needed
Collaborate in customer-managed repositories
- Direction of code flow
- Vendor would mirror their code into customer's GitHub presence to collaborate there
- Vendor would need understanding of how to remove code if contract ends
- Authentication needs
- Customer brings vendor users into their internal IdP
- Vendor users could be brought in as Outside Collaborators (no SSO required), or as part of traditional IdP group (option for SSO requirement)
- Cost/licensing
- Customer would purchase GitHub licenses for the vendor users
Collaborate in vendor-managed repositories
- Direction of code flow
- Vendor maintains the code in their own repositories, customers are invited to collaborate there
- Customer could then mirror that code into their environment, after collaboration
- Authentication needs
- IAM option 1: Vendor brings customer users into their internal IDP as collaborators
- Vendor could then control customer user access to certain repos by user groups
- IAM option 2: Vendor creates separate Organizations for separate customer IdPs
- Vendor would facilitate configuration of customer IdPs into their GitHub presence, keeping vendor internal IdP separate
- Possible access issues (for the actual configuration itself), scalability issues (new customer means new IdP configuration)
- IAM option 3: Vendor brings customers users in using local invitations
- No SSO capability
- Scalability concerns since user invites would be manual
- Easier configuration, no issues around access to customer IdP information
- IAM option 1: Vendor brings customer users into their internal IDP as collaborators
- Cost/licensing
- Vendor would purchase GitHub licenses for the customer users