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.
GitLab’s 10-year product vision is inspired by our mission to make it so that everyone can contribute. Today GitLab is the DevOps Platform, empowering organizations to maximize the overall return on software development by delivering software faster and efficiently, while strengthening security and compliance. We believe our DevOps platform vision is shared by market analysts who have coined it the Value Stream Delivery Platform market. Over the next ten years, our vision is to expand GitLab in the following ways.
First, we expect to continue rapidly maturing our DevOps platform so that GitLab is able to replace any DevOps point solution. To replace any DevOps solution will require most of our categories to be lovable, which is likely a 10 year journey. To ensure rapid progress, we have a 3-year goal to have 50% of our categories at lovable maturity by the end of 2023, and this three year product strategy articulates our current focus. Once we achieve that goal, there will still be more work to do, but having half our categories lovable will mean most DevOps tools are replaceable by GitLab.
Second, we expect GitLab to expand its DevOps platform to provide similar support for ModelOps and DataOps. Over time, data and machine learning/AI models will increasingly power software experiences. Our customers will need an ability to manage data and its associated ML/AI models in a similar fashion to software projects. We endeavor to support data scientists and data engineers just as we support software developers today, by enabling rapid development, testing, production deployment, and monitoring of data models. We would also expect to automate handling of product usage data collection, GDPR compliance of data under management, cookie and privacy management, experimentation tools, A/B testing, etc.
Third, we expect GitLab to become a creation platform for all digital content. This will require us to expand beyond traditional software development. Possible new digital content creation formats we could support include low code/no code development, design creation, and other creative media like music and movies. It would also likely require enhanced content management to better enable customers to create great digital experiences for their users.
We execute on our vision rapidly and efficiently by leveraging the best practices of 100,000 organizations co-developing the DevOps platform of their dreams. We take a seed then nurture approach to maturing our product surface area over time, all the while, focusing on customer results. We leverage sensing mechanisms and product usage data to make decisions about where to increase or decrease investment. You can read more about the principles that guide our prioritization and product thinking in our product handbook.
The following 6-minute video gives a quick overview into where the GitLab product is headed the next few years.
GitLab competes in a large market space, with a TAM estimated at ~$18B in 2024. GitLab has recently surpassed the $150M 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 codebase from our users.
GitLab CEO and Product leadership discuss the Product Strategy in detail during a CEO Handbook Learning Session.
Every product should have a single job that it strives to do. At GitLab we use the Jobs to be Done (JTBD) framework. A JTBD is the reason why people employ a product. GitLab's overarching Job to be Done is:
When we are building software as a team, we want to get from ideas to production with quality, reliability, and security quickly and within budget, so that our organization can deliver promised value and achieve our business outcomes.
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.
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 lot of other roles 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.
Every year at GitLab, we choose some specific areas of emphasis to help guide the teams on the directional themes that we want to accentuate in our product. This section is used to highlight that emphasis. It is not a comprehensive list of everything we plan to do this year. Direction for each stage and category can be found at the respective direction pages. We are not asking the teams to deviate from their core mission.
Many teams will see themselves contributing to these areas of emphasis directly. The other teams will continue to execute on their mission - that is also important.
The themes are to help facilitate cross-team collaboration when invariably teams working on the 1-year themes may need to collaborate with others. Our guidance is: if any team approaches you to prioritize something that is thematic for this year, consider that as a higher priority than you would normally - as it is in service of the broader product-wide goal that we, as a company, have deemed important to accomplish this year.
For FY23, the 3 key product themes we are focused on are:
Primary Leading Performance Indicator:
Secondary Lagging Performance Indicator:
We continue to see massive growth opportunities on SaaS. We made a lot of great progress with GitLab Hosted First including embracing error-budgets.
We will continue this theme into FY23.
Performance Indicator: UX Scorecard improvements for key workflows
In FY22 we had a broad effort to improve usability. We accomplished a lot. We also learned that we need a concerted effort to improve key workflows as they are often complex, require cross-functional alignment and drive a majority of usability feedback about the product. For FY23 we aim to provide:
Performance Indicator: Double current Ops Section CMAU by end of Fiscal Year 2023 to 3.6M
CI is one of the first use cases customers experience that provides them value and an appreciation of the potential of a single application for the DevOps lifecycle. Our early lead in CI/CD is being followed by other deployment focused platforms which are expanding into CI. We will extend our CI/CD leadership by:
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 Zeitgeist 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 a 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 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 four 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:
We expect GitLab to continue to grow, and we have several ideas for possible future stages
To make sure our goals are clearly defined and aligned throughout the organization, we make use of OKRs (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 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.
If you are interested in contributing to specific, priority key technical challenges, we maintain the following list of priority issues and epics. Feel free to add a comment expressing your interest in these issues and epics to determine the best place to contribute.
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 Development Department merge request rate 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:
We have more details about our plans on the Mobile direction page. Some of our older thoughts are collected in the original epic.
Right now, GitLab doesn't use any ML/AI technologies in production features, but we expect to use them in the near future for several types of problems. This is the focus of our new Learn stage.
GitLab consistently strives to deliver a cohesive experience that enables workflows that span the DevOps loop. We have a number of existing capabilities and planned improvements that do just that:
We set big hairy audacious goals that may take a long time to deliver. Because of this, we leverage Single-Engineer 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.