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.
Interested in a GitLab Technology Partnership?
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 the Alliances team.
Partner definitions
Technology partners
Primary monetization is through the sales of software licensing/support that integrates with GitLab
Platform Partners. These are critical partnerships and will be prioritized to support our customer demands.
Cloud partners. For example AWS, Google, Azure, Digital Ocean, IBM
Kubernetes partners: Red Hat, Rancher, VMWare, Mesosphere, Cisco, NetApp, etc.
Outbound: There is a core set of priority outbound partnerships we will maintain and focus on.
Those are: GitHub, BitBucket, Jira and Jenkins
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.
Sell-to Partners - Most of CNCF and majority of tech partners.
Primary monetization is through the sale of services. This can be a one-time implementation, ongoing support, or outsourcing.
Global Systems Integrators - have a large global workforce and can deliver on almost any customer need. Examples: Accenture, Deloitte, TCS, Wipro
Regional Systems Integrators - large workforce but with single continental focus and a more limited offering of services. Examples: CI&T, Slalom
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 - CloudReach, Flux7
Managed Service Providers - provide ongoing support for solutions/applications. Examples: Rackspace
VAR/VAD (Value Added Reseller or Distributor) - Channel services including resale, implementation, contracting, support, financing etc.
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.
Training Partners - focus on training companies, teams and often certifications
Criteria for successful partnerships
Exposure - Partnerships which generate more exposure to new segments of audiences, integrations are a good example.
Product usage familiarity - more people using GitLab but not necessarily installing their own instance (GitLab.com), open source projects as an example.
Adoption - partnerships attracting more people to adopt GitLab for their own instance. Upstream and downstream partners help here.
Revenue - Revenue generating partnerships. Users come first but focus on revenue has ensured we have the revenue for sustainable growth.
Strategic - partners we find will add strategic value to our long term positioning and often around competitive situations.
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
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
Deprecated
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
Gdocs which are shared with the partners should be set to "Anyone with the link". Internal Gdocs should be set to "GitLab".
The following structure should be used for Gdoc names: "PARTNER NAME and GitLab".
Alliance folder contain current work with partners and are kept by Partner name
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:
Create issue with the following details on the campaign:
Campaign topic
Timeline
Budget
Marketing targets
Budget spend approval and acknowledgement from AWS/Google/etc
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
Inquire with the partner how many developer seats will be necessary.
