GitLab Alliances Handbook

1. You are here:
2. GitLab Alliances Handbook

Maintained by:

On this page

• Alliances Mission
• Who are we
• Open to collaboration
  • Interested in a GitLab Technology Partnership?
• Partner definitions
  • Technology partners
  • Services partners
• Sales Alignment with Platform Partners
• Criteria for successful partnerships
• GitLab delivery models
• Acquisitions
• Workflow guidelines
  • How Alliances manages work in GitLab - Alliances Group
• How Alliances mesures revenue impact in GitLab through co-selling
  • Labels for Alliance Pillar
  • Priority: Alliance - Priority : <P#>
  • Status: Alliance - Status : Status
  • OKR Goals: Alliance - OKR : OKR FY'YY Q#
  • Internal Process
  • Handling inbound alliance requests if at GitLab
  • Google docs
  • MDF cloud credit reimbursement process
  • License requests
    • Self-managed
    • GitLab.com

Alliances Mission

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

Who are we

• Nima Badiey, VP, Alliances
• Mayank Tahilramani, Director, Alliances {Focused on Strategic Public Cloud Partnerships}
• Pete Goldberg, Director, Alliances {Focused on Strategic Public Cloud Partnerships}
• Vick Kelkar, Director, Alliances {Focused on Strategic Private Cloud Partnerships}
• Kasim Ahmad, Business Development Manager {Focused Alliance Co-Sell Partnerships}
• Mike LeBeau, Manager, Alliances {Focused on Ecosystem Partners}

GitLab Team: Please visit the Private Alliance Handbook Page for additional information about Alliance Partners.

Open to collaboration

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

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.

Traditionally GitLab had defaulted to a competitive voice when talking about other companies. This is counterproductive for the following reasons:

1. Customers are often not ready or looking to replace all of their tooling. We risk losing credibility when we suggest that we are a replacement (competitive) in areas that we are not.
2. We are actively creating an anti-GitLab salesforce in all of our partners vs collaborating.
3. We may be jointly and actively selling or building integrations with these companies and this voice can be damaging in said partnerships and confusing to customers.

Messaging going forward (Oct 2019):

1. We need to be clear of where we are and where we will be in the future
2. We should highlight our partnerships and through these integrations provide users a single application platform for the entire SDLC

GitLab will use competitive language only in stages where we are lovable. (Product Maturity and Product Strategy)

For all areas where we are not yet lovable:

1. Support integrations with companies that are leaders in their categories and enable them to work well with GitLab.
2. We will actively work to ensure strong integrations (i.e., Jira) through partnerships (Alliance team) that will be driven by customer demand.
3. Through product integrations, GitLab helps developers compile all their work into one tool that can be accessed anywhere. We have worked closely through partnerships to provide developers with a single DevOps experience. GitLab has created partnerships and incorporated integrations with a number of companies including Aqua Security, ARM, AWS, Bitnami, Canonical, Datadog, Digital Ocean, D2IQ, GCP, Mattermost, NetApp, Microsoft, Portworx, Rancher, Suse, Sysdig, Upbound, VMware, Whitesource, and many more.

Interested in a GitLab Technology Partnership?

GitLab is open to collaboration and committed to building technology partnerships in the DevOps ecosystem. If you are interested in becoming a GitLab Technology Partner, learn more on our Integrate with us page.

If you want to talk to us about a partnership please create a New Partner Issue and share details about the technical integration, end user benefits and business relationship that you would ideally want. When creating an issue, please select new_partner issue template in the drop down.

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. Kubernetes partners: Red Hat, Rancher, VMWare, Mesosphere, Cisco, NetApp, etc.
2. Integrated Partners. Examples: Jenkins, Codeship, Shippable, TeamCity, Atlassian.
   1. Outbound: There is a core set of priority outbound partnerships we will maintain and focus on. Those are: GitHub, BitBucket, Jira and Jenkins
   2. Inbound: GitLab plays well with others. This means we will support integrations to make them successful by enabling them within our product but we encourage other integration partners to make and maintain the integration with us. The work required to deliver the integration will be provided by the partner. For go-to-market initiatives with inbound partners, we are open to collaboration but expect them to lead the effort.
3. Sell-to Partners - Most of CNCF and majority of tech partners.
4. Upstream Partners. Examples: JetBrains, Visual Studio, Eclipse, Slack, Cloudability.

Services partners

For details on how to we work with Channel partners please go to the Channel Handbook page: Channel Partner Types

Sales Alignment with Platform Partners

We are able to connect with sales and technical teams at platform partners to accelerate deals and add value for customers.The best way to engage with platform partners is with active opportunities that include expansion for an existing customer and POV or technical evaluation for a prospect.

1. Reference Google Docs to review the sales enablement material on co-selling with the partner.
2. Identify active opportunities (at or about to enter Stage 3) or expansion with current customers.
3. Register the opportunities using the partner registration forms included below. This will allow us to gather the required information to register them in the partner's portal. Once the submission is approved by the partner, we will get an introduction to the account manager covering that account. This can take up to 3-5 business days.
4. For any questions on the above steps, navigating enablement material or if an opportunity is fit to engage a partner please reach out to Kasim Ahmad.

AWS Opportunity Registration Form

GCP Opportunity Registration Form

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.
6. Alignment - collaboration is stronger and our customers have a great experience when the Product, Marketing, and Sales teams are aligned.

GitLab delivery models

There are many ways that GitLab can be both installed (/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
• 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.

Acquisitions

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

Workflow guidelines

How Alliances manages work in GitLab - Alliances Group

How Alliances mesures revenue impact in GitLab through co-selling

Labels for Alliance Pillar

• Co-Innovation :
• Co-Marketing :
• Co-Selling :
• Marketplace :
• Public Sector :

Priority: Alliance - Priority : <P#>

• P0 - Immediate revenue impacting and time sensitive.
• P1 - Strategic to short term alliance goals
• P2 - Strategic to long term alliance goals

Status: Alliance - Status : Status

• Backlog - Place holder for future work that will then move to planning phase.
• Planning - Ideation phase, still creating a MVC plan internally or cross functional teams
• WIP - Currently in progress and active priority to complete.
• Blocked - Stalled work item with no definite workaround yet
• Awaiting Feedback - Stalled work item awaiting for contribution from internal or external stakeholders.
• Delivered - Related work has been completed and awaiting formal acceptance or close of issue.

OKR Goals: Alliance - OKR : OKR FY'YY Q#

Internal Process

• 1 Epic as SST for all meta issues and high level issues
• Labels above only apply to our project

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.

For Context of the Partnerships we are working on please reference : GitLab Partner Dashboard

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

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 partners and potential partners request free licenses to develop integrations with GitLab most need a self-managed license key. To generate a license follow the steps below according to the type of license.

Self-managed

1. Inquire with the partner how many developer seats will be necessary.
2. Open an issue using the License Issue template.
3. Specify the license is for Ultimate (unless requested otherwise).
4. Specify the term to be 6 months.
5. Specify the appropriate number of seats; if unknown set at 5. The total number of seats should not exceed 10.
6. Provide any relevant details about the purpose and use of the license in the issue.

GitLab.com

1. Inquire with the partner how many developer seats will be necessary.
2. Create an issue under the internal-requests project 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.