GitLab Alliances Handbook

1. You are here:
2. Handbook
3. GitLab Alliances Handbook

On this page

• Alliances Mission
• Alliances KPI's
  • Active installations per hosting platform
  • Active SMAU
  • Product Download by distribution method
• Open to collaboration
• Partner definitions
  • Technology partners
  • Services partners
  • Resellers
• Criteria for successful partnerships
• GitLab delivery models
• Acquisitions
• Workflow guidelines
  • Handling inbound alliance requests if at GitLab
  • Google docs
  • Cloud images
  • MDF cloud credit reimbursement process
  • License requests

Alliances Mission

Accelerate GitLab’s trajectory by connecting the great work every team is doing with the outside world

Alliances KPI's

Active installations per hosting platform

Total active installations per hosting platform (Total, AWS, AZure, GCP, IBM, Red Hat, Digital Ocean, etc) in a given calendar month.

Active SMAU

Current SMAU per hosting platform (Total, AWS, Azure, GCP, Red Hat, Digital Ocean, Unknown etc) in a given calendar month.

Product Download by distribution method

Total downloads by installation method(Omnibus, Cloud native helm chart, Source, etc).

Open to collaboration

GitLab is an open product with a Core, open-source edition, and a enterprise, open-core edition, with additional features that are closed-sourced.

We're open to integrations with companies and tools that are interested in harnessing GitLab's platform capabilities, user flows and data with their products.

If you want to talk to us about a partnership please create a shared Google Doc that includes: details about the technical integration, end user benefits and business relationship that you would ideally want. Then please contact Brandon Jung, our VP Alliances.

Partner definitions

Technology partners

Primary monetization is through the sales of software licensing/support that integrates with GitLab

1. Platform Partners. These are critical partnerships and will be prioritized to support our customer demands.
   1. Cloud partners. For example AWS, Google, Azure, Digital Ocean, IBM
   2. Kuberentes partners: Red Hat, Rancher, VMWare, Mesosphere, Cisco, NetApp, etc.
2. Upstream Partners. Examples: JetBrains, Visual Studio, Eclipse, Slack, Cloudability.
3. Integrated Partners. Examples: Jenkins, Codeship, Shippable, TeamCity, Atlassian. Need very clear agreement from sales, product, and engineering on how we prioritize working with these partners.
   1. Some of these are critical integrations that we will maintain based on our customers needs (Examples: GitHub, Jenkins, Jira)
   2. We encourage other ingration partners to make and maintain the integration with us
4. Sell-to Partners - Most of CNCF and majority of tech partners.

Services partners

Primary monetization is through the sale of services. This can be a one-time implementation, ongoing support, or outsourcing.

1. Global Systems Integrators - have a large global workforce and can deliver on almost any customer need. Examples: Accenture, Deloitte, TCS, Wipro
2. Regional Systems Integrators - large workforce but with single continental focus and a more limited offering of services. Examples: CI&T, Slalom
3. Boutique Systems Integrators - very focused DevOps partners that could be deep experts on GitLab and the nuances of getting it setup and running it. Examples - Managed Service Providers - provide ongoing support for solutions/applications. Examples: Rackspace

Resellers

Primary monetization is through reselling GitLab.

1. VAR/VAD (Value Added Reseller or Distributor) - Channel services including resale, implementation, contracting, support, financing etc.
2. DMR (Direct Market Reseller)- primary business is resale of the software, often does not implement. Value are the contracts that these partners have in place with customers.
3. Training Partners - focus on training companies, teams and often certifications

Criteria for successful partnerships

1. Exposure - Partnerships which generate more exposure to new segments of audiences, integrations are a good example.
2. Product usage familiarity - more people using GitLab but not necessarily installing their own instance (GitLab.com), open source projects as an example.
3. Adoption - partnerships attracting more people to adopt GitLab for their own instance. Upstream and downstream partners help here.
4. Revenue - Revenue generating partnerships. Users come first but focus on revenue has ensured we have the revenue for sustainable growth.
5. Strategic - partners we find will add strategic value to our long term positioning and often around competitive situations.

GitLab delivery models

There are many ways that GitLab can be both installed (https://about.gitlab.com/install) and once installed many deployment environments that GitLab can target. Below is a structure to think about those options and some of the trade-offs that are made depending on the model.

• Self-managed - customer downloads, installs and maintains themselves
• GitLab Hosted - same code as self managed but maintained by a third party
• Marketplace - self-managed but purchased through marketplaces
• GLaaSTS - fully managed (by the cloud provider) private instance of GitLab. Similar to the managed database options clouds offer.
• GitLab.com - fully managed multi tenent offer by GitLab Inc.

Delivery Model	Self-Managed	GitLab Hosted	Marketplace	GLaaSTS	GitLab.com
State	Active	Depricated	Soon	Future	Active
Tenents	Single	Single	Single	Single	Multi
Installation Package	Omnibus/Helm	Omnibus/Helm	Omnibus/Helm	Helm	Moving to Helm
Managed	Self	Partner	Self	Cloud	GitLab
Billing Ownership	GitLab/Partner	Partner	GCP, AWS, DO, etc	Cloud	GitLab
Infrastructure Incl.	no	yes	yes	yes	yes
Partners	SI's/VAR's	MSP's	Clouds	Clouds	GitLab/Partner
Sales Focus	Hybrid/Multi-Cloud	Partner	Self-service	Self-service	Self-service
Pricing	user/yr	user/yr	user/month or hour	user/yr	user/yr

Acquisitions

If you are interested to inquire about a potential acquisition of your company please visit our acquisition handbook.

Workflow guidelines

Handling inbound alliance requests if at GitLab

If you've received an inbound alliance request please post a new message to the #alliances Slack channel with the brief description of the request. Once posted, the alliances team will declare who will take lead on that request and the necessary next steps to take.

Google docs

1. Gdocs which are shared with the partners should be set to "Anyone with the link". Internal Gdocs should be set to "GitLab".
2. The following structure should be used for Gdoc names: "PARTNER NAME and GitLab".
3. Alliance folder contain current work with partners and are kept by Partner name

Cloud images

See the Cloud image process page for guidelines.

MDF cloud credit reimbursement process

When applying for MDF funds which are reimbursed in the form of cloud credits to a GitLab account follow the following process to make sure all relevant parties are informed:

1. Create issue with the following details on the campaign:
   1. Campaign topic
   2. Timeline
   3. Budget
   4. Marketing targets
2. Budget spend approval and acknowledgement from AWS/Google/etc
3. Future credit acknowledgement - by production team lead

License requests

When existing or potential partners reach out with a request for a free license for the purpose of developing an integration with GitLab most would need a self-managed license key. To generate a license follow the steps below according to the type of license:

1. Self-managed:
   1. Inquire with the partner how many developer seats will be necessary
   2. Go to https://license.gitlab.com/ and sign-in with your GitLab credentials
   3. Choose the manual entry option
   4. Select the Ultimate license (unless requested otherwise)
   5. Set the term for 6 months
   6. Set the appropriate number of seats, if unknown set at 5. The total number of seats should not exceed 10.
   7. Provide any relevant details about the purpose and use of the license in the free form text box at the bottom of the page
2. GitLab.com:
   1. Inquire with the partner how many developer seats will be necessary
   2. Create an issue here: https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues and choose the plan-change-request template
   3. Set the appropriate number of seats, if unknown set at 5. The total number of seats should not exceed 10.