Last Reviewed: 2020-02-07
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 indicates the estimated TAM in 2019 is roughly ~$3B, growing to ~$7.5B in 2023 (26.5% CAGR).
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 Create has the highest usage amongst GitLab stages, alongside Manage, which every user of GitLab 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 are in order of priority. The top priority for each stage is:
Over the next 12 months, each stage in the Dev section will play an integral part in this strategy.
Please see the categories page for a more detailed look at Dev's plan by exploring Strategy links in areas of interest.
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:
Growth driver: Initial purchase
Providing a great import experience: Few instances start from scratch - for most, one of the earliest tasks for a GitLab administrator is importing information from outside the application. We'll invest heavily in a strong import user experience and build bespoke importers for key competitors like Jenkins and Jira. We'll also expand on the capabilities of our existing importers, with a focus on making GitLab.com migration easy with better group import/export capabilities.
Growth driver: Initial purchase
Lowering time to production for our customers: Improvements to productivity and code analytics over the next 12 months will allow our customers to drill down and identify sources of waste in their existing process. Within 12 months, GitLab customers will be able to firmly answer how much their time-to-production metrics have improved. Providing our customers the ability to customize the events to measure between is part of allowing our customers better insight into value stream analytics and lowering time to production.
Growth driver: Retention
Creating a better way to organize individuals in GitLab: We've heard feedback that the existing group and project constructs in GitLab do not provide the right structure for teams of people to achieve the goals of their organizations. Work often spans multiple groups, sub-groups, projects, and sub-projects; where one team of people may need to manage work spanning these organizational constructs within GitLab. Creating the concept of a team inside of GitLab is something that we should tackle in the next year. A team concept in GitLab is useful for a few reasons. First, it allows specific members to be organized into a team, in a way that sub-groups can't today as every member of the top level group in a GitLab instance is automatically part of every sub-group. Second, it would allow teams to be assigned to work, such as issues and MRs, enabling more robust capacity planning and management. Other team concepts such as team boards, workspaces where the team can easily see their assigned work and activity feed, and team analytics are part of our vision for the newly created Spaces group.
Growth driver: Expansion
Importing from Jira without losing required data: In the next 12 months, we will deliver enforced workflows, a better roadmap experience, cumulative flow diagrams, and improvements to issue management and Boards in order to enable a better planning and project management experience. Importing from JIRA without losing required data means just that; GitLab must provide the proper objects, fields, and workflows in order for our customers to view GitLab as a viable replacement for JIRA. Enforced workflows, custom fields, and realtime functionality are likely requirements for this goal to be met, although we are still conducting research with our customers to understand how we can provide substantially more value than Jira so it's easy for organizations to justify the tangible and cognitive overhead for switching tools. The goal is not feature parity, rather value-added differentiation with an effortless migration path.
Growth driver: Expansion
Best in class Kanban boards: Current project management tools are capable, but few enjoy the experience. Trello made significant gains by focusing on the user experience. Unfortunately, Trello chose to be a general tool which left some software teams wanting features designed specifically to help with software development and delivery. GitLab has an opportunity to re-design board-based workflows for product development teams; think of how Jira could work if it were designed by Trello as opposed to the other way around. Our boards need to evolve to be a primary interface, an experience where:
Growth driver: Retention with a transition to initial purchase
Enhancing Portfolio and Project Roadmaps: Provide easy-to-use, cross-team roadmaps at the portfolio, project, and epic level that allow users across the organization to see how work is progressing and identify dependencies and blockers. Organize and prioritize work though dynamic roadmaps in real time. Our current roadmap product works fine for epics, but only provides basic functionality. Roadmaps should include milestones, completion progress, and be expandable to view individual issues as well as provide functionality to edit issues and epics on the roadmap view without losing context.
Growth driver: Expansion
Strategic Planning: Enhanced portfolio management experience allowing customers to start planning from the top; creating strategic initiatives, projects, and epics while laying them out on a roadmap prior to issues and milestones being created. Provide analytics at each level, and allow linking of each object to surface deeper dependency mapping across multiple teams and projects. Enable users to manage strategic initiatives, assign work, measure impact, and allocate resources to each to help deliver tangible business results. Additionally, in order for our users to get more value out of Plan, we will be implementing Epic features to be more aligned with our buying tiers.
Growth driver: Expansion
Requirements Management: Many regulated customers desire to use GitLab for requirements mapping, dependencies, and process management. GitLab will provide these capabilites in a lightweight, modern way such as integrating requirements directly with the actual test cases that verify their implementation during the build process.
Growth driver: Initial purchase
Reporting and Analytics: Provide dashboarding and analytics for project and portfolio management, allowing business to track and communicate progress on work in flight, capacity of teams and projects, and overall efficiency across their full portfolio. Board work in progress limits were the first step here, but expansion of the milestone page to have more historically accurate insights into sprint velocity, scope movement, and plans vs. actuals are important for product development teams.
Growth driver: Retention
Git availability and performance: Git is a critical component in the deployment process when practicing Continuous Deployment. As such, service degradations or outages that prevent access to Git cannot be tolerated. To this end, making Gitaly highly available is of the utmost importance, and secondarily, improve the handling of extreme read pressures exterted by highly parallelized CI loads that cause performance degradations.
Growth driver: Initial purchase
Provide a great experience for large repositories and monorepos: To gather more market share from industries that currently use Perforce or SVN, or from customers that just have huge monorepos, we must invest in making the large repository experience in Git excellent. Large files should “just work” without configuration or specialized hardware. We will primarily be focused on partial clone, but also provide support for sparse checkouts.
Growth driver: Initial purchase
Enhancing the code review experience: In the next 12 months, we must focus code review to be more performant and intelligent. We will do this by investing in performance improvements, adding additional code review functionality such as jump to definition, identifying references, displaying function documentation and type signatures, and adding support for first-class reviewers. Code review should be an "IDE like" experience. Additionally, we should invest in enhancing language specific experiences such as improving syntax highlighting and webpacks. The Merge Request is a point of unification in the product and provides experiences for pipeline results, security scans, code review, discussions, and branching. As such, it's incredibly important that we care about the UX, performance, and usability of this object.
Growth driver: Retention
Realtime Merge Requests: Many parts of GitLab update in near realtime, but not everything does, and unfortunately some of the parts that are left are critical to a great experience. Realtime kanban boards is mentioned above in Plan, but within Create, there is a lot of opportunity. Areas we are thinking about are real time editing of code in the Web IDE for live coding and real time editing of issue/MR descriptions and comments. For more thoughts on this topic, check out the embedded video!
Growth driver: Retention
Focusing on the gaps in the design management workflow: Most designers use a sketch or prototyping tool already, but version controlling assets alongside code and providing a workflow to compare those assets to what front-end teams ship is a gap in the market. We are uniquely poised to capitalize on this gap; think visual review apps checked against the mockups checked into the repository. Additionally, we will continue to make improvements to the collaboration aspect of designs and consider other features such as simple sketch functionality inside of issues and MRs.
Growth driver: Expansion
Bolstering the Web IDE experience: Our current Web IDE experience is useful for small changes, but has not proven itself useful as an actual replacement for a local IDE. Over the next year we will streamline our editing experience, potentially sunsetting the ACE, single-file editor. The team will also be investing in quality of life changes, such as adapting syntax highlighting preferences, moving information to areas in the Web IDE where they would be on local editors, and providing tools for easier code creation. Additionally, we will improve the IDE experience by providing a way to self-host the client side evaluation capabilities already inside of the Web IDE.
Growth Driver: Expansion
Creating a static site editing experience: Projects in GitLab aren't always leveraged by pure engineering teams. Groups like marketing, sales and others often have needs for projects that more closely resemble marketing websites or documentation. While GitLab Pages enables the deployment of many popular static site generators, the editing experience is still geared towards technical users. Enabling a more WYSIWYG content management editor will help support non-technical personas use GitLab for non-engineering driven projecs. We'll also ensure this experience is dogfooded by our GitLab Handbook and available on both mobile and tablet devices.
Growth Driver: Expansion
Code Intelligence: Making changes to a huge code base or monorepo can be challenging due to the sprawl of code and unknown dependencies that span it. Additionally, joining a new orgnization and ramping up with a new codebase is hard. GitLab should provide a great experience for code intelligence that helps contributors be more productive earlier.
Growth Driver: Expansion
Performance and availability: We must invest in the performance, stability, and availability of our application. We will do this by focusing on application limits, diff load times, and ensuring availability is top of mind.
Growth driver: Retention
Choosing to invest in the above areas in 2020 means we will choose not to:
Our direction for the Dev section is to provide the world’s best product creation and management platform. We believe we have a massive opportunity to change how cross-functional, multi-level teams collaborate by providng a solution that breaks down organizational silos and enables more effective, efficient value delivery. We want to provide a solution that enables higher-quality products to be more quickly iterated upon. While we want to to make it effortless for companies to mirgrate to GitLab, striving for feature parity is not our primary objective. In order to obtain adoption at scale, GitLab has to provide substantially more value than our competitors. The following themes listed below represent how we believe we will deliver this value and is our view of what will be important to the market and to GitLab over the next 3 to 5 years. As such, they will be the cornerstone of our 3-year strategy, and all activities in the 1-year plan should advance GitLab in one or more of these areas.
Code review should be a delightful experience for all involved in the process. Over time, we expect the code review process to evolve from where it is today to become a mostly automated process in the future. Along the way, incremental improvements will occur, where developer platforms like GitLab will focus on performance and usability of the code review tools. Code review should be an efficient process, and the easier GitLab can make code review, the more efficient dev teams become. Research has shown that better code review should reduce the number of bugs and increase the amount of higher-quality features an organization can ship. The code review process will continue to provide a venue for developers to learn and collaborate together.
As examples, GitLab will:
Peter Drucker has stated “If you can’t measure it, you can’t improve it.” Many software development teams have no way of measuring their efficiency, and even if they do, there is not enough feedback, information, or actionable insights to improve the efficiency of their team. Even then, once efficiency is improved, it can be difficult to tell if a team’s performance is good or bad, as there is often no point of comparison. Even the best performing team in an organization could be worse than the competition. Increasing efficiency is paramount to companies increasing their time to value and helping organizations answer “Is my DevOps transformation working?”
We believe efficiency can be improved in two ways. The first way is to reduce cycle times for existing value stream activities. The second is to question and optimize the value stream into higher value-added activities at each step. GitLab’s vision is to help answer both of these questions: “Am I doing things fast enough?” and “Am I doing the right things?”
Today, value stream management is largely focused on visualizing the value chain through deployment. GitLab is uniquely positioned to also visualize, track, and measure value chain activities from the strategic initiative level all the way to captured value from an organization's customer. For example, the value created by post launch activities, such as press releases, blog posts, marketing campaigns, and customer engagement should funnel into value stream management; providing the business with insights and data to continuously improve each step of their value chain.
As examples, GitLab will provide:
DevOps started with the merging of Development and Operations and has since been augmented to include Security in some circles, highlighting DevSecOps as the next trend. There are many other personas that are involved in software development, such as product managers, project managers, product designers, finance, marketing, procurement, etc. These personas will continue to expand until nearly every role at knowledge-work companies touches some facet of the DevOps lifecycle. Over time, organizations will realize that teams who work out of the same platform/set of tools are more efficient and deliver faster business and customer value.
Because of this trend, each persona of the DevOps lifecycle should ultimately be treated as a first-class citizen in GitLab.
As examples, GitLab will provide:
Most enterprise customers have custom requirements that GitLab does not solve for today. This is a wide-ranging set of custom controls that spans systems such as permissions, approvals, compliance, governance, workflows, and requirements mapping. It is our belief these needs will exist for many years to come, and we will need to incorporate these to truly become a flexible DevOps platform that serves enterprise segments. We will strive to do this in ways that are modern and, where possible, adhere to a “convention over configuration” approach, living with the cognitive dissonance that sometimes flexibility will be required in areas we have not been willing to venture into thus far.
Additionally, compliance, auditing, and surfacing evidence of security/compliance posture will become more important as more GDPR-like legislation is enacted and passed into law. GitLab should make it easy to not only surface and deliver evidence for GitLab controls (i.e. who has access to GitLab, who did what on what group, etc.), but also to track and manage compliance requirements for various legislation our customers may be bound to.
As examples, GitLab will provide:
Product Managers often struggle with answering the question, "Is the product or feature I just launched successful?" There are many sensing mechanisms to help answer this question, including revenue, users, customer feedback, NPS, etc., but no product currently helps product managers exhaustively manage the product development lifecycle from end-to-end. Many products assist with planning, delivery of code, and deployment, but feedback and iteration are equally as important to product managers as shipping the first iteration. Getting the first iteration out is traditionally celebrated, but is only one of many steps to true product development lifecycle management.
Imagine an experience where product managers can log in and view the "health" of their entire portfolio on one dashboard. It is clear which features have the most value to customers (and by extension to the business) as measured by key metrics, assisting PMs with priortization activities. PMs can quickly identify features or products within their portfolio that need more attention and drill into them, identifying the correct next action to take, whether it's iteration on the feature or perhaps sunsetting it. PMs can quickly create an issue for the next iteration, version control features, view security incidents, respond to customer feedback, drill down into analytics, control A/B tests of the feature, and even interact with users of the feature or product directly by creating ad-hoc surveys or questions for users to answer. Additionally, the experience should allow for ROI analysis and tracking of the ROI after capital has been expended.
Within three years, project management tools will begin evolving to provide this experience and help PMs answer tough product questions. These tools will also assist with measuring and predicting value to the organization before a feature is prioritized by the PM. The ideal solution most likely uses data science, natural language processing (NPL), machine learning, and predictive analytics to assist product managers with decisions both before and after a feature is launched.
As examples, GitLab will provide:
In three years, the Dev Section market will:
As a result, in three years, GitLab will:
For administrators and executives, the process of management is always on. It extends to managing people, money, and risk; when the stakes are high, these stakeholders demand an experience and feature set that makes them feel in control. Setting up your processes shouldn’t be a struggle, and administrators shouldn’t have to compromise on security or compliance to make software work for them.
Not only do we want to fulfill those fundamental needs, we want to give you the freedom to work in new and powerful ways. We aspire to answer questions managers didn't know they had, and to automate away the mundane.
For these users, Manage's role in GitLab is to serve across stages to help organizations prosper with configuration and analytics that enables them to work more efficiently. It’s not enough to give instances the ability to meet their most basic needs; as a single application for the DevOps lifecycle, GitLab can exceed the standard and enable you to work in ways you previously couldn’t.
Manage Overview: See video on YouTube
Manage high level roadmap.
The Manage stage is made up of several categories:
Organize your projects and restrict access to controlled resources. This category is at the "complete" level of maturity.
Track important events for review and compliance such as who performed certain actions and the time they happened. This category is at the "viable" level of maturity.
This category is planned, but not yet available.
Strategy
Provide customers with the tools and features necessary to manage their compliance programs. This category is at the "minimal" level of maturity.
GitLab features multiple auth mechanisms including LDAP (including Active Directory), OmniAuth, CAS, SAML, Okta, and Authentiq.
Managing who's using your instance and what they can do with user management tools, permissions, and user profiles.
Create and manage Teams in GitLab to view insights into how your team is working, communicate more effectively and have more flexible access controls.
GitLab Workspaces allow for tighter autonomy over organization administration and provide a dedicated place for users and teams to work on projects in careful isolation from other Workspaces when needed.
This category is at the "minimal" level of maturity.
Strategy
Get an overview of how well your organization is adopting DevOps and to see the impact on your velocity. This category is at the "minimal" level of maturity.
Import existing work into GitLab from a wide variety of sources.
Gather insights about how your organization is planning and prioritizing across projects and groups.
Visualize, manage and optimize the flow of work through the DevOps lifecycle value stream. This category is at the "minimal" level of maturity.
Learn more • Documentation • Strategy
The Plan stage is made up of several categories:
Plan, organize, and track project progress with issues, labels, weights (story points), milestones (sprints and releases), time tracking, due dates, and assignees using Scrum, Kanban, SAFe, and other methodologies. This category is at the "complete" level of maturity.
Visually prioritize, manage, and track work execution with powerful and flexible kanban boards. This category is at the "viable" level of maturity.
Learn more • Documentation • Strategy
Estimate, track, and report on time spent on issues. This category is at the "viable" level of maturity.
Learn more • Documentation • Strategy
Plan upcoming work by creating Epics and mapping all relevant Issues to them. Create and track against multiple milestones at the portfolio level to see status overtime and review progress towards your goals This category is at the "viable" level of maturity.
Learn more • Documentation • Strategy
Visually plan and map projects in a roadmap view which can be used for tracking and communication. This category is at the "minimal" level of maturity.
Learn more • Documentation • Strategy
Connect your team using GitLab issues, to external parties directly via email for feedback and support, with no additional tools required. This category is at the "viable" level of maturity.
Learn more • Documentation • Strategy
Gather and manage the use cases and requirements to meet business objectives. This category is planned, but not yet available.
Plan and track testing and quality of your product. This category is planned, but not yet available.
The Create stage is made up of several categories:
Source code management enables coordination, sharing and collaboration across the entire software development team. Track and merge branches, audit changes and enable concurrent work, to accelerate software delivery. This category is at the "lovable" level of maturity.
Learn more • Documentation • Strategy
Review code, discuss changes, share knowledge, and identify defects in code among distributed teams via asynchronous review and commenting. Automate, track and report code reviews. This category is at the "lovable" level of maturity.
Learn more • Documentation • Strategy
Share documentation and organization information with a built in wiki. This category is at the "viable" level of maturity.
Focused on building an amazing experience for editing and building static sites. This category is planned, but not yet available.
Focused on improving the GitLab Handbook. The Gitlab Handbook team is resourced from the Growth Section as a temporary exception to our organizational structure.
A full featured Integrated Development Environment (IDE) built into GitLab so you can start contributing on day one with no need to spend days getting all the right packages installed into your local dev environment. This category is at the "viable" level of maturity.
Store and share bits of code and text with other users. This category is at the "minimal" level of maturity.
Upload design assets to GitLab issues for easy collaboration on designs with a single source of truth. This category is at the "minimal" level of maturity.
Do pair programming directly in the Web IDE. This category is planned, but not yet available.
Gitter is an open source instant messaging application for developers, and is the place to connect the open source and software development community.
Gitaly is a Git RPC service for handling all the git calls made by GitLab.
