The Enablement section is responsible for the features and tools our customers use to operate GitLab at all scales. Enablement supports customers from initial deployment of GitLab to ongoing operation, as well as integration of other services in use by an organization.
The Enablement section is made up of one eponymous non-DevOps stage, Enablement, and seven groups:
Provide users with a consistently great experience and achieve customer business requirements by making GitLab easy to deploy, operate, scale, and integrate.
There is no traditional addressable market for Enablement due to its foundational, GitLab-specific nature. Every GitLab user is directly impacted, however, by the work Enablement delivers.
In light of this, we think of Enablement's addressable market as that of GitLab's larger addressable market. By working to ensure we can meet the operational, compliance, and integration requirements of GitLab's customers, we can capture increasingly larger percentages of GitLab's total addressable market opportunity. We presently don't capture reasons for loss with sufficient granularity to determine when an Enablement related concern was the primary driver, making the determination of the precise missed opportunity challenging.
There are two primary segments within the broader "GitLab" market: organizations that would like to operate their own GitLab instances (self-managed) and those who prefer to utilize a SaaS service (GitLab.com). It is important to note that GitLab.com utilizes the same code base and release artifacts as our other customers, and we document any non-default configurations, it is simply the largest deployment of GitLab.
Today, we are able to capture most of the self-managed segment with our mature linux packages and more recently our Kubernetes Helm chart. A proof point is GitLab's two-thirds market share in the self-managed Git market. While this speaks to the competitiveness of GitLab's overall product, a critical enabling factor is the high-quality, flexible, and scalable software and operational tools.
While we are able to meet the requirements of most organizations, there are some occasional unmet needs:
GitLab's market share in the SaaS segment is significantly smaller than self-managed at approximately 8%. While some of the disparity is due to the network effects of GitHub.com's strong open-source community, Bitbucket's 30% market share illustrates the significant upside present in this segment for us.
There are a larger number of unmet needs on GitLab.com than self-managed, which primarily fall into two buckets:
From an Enablement perspective, much of our work is on improving the performance and reliability of GitLab.com, although there are some feature gaps we are working to address, like enablement of Advanced Global Search.
The existing team members and open vacancies for the Enablment section can be found in the links below:
Historical staffing levels for Enablement can be found in our hiring charts.
Due to the GitLab-specific nature of Enablement, adoption is primarily meaningful when seen as a percentage of GitLab instances.
Note: Links are to internal Periscope dashboards. Additional details can be found on internal Enablement topic.
As noted above, GitLab's competitive position is a tale of two cities. We are the leading self-managed Git solution but are a distant third in SaaS. Our success in self-managed has driven the majority of the company's growth, however it is at risk of being disrupted by growing trends in the market.
The IDC DevOps 2019 report is illustrative of this challenge, with the top two preferences for new IT infrastructure projects being community-supported open source software (OSS) and SaaS, respectively. Commercially supported OSS is fourth with under 15% share. While we have been successfully managing the open-core nature of GitLab, we are at risk of being disrupted from below by other OSS projects; for example, ones that may be lighter-weight and more focused in specific stages. GitLab.com, our SaaS service, represents both our biggest opportunity and risk depending on our execution.
We need to achieve what could be considered opposing goals: making GitLab efficient and easy to run at small scales and improving the scalability and reliability at web-scale.
In three years we expect:
As a result, in three years, GitLab will:
Deploying and maintaining GitLab should be as frictionless as possible for organizations of all sizes. This is critical for GitLab at multiple points in the customer journey.
GitLab starts as a personal or side project at many organizations, representing an important driver of initial adoption and awareness. Delighting future champions by providing a thoughtfully designed out-of-the-box experience that runs well on hardware they have lying around pays dividends in future growth.
Once a company is ready to adopt GitLab enterprise wide, it is similarly important to ensure the GitLab instance is set up for success with minimal effort. Consider our 5,000-user reference architecture which recommends setting up at minimum 27 different instances, and that our GitLab configuration file is over 2,000 lines long. This is a significant upfront investment to ask a company to make, prior to seeing value returned. It can also be error prone given the complexity, with the only practical solution to ongoing management being infrastructure as code, which requires further investment.
Day 2 operations like backups, scaling, and upgrades are equally important. GitLab is a business critical application, so events like upgrades need to be routine and seamless. The easier we make it for our customers to upgrade, the faster our users will be able to leverage our new features and provide feedback. Currently it takes 3 months after release for half of our users to feel the impact of our work.
By reducing the deployment/operating costs and packaging best practices, we will see the following benefits:
As customers roll out and adopt additional stages of GitLab to realize the benefits of a single application, the service availability and performance requirements increase as well. Additional departments within the business utilize the service on a daily basis to accomplish their jobs, such as design, security, and operations teams. People around the world collaborate together. Work that may have been done manually is now automated using CI/CD, including delivering the latest update or bug fix to their customer facing application/website. For these reasons, GitLab is increasingly being identified as a business-critical application with attendant requirements. It is therefore important for GitLab to be a consistently reliable, performant service for all users to fulfill its potential.
By providing market-leading reliability and performance, we will see the following benefits:
Organizations in regulated industries, the public sector, and large enterprises often have a variety of standards and processes that they must adhere to.
In the public sector, there are standards like NIST 800-53 and FedRAMP. For companies handling credit card transactions, there is PCI DSS. These are just two examples. While some of these standards are not directly aimed at services like GitLab, they have a broad reach, and the requirements generally cannot be waived, as the penalties for non-compliance can be severe. Many enterprises have also developed their own internally driven processes and policies that can be important to support, rather than requiring changes prior to the adoption of GitLab.
For published standards, it is important that GitLab offers the required features and configuration to enable our customers to be in compliance. This includes changes to our code base; for example, fully encrypting all traffic between GitLab nodes, selection of specific cryptographic modules, high availability, and disaster recovery, among others. Additionally, some standards like FedRAMP can also impact the operational and governance processes of GitLab.com. The more that we can do to be compliant out of the box or provide documentation on recommended settings, the less work our customers will be required to do during evaluation and implementation.
Enterprise-specific standards are also important to support with as little friction as possible. One of the common ways enterprises achieve these is by ensuring their new services plug into existing tools, processes, and workflows. While we try to build the required settings/features into GitLab directly, these workflows and tools can be highly specific to a given enterprise, with our API being frequently relied upon instead. Some examples we encounter include user provisioning, custom analytics and reporting, and auditing. Providing a high quality API with easy-to-use client libraries can speed the integration work and reduce the effort required.
By enabling our customers to meet their compliance requirements and reducing the required effort, we will see the following benefits:
As an open source project and single application for the whole DevOps lifecycle, an elevated contributor experience is critical.
Two of the highest priorities in the company are growing our open source community and maintaining the velocity of the project. An improved contributor experience has a direct impact on both of these metrics by reducing initial friction and ensuring seasoned GitLab employees can quickly develop and review changes. For example, consider the time and effort required to set up your development environment (GDK) to contribute or review a change to AutoDevOps or Geo. As the wider GitLab community grows, along with the surface area of the product, the value of a great contributor experience will have compounding returns.
As noted above, GitLab plays a central role in an organization's software engineering process. Currently, there are 34 services directly integrated, with many of these originally contributed by members of the community and many more through our API. These integrations are important to providing a smooth and productive workflow, especially at larger organizations where there may not be a single standard toolchain. For example, it is not uncommon for some portions of a company to use GitLab Issues and other parts to use Jira. If we did not have Jira integration, these users would be less productive, and our growth within this organization may be constrained. By making it easier to contribute an integration to GitLab, we can increase our coverage area of commonly requested integrations, whether it's from a community member or third-party product.
By providing an elevated contributor experience, we will see the following benefits:
Over the next 12 months, each group in the Enablement section will play an integral part in this strategy.
Please see the categories page for a more detailed look at Enablements's plan by exploring
Strategy links in areas of interest.
You can read the Distribution group plan on the Distribution Direction page.
You can read the Geo group plan on the Geo Direction page.
You can read the Ecosystem group plan on the Ecosystem Direction page.
You can read the Search group plan on the Search Direction page.