The following page contains information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
This page introduces the GitLab product vision, where we're headed over the next few years, and our plan to deliver over the next year.
Our vision is to replace DevOps toolchains with a
single application that is
pre-configured to work by default across the entire DevOps lifecycle.
Many organizations are in the midst of evolving from classic development
paradigms, to DevOps. They want faster cycle time, higher quality outcomes, and
less risk. Every organization, large or small, deserves to operate at peak
efficiency. GitLab’s job is to help those companies along, accelerate their
evolution, and provide optimized tooling once they get there. We do this by
leveraging the best practices of 100,000 organizations co-developing the DevOps
platform of their dreams. We deliver
Seed then nurture, and
mature product surface area over time, all the while,
focusing on customer results. We’re informed by data, and ROI-driven; balancing
that with fleshing out the breadth of our vision as quickly as possible so
people everywhere understand where we’re going, what’s possible, and how they
can contribute. We believe in the emergent benefits of a
single application for the entire
You can read more about the principles that guide our prioritization process in
our product handbook. You can also read
our GitLab as a Product section which
describes the principles that are used to guide GitLab itself forward.
It's natural for technology markets go through stages as they mature: when a young technology is first becoming popular, there is an explosion of tools to support it. New technologies have rough edges that make them difficult to use, and early tools tend to center around adoption of the new paradigm. Once the technology matures, consolidation is a natural part of the life cycle. GitLab is in a fantastic position to be ahead of the curve on consolidation, but it's a position we need to actively defend as competitors start to bring more legitimately integrated products to market.
DevOps is a broad space with a lot of complexity. To manage this within GitLab,
we break down the DevOps lifecycle
into a few different sections, each with its own direction page you can review.
GitLab competes in a large market space, with a TAM estimated at $14B in 2019, rising to $71B in 2025 as we better serve additional personas and use cases. GitLab has impressive revenue growth, recently surpassing the $100M ARR milestone, with unusually high revenue growth and retention rates. GitLab is uniquely positioned in the market with a vision to offer a single application for the entire DevOps lifecycle. GitLab competes across numerous market segments and aims to deliver value in 80+ market categories. GitLab’s product vision is uniquely ambitious, as we were the first DevOps player to take a single application approach. From idea to production, GitLab helps teams improve cycle time from weeks to minutes, reduce development process costs, and enable a faster time to market while increasing developer productivity. With software “eating the world”, this is widely viewed as a mission-critical value proposition for customers. We also have a number of tailwinds in the form of cloud adoption, Kubernetes adoption, and DevOps tool consolidation, which are helping fuel our rapid growth. Finally, GitLab has an open source community and distribution model, which has exposed the value of GitLab to millions of developers, and has sped up the maturation of our product through more than 200 monthly improvements to the GitLab code base from our users.
Tension between Breadth and Depth: GitLab’s ambitious single application product vision means we need to build out feature function value across a very large surface area. Our challenge is to drive the right balance between breadth and depth in our product experience. In recent years, we have optimized for breadth. To win and retain more sophisticated enterprise customers, we need to effectively seed then nurture in areas of the product that generate usage and revenue. With so much product surface area to deliver in a single application experience, it is a big UX challenge to keep the experience simple, consistent, and seamless between DevOps phases.
GitLab.com and Self-Managed: Another challenge we face is the balance between our self-managed and GitLab.com offerings. GitLab's early paying customers were more interested in self-managed and the majority of our customers use this offering today. As a result, we focused heavily on delivering a great self-managed customer experience. However, as the market shifts toward cloud adoption, we are seeing an increasing demand for our GitLab.com offering. We now need to rapidly meet the same enterprise-grade security, reliability, and performance expectations our paying customers have come to expect from self-managed in our SaaS (.com offering).
Wide Customer Profile: We also serve a wide range of customers, from individual contributor developers to large enterprises, across all vertical markets. This range of deployment options and customer sizes makes our business complex, and makes it hard to optimize the customer experience for all customer sizes. The past few years we have prioritized enabling our direct sales channel, but in the process have not focused enough on great customer experiences around self-service purchase workflows, onboarding, and cross-stage adoption.
Competition: Finally, we have formidable competition from much larger companies, including Microsoft, Atlassian, and Synopsys, to name a few. Microsoft is starting to mimic our single application positioning, and while behind us in the journey, have substantial resources to dedicate to competing with GitLab.
As outlined in this user journey, the most important additional stages for customers to adopt are Create to Verify, and Verify to Release, as each of these adoption steps open up three additional stages to users. Our goal is to have 100M TMAU by the end of 2023.
Deliver cross-stage value: GitLab’s primary point of differentiation is our single application approach. As we continue to drive value in any given stage or category, our first instinct should be to connect that feature or product experience to other parts of the GitLab product. These cross-stage connections will drive differentiated customer value, and will be impossible for point product competitors to imitate. Recognizing this opportunity, we have grown our R&D organization significantly over the past two years, and plan to invest an outsized amount on R&D for the next 2-3 years to extend our lead in executing against the single application product vision.
Leverage open source to rapidly achieve multi-stage product adoption. Our vision is to deliver a single application for the entire DevOps lifecycle. To achieve this ambitious vision more quickly, we will leverage our powerful open source community. Each stage should have a clear strategy for tiering the value of the stage. When stages are early in maturity, we will bias toward including as much functionality in our Core open source version as possible, to drive more rapid adoption and greater community contributions, which will help us mature new stages faster. Once stage adoption is achieved, we can then layer on additional value in paid tiers to encourage upgrades.
Shift to depth in core product areas: We want to ensure the core product usage experience is great, which will lead to more paying customers and improved customer retention. We intend to maintain our market-leading depth in stages with lovable categories, which currently are Verify (Continuous Integration) and Create (Source Code Management and Code Review). Beyond that, we will endeavor to rapidly mature our offering to lovable in Plan (3rd most used stage), Release (4th most used stage), and Secure (important element of our Ultimate/Gold tier). Our goal is to have 50% of our categories at lovable maturity by the end of 2023.
Optimize for SaaS and self-service: We have millions of overall users, hundreds of thousands of paying users, and tens of thousands of paying organizations. Given this volume of adoption, it’s essential that we assume users will need to serve themselves to buy & use GitLab. This will enable us to shift a higher percentage of our customer base to a lower cost self-service buying channel, reducing sales & support costs, and improving our customer acquisition costs. It should also lead to higher customer satisfaction overall, as assuming customers will buy & use GitLab without assistance from sales & support will force us to keep our UX quality bar very high. We should also assume that over time a majority of our customers will prefer a SaaS delivery model, so our SaaS offering needs to have enterprise-grade security, availability, and performance. We must also ensure feature parity between self-managed and GitLab.com and that customers have an easy migration path from self-managed to GitLab.com.
Personas are the people we design for. We’ve started down the path of having developers, security professionals, and operations professionals as first-class citizens; letting each person have a unique experience tailored to their needs. We want GitLab to be the main interface for all of these people. Show up at work, start your day, and load up GitLab. And that’s already happening.
But there are a ton of people involved with the development and delivery of software. That is the ultimate GitLab goal - where everyone involved with software development and delivery uses a single application so they are on the same page with the rest of their team. We are rapidly expanding our user experience for Designers, Compliance Managers, Product Managers, and Release Managers. We’ll also be expanding to the business side, with Executive visibility and reporting. While we’re still calling it DevOps, we’re really expanding the definition of DevOps, and delivering it all as a single application.
For 2020, we have 3 key product themes we are focused on:
Enterprise Readiness: Make it easy for large enterprise customers to rapidly adopt and get value from GitLab. Relevant product direction themes include:
World-Class Security for DevSecOps: Deliver fully integrated security experience, allowing customers to adapt security testing and processes to developers (and not the other way around). Relevant product direction themes include:
GitLab is not immune to disruption. In some ways, it is a sign of success that GitLab is now at a scale where we have to think about low-end disruption. Arguably, a few years ago, GitLab was a low-end disruptor.
Low-end disruption refers to businesses that come in at the bottom of the market and serve customers in a way that is "good enough." These are generally the lower profit markets for the incumbent and thus, when these new businesses enter, the incumbents move further "upstream." In other words, they put their focus on where the greater profit margins are.
Our perspective is that low-end disruption is an additional and critical sensing mechanism. This is especially true for the DevOps market. We look at the following attributes to figure out if a low end disruption has anything close to potential product-market resonance. This list is an adaptation of the Product Zietgest Fit.
Builder Enthusiasm: Are most talented, hardest working or most-in-demand people - the engineers, the developers - so intrigued by the approach that they are working on it, excited by it, and trying to make it a thing? If that is the case then there is a good chance that they will eventually make it happen, moving beyond the fringes to the mainstream. Number of stars, forks and contributions in the repo are some metrics to look for here.
Despite Test: When people are using a product despite the fact that it’s not the best thing out there, or, in some cases, that it’s straight-up terrible, it’s a great sign. It shows that the product has a line into something emotional, not solely functional. Wanted, not just needed. In the early days, these products can often feel misunderstood or controversial. At first blush, the conceit may even raise a few eyebrows. But to the people who have been working on those products, they’re so clearly elegant, if temporarily imperfect, solutions to big and important problems that they seem almost obvious once they recognize it. Google Trends, posts on hackernews are some things to monitor here.
T-shirt test: If people with no connection to the company are wearing their t-shirts or putting their stickers on their laptops or wearing their socks, that desire to associate with the idea indicates as much a movement as a product.
A reason low-end disruptors are able to enter the market is that the feature-absorption by users is lower than the feature-velocity of the established vendor. To address this we are focused on working-by-default configuration principle.
As we add new categories and stages to GitLab, some areas of the product will be deeper and more mature than others. We publish a
list of the categories, what we think their maturity levels are, and our plans to improve on our maturity page.
We try to prevent maintaining functionality that is language or platform
specific because they slow down our ability to get results. Examples of how we
handle it instead are:
We don't make native mobile clients, we make sure our mobile web pages are great.
We don't make native clients for desktop operating systems, people can use Tower and for example GitLab was the first to have merge conflict resolution in our web applications.
During a presentation of Kubernetes Brendan Burns talks about the 4 Ops layers
at the 2:00 mark:
GitLab helps you mainly with application ops. And where needed we also allow you
to monitor clusters and link them to application environments. But we intend to
use vanilla Kubernetes instead of something specific to GitLab.
Also outside our scope are products that are not specific to developing,
securing, or operating applications and digital products.
Identity management: Okta and Duo, you use this mainly with SaaS applications
you don't develop, secure, or operate.
SaaS integration: Zapier and IFTTT
In scope are things that are not mainly for SaaS applications:
Network security, since it overlaps with application security to some extent.
Security information and event management (SIEM), since that measures
applications and network.
To make sure our goals are clearly defined and aligned throughout the
organization, we make use of OKR's (Objectives and Key Results). Our quarterly Objectives and Key Results
are publicly viewable.
GitLab's direction is determined by GitLab the company, and the code that is
sent by our contributors. We continually
merge code to be released in the next version. Contributing is the best way to
get a feature you want included.
At GitLab, we strive to be ambitious,
maintain a strong sense of urgency, and set aspirational targets with every
release. The direction items we highlight in our kickoff
are a reflection of this ambitious planning. When it comes to execution we aim
velocity over predictability.
This way we optimize our planning time to focus on the top of the queue and
deliver things fast. We schedule 100% of what we can accomplish based on past throughput
and availability factors (vacation, contribute, etc.).
Note that we often move things around, do things that are not listed, and cancel
things that are listed.
Developing and delivering mobile apps with GitLab is a critical capability. Many technology companies are now managing a fleet of mobile applications, and being able to effectively build, package, test, and deploy this code in an efficient, effective way is a competitive advantage that cannot be understated. GitLab is taking improvements in this area seriously, with a unified vision across several of our DevOps stages.
Mobile focus areas
There are several stages involved in delivering a comprehensive, quality mobile development experience at GitLab. These include, but are not necessarily limited to the following:
Manage: Comprehensive templates to get started quickly.
Create: Web IDE features that allow you to easily manage the kinds of code and artifacts you work with during mobile development.
Verify: Runners for macOS, Linux-based builds for iOS.
Package: Build archives for mobile applications.
Release: Review Apps for mobile development, code signing and publishing workflows to TestFlight or other distribution models.
Secure: Security scanning built directly into CI/CD pipelines supporting a variety of mobile coding languages.
There are a few important issues you can check out to see where we're headed. We are collecting these in gitlab-org&769.
ML/AI at GitLab
Machine learning (ML) through neural networks is a really great tool to solve hard to define, dynamic problems.
Right now, GitLab doesn't use any machine learning technologies, but we expect to use them in the near future
for several types of problems.
Signal detection is very hard in a noisy environment. GitLab intends to use
ML to warn users of any signals that stand out against the background noise in several features:
security scans, notifying the user of stand-out warnings or changes
error rates and log output, allowing you to rollback / automatically rollback a change if the network notices aberrant behavior
Automatically categorizing and labelling is risky. Modern models tend to overfit, e.g. resulting
in issues with too many labels. However, similar models can be used very well in combination
with human interaction in the form of recommendation engines.
Identifying anomalous activity within audit events systems can be both challenging and valuable. This identification is difficult because audit events are raw, objective data points and must be interpreted against an organization's company policies. Knowing about anomalous behavior is valuable because it can allow GitLab administrators and group owners to proactively manage undesireable events.
This a difficult problem to solve, but can help to drastically reduce the overhead of managing risk within a GitLab environment.
We set big hairy audacious goals
that may take a long time to deliver. Because of this, we leverage single-person groups to adequately explore a new space, build rapid Interactions, and
grow a community around the problem space. Below is a list of areas where we are putting some longer