Dev Subpage

Credit: https://about.gitlab.com/direction/dev/#manage

Overview

⁠

Loading…⁠

⁠

The Dev Section is made up of the Manage, Plan, and Create stages of the DevOps lifecycle. The scope for the Dev section is wide and encompasses a number of analyst categories including Value Stream Management, Project Portfolio Management, Enterprise Agile Planning Tools, Source Code Management, IDEs, Design Management, and even ITSM. It is difficult to truly estimate TAM for the Dev Section, as our scope includes so many components from various industries, but research from IDC indicates the estimated TAM in 2019 is roughly ~$3B, growing to ~$7.5B in 2023 (26.5% CAGR). Alternatively, the Dev product management team has conducted a bottoms up Total Addressable and Serviceable Addressable market analysis which estimates GitLab's SAM for Dev to be 19.5B in 2019 growing to 27.5B in 2023.

Based on DevOps tool revenue at the end of 2018 and comparing to GitLab annual recurring revenue at the end of FY20 Q3, our estimated market share is approximately 1.5% based on revenue. (Note: this assumes we can attribute 100% of GitLab revenue to Dev stages.) Market share based on source code management is somewhere in the 30% range.

Nearly half of organizations still have not adopted DevOps methodologies, despite data that indicates far higher revenue growth for organizations that do so. Migrating a code base to a modern, Git-backed source control platform like GitLab can often be the first step in a DevOps transformation. As such, we must provide industry-leading solutions in source code and code review, as this is not only the entry into DevOps for our customers, but typically the entry into the GitLab platform. Once a user has begun utilizing repositories and code review features like Merge Requests, they often move “left” and “right” to explore and utilize other capabilities in GitLab, such as CI and project management features.

Per our Stage Monthly Active User data we know that Create has the highest usage amongst GitLab stages, alongside Manage, which all users in groups uses. As such, these stages must focus on security fixes, bug fixes, performance improvements, UX improvements, and depth more than other areas of GitLab. Plan, while introduced in 2011 with the release of issue tracking, still falls far behind market leaders who have better experiences for sprint management, portfolio management, roadmapping, and workflows.

Other areas, such as Value Stream Management are nascent to both GitLab and the market, and will require more time devoted to executing problem and solution validation discovery.

Over the next year, Dev will require focus on both breadth and depth activities, and each stage will require significant investment to accelerate the delivery of security issues, performance issues, and direction items.

Within each stage, the listed items in the FY21 plan are in order of priority.

The top priority for each stage is:

Manage: Enterprise Readiness

Plan: Importing from Jira

Create: Gitaly Clusters for fault tolerance and performance

FY21 Plan: What’s Next for Dev

Enterprise readiness: GitLab must be seen as a platform that enterprises can use out of the box for both GitLab.com and self-managed deployments. We're doing this by focusing on improvements in several key areas:

Enterprise-grade authentication and authorization. Critical for large organizations managing users at scale, we're focused on investing in SAML SSO that works across a range of identity providers and automates member management.

Providing consistent views on instance activity. We'll improve

audit management⁠

to a lovable category and introduce dashboarding and alerting to help tell your compliance story to stakeholders. We'll also solve a pronounced need for fine-grained member permissions.

Create a consistent experience between self-managed customers and GitLab.com customers. Currently, these experiences differ, mainly from the reason that the code base running the two deployment types is the same. This means as a self-managed customer, you have control at the instance level. Conversely, for GitLab.com, the highest level of access is at the group level. Much of our recent audit management work has been to ensure consistency for audit tracking at the group level, but we will continue to invest here to make sure the experience is the same for both deployment types.

Provide isolation of groups inside of GitLab. For some organizations, there must be safeguards in place to prevent users from viewing or accessing other groups and projects. Providing isolation of group managed accounts will help organizations better manage their GitLab usage by providing a more "instance-like" experience at the group level.

Improving tools that help compliance-minded organizations thrive. GitLab makes it easy to contribute, but administrators should have comprehensive control to establish, enforce, and provide evidence of organizational policies that are part of a compliance program or framework. Our

compliance vision⁠

will evolve to introduce features that enable organizations to rely on GitLab for the enforcement and documentation of

policies⁠

they set. You can hear more about our direction on compliance here:

⁠

People Operations⁠

⁠

Overview

FY21 Plan: What’s Next for Dev

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.