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.
GitLab delivers value by enabling organizations to build better software, faster. The most important persona for the Enablement group is therefore the broader userbase of GitLab, rather than its administrators. We need to provide the software necessary to make it easy for an administrator to provide a delightful and productive GitLab experience to their users.
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 enterprise customers, we can capture increasingly larger percentages of GitLab's total addressable market opportunity. While 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, these improvements will have a positive impact on our ability to attract and retain customers in the enterprise segment.
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 estimated that SaaS is the larger segment, with growth continuing to outpace self-managed.
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, as opposed to other products in the market.
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.
/install/) and container image represent about 90% of all instances, with Source making up 8% and the cloud-native Kubernetes Helm chart 1%.
It is important to note that these statistics include the whole installed base, rather than incremental changes, which would be more sensitive to leading indicators.
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.
In 2020, the Distribution team will focus on several main themes:
You can learn more about Distribution group plans on the Distribution Direction page.
You can read complete the Geo group plan on the Geo Direction page.
In 2020, the Geo Group will focus on making substantial improvements to the Disaster Recovery Category. Currently, a planned failover requires around 10 preflight actions plus 6-8 additional steps, which each contain several more commands and we aim to reduce the number of steps significantly, ideally to under five steps (we still need to do some more exploration to see what is possible). Consequently, we are working on making it easier to perform a planned failover; for example, by exploring a read-only maintenance mode, working on making it easier to pause and resume replication, and by streamlining the failover process. We are also working to enable Geo on GitLab.com to ensure the product functions at scale. This also gives us an opportunity to highlight any shortcomings long before those changes are made available in the self-managed release.
Another challenge is that many new GitLab features are initially shipped without Geo support, which means they are initially not part of Geo's Disaster Recovery plan, nor can developers benefit from geo replication. Many of our customers have a reasonable expectation that Geo works "out of the box". In order to address this problem, we are working to accelerate how new data types are added to Geo by building a scalable, self-service geo replication and verification framework. This should make it easier for developers at GitLab and the wider GitLab community to contribute and significantly reduce the current limitations on replication and verification. We also plan to make Geo easier to install and use. At this moment, installing Geo requires more than 70 individual steps to be setup, which is cumbersome, time consuming and error prone. For this reason, we are aiming to significantly simplify the installation experience, ideally reducing the required steps to below 10 (we know this is ambitious). We also aim to improve the Geo Administrator Panel so that systems administrators can manage Geo with ease and perform the tasks they need on the UI. For Geo-replication use cases, we will explore how we can improve the overall user experience. Our goal for Geo-replication is to offer the same experience to users, regardless of their location. In the future, we want our users to be able to configure Geo within minutes - not hours. We envision Geo-replication to be fully transparent to users.
Finally, the Geo group is now also responsible for backups and restore and we are going to analyze the requirements needed to improve the current backup system with a likely focus on completeness and performance.
Over 5,000 GitLab installations have more than 300,000 projects using our Jira integration, making it our top priority in this category. The biggest impacts to these customers is the difficulty of managing large numbers of projects, the complexity and lack of granularity in the configuration, and the lack of Development Panel integration for Jira Server users.
Over the next year, the Integrations category will make it easier to manage large numbers of projects via Group and instance level integrations, improve the UX of configuring Jira's integration, and bring support for the GitLab connect app to Jira Server users.
We will also be laying groundwork for improvements to all of our integrations by allowing integrations to work at the Group and Instance level, and developing guides for other companies looking to create integrations.
The API & SDK category will focus on making it easier to integrate with and develop inside of GitLab by establishing a Developer Portal to act a centralized resource for finding developer tools and documentation, establishing usage telemetry for our API and SDKs so we can understand how people are using GitLab as integrators, and continuing to expand and refine our existing APIs.
A key component to better supporting our ecosystem of native client libraries is Reviewing Commuinity Tools that are currently in the wild. As long as the primary way that developers integrate with GitLab is through these libraries, we should carefully work to monitor their state.
We will also continue working to burn down our large backlog of API issues (~900 as of January 2020) and work towards establishing clear best practices for GitLab Stages and Groups that are building their own APIs.
You can read the Ecosystem group plan on the Ecosystem Direction page.
You can read the Search group plan on the Search Direction page.
In 2020, the Search group is focused on three primary priorities: optimizing the cost and load of our Elasticsearch implementation, enabling Advanced Global Search (powered by Elasticsearch) for paid groups on GitLab.com, and improving the user experience.
Optimizing the infrastructure utilization is important for Search, as Elasticsearch can become quite costly to operate in both storage and compute. Reducing the requirements will be appreciated by our customers, but it is also critical enabling work to delivering Search on GitLab.com at scale. We believe we can make a number of optimizations, reducing the impact indexing has on the GitLab server itself, as well as reducing overall index size on Elasticsearch.
Enabling Elasticsearch on GitLab.com brings two primary benefits. First, users of GitLab.com will benefit by being able to perform group-wide searches with lower latency, and higher quality results. Second, we will be able to dogfood our own feature, which we have found to be hugely beneficial in improving its quality and value for all customers. Over the course of our preparing to enable Elasticsearch on GitLab.com, we have already identified a number of shortcomings which we needed to resolve.
Once we have Elasticsearch running well on GitLab.com, we'd like to improve the relevancy of returned results. There is a lot of we can do here, for example leveraging our knowledge of the code base, to prioritize function definitions themselves over the potentially hundreds of places it is called throughout the code base.
The Memory group is focused on improving performance and reducing the memory consumption of GitLab.
The focus of the team will be threefold: foundational improvements like Puma to significantly reduce memory usage, assisting in addressing memory and performance bottlenecks that are affecting customers, as well as driving organization-wide changes to ensure net-new code is performant.
The Database group is focused on improving the scalability, performance, and resilience of the relational database as well as instituting best practices across the wider development organization.
The primary focus of the team in 2020 is to improve the performance and scalability of the Postgres database. Upgrading to PosgreSQL 11 from our current supported version of 9.6 will allow us to take advantage of newer features such as declarative partitioning while also realizing the performance gains included in PostgreSQL 11. As a first iteration, we will implement partitioning for problematic tables, providing additional headroom and performance. Later, we will leverage the partitioning work and roll out sharding of the Postgres instances themselves, to improve isolation and reduce the impact of noisy neighbor situations.
The Infrastructure group has two primary goals in 2020:
A few of the key frameworks and guidance to drive in the short term are:
The Contributor Experience group is a new group for 2020, and will be focusing on a few key themes this year:
The first is improving the usability and reliability of the development environment used to build GitLab, the GitLab Development Kit (GDK). The GDK is essentially required to locally develop and test the changes, before submitting them upstream to GitLab. It is used by nearly all of the product development organization in some form at GitLab, as well as by any of our community contributors and partners. It is therefore critical to optimize this experience for two reasons: productivity gains made through tool enhancements have compounding returns, and by making it easier to get started we can lower the bar to contributing. Our first focus in this area is to do a thorough evaluation of the challenges and opportunities for the GDK, before recommending a path forward. Ideally we could leverage a containerized build environment, to reduce the amount of initial and on-going work required.
In addition to the GDK, the Contributor Experience group is also focused on improving the frontend architecture of GitLab. This includes improving our design system, Pajamas, as well as ensuring that the broader product development organization has the tools required to ensure the GitLab experience is great on mobile.
Choosing to invest in these areas in 2020 means we will choose not to:
The Advanced Global Search in GitLab is a powerful search service that saves you time. Instead of creating duplicate code and wasting time, you can now search for code within other teams that can help your own project. GitLab leverages the search capabilities of Elasticsearch This category is at the "viable" level of maturity.
Install a self-managed instance of GitLab using the Omnibus package. This category is at the "lovable" level of maturity.
Install GitLab in a cloud native environment using Helm. This category is at the "viable" level of maturity.
Geo-replication provides an easily configurable, read-only mirror (we call it a Geo node) of a GitLab installation that is complete, accurate, verifiable and efficient. This category is at the "viable" level of maturity.
Disaster Recovery (DR) helps our customers fulfill their business continuity plans by creating processes that allow the recovery of GitLab following a natural or human-created disaster. This category is at the "minimal" level of maturity.
Integrations are places where the GitLab product connects to features and services from other products. These integrations seek to offer our customers a seamless experience between these products, and range from lightweight features like Slack notifications for projects, to deep and complex integrations with Atlassian JIRA that connect a wide array of functionality throughout the GitLab product.
The GitLab API offers other, non-partner companies or individuals the ability to develop their own integrations with and extensions to the GitLab product. The GitLab SDK will offer a robust set of tools for developers, such as native client libraries to interact with the GitLab API in an array of popular languages, a CLI utility for interactive and scriptable integration with GitLab, and a complete set of documentation that covers all these tools and offers example code and reference applications for education. This category is at the "viable" level of maturity.
GitLab Development Kit (GDK) provides a collection of scripts and other resources to install and manage a GitLab installation for development purposes.
import/exportCloud-Native: use remotely stored