GitLab Alliances Handbook

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

On this page

• Open to collaboration
• Partner definitions
  • Services partners
  • Channel partners
  • Technology partners
  • Additional criteria
• Handling inbound alliance requests
• Acquisitions
• Workflow guidelines
  • Google docs

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 you can contact Brandon Jung, our VP Alliances.

Partner definitions

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

Channel partners

Primary monetization is through reselling GitLab.

1. VAR/VAD - Channel services including resale, implementation, contracting, support, financing etc.
2. DMR - 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 teams

Technology partners

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

1. Upstream Technology Partners. Examples: JetBrains, Visual Studio, Eclipse, Slack, Cloudability
2. Integrated/Competitive Technology Partners. Examples: Jenkins, Codeship, Shippable, TeamCity, Atlassian. Need very clear agreement from sales, product, and engineering on how we prioritize working with these partners.
3. Downstream/Platform Technology Partners. Examples: AWS, Google, Azure, IBM, Salesforce
4. Sell-to Technology Partners - Most of CNCF and majority of tech partners.

Additional criteria

1. Exposure - Partnerships which generate more exposure to new segments of audiences, integrations are a good example of that.
2. Product usage familiarity - more people using GitLab but not necessarily installing their own instance, open source projects as an example.
3. Adoption - partnerships attracting more people to adopt GitLab for their own instance.
4. Revenue - Revenue generating partnerships
5. Strategic - partners we find will add strategic value to our long term positioning.

Handling inbound alliance requests

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.

Acquisitions

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

Workflow guidelines

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".