The following page may contain 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 DevOps lifecycle.
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.
Product Vision, Strategy, and 2020 Plan slides
Continuing apace after Microsoft's 2018 acquisition of GitHub, the trend to consolidate DevOps companies seems here to stay. In January 2019, Travis CI was acquired by Idera, and in February 2019 we saw Shippable acquired by JFrog. Atlassian and GitHub now both bundle CI/CD with SCM, alongside their ever-growing related suite of products. In January 2020, CollabNet acquired XebiaLabs to build out their version of a comprehensive DevOps solution.
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.
We are investing in the following manner across each stage.
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.
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.
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 2021, the 3 key product themes we are focused on are:
Some key goals here are
Performance Indicator: Increase in Paid GMAU for gitlab.com
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.
Clayton Christensen defines low-end-disruption as follows:
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.
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 strive to be the best product in the market and to be truly lovable. As the market, customer's needs, competitive landscape and technology change, we should expect our maturities to also change, including changing to a lower maturity rating. By embracing a focus on improvement and low level of shame, we encourage moving a maturity down. This is a strong indicator that we are realists about our product with an eye on achieving the best results for our customers.
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:
Outside our scope are Kubernetes and everything it depends on:
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.
In scope are things that are not mainly for SaaS applications:
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.
On our issue tracker for CE and EE, many requests are made for features and changes to GitLab. Issues with the Accepting Merge Requests label are pre-approved as something we're willing to add to GitLab. Of course, before any code is merged it still has to meet our contribution acceptance criteria.
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 for 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.).
See our product handbook on how we prioritize.
On our releases page you can find an overview of the most important features of recent releases and links to the blog posts for each release.
GitLab releases a new version every single month on the 22nd. You can find the major planned features for upcoming releases on our upcoming releases page or see the upcoming features for paid tiers.
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.
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:
There are a few important issues you can check out to see where we're headed. We are collecting these in gitlab-org&769.
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.
Using technology like Kubeflow or CML.
Demonstration projects using GitLab CI and ML:
More information can be found in the MLOps with GitLab overview.
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:
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.
Because of their great ability to recognize patterns, neural networks are an excellent tool to help with scaling, and anticipating needs. In GitLab, we can imagine:
Similar to DeepScan.
Similar to Sourcegraph although we now have code intelligence in GitLab.
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 term bets.
