This is the first in a series of posts diving into our strategy and plans for the GitLab product. This post focuses on the Dev section and is an excerpt of our public direction page for Dev, which you can read for more detail. You can also watch our director of product for Dev, Eric Brinkman present the strategy below. When you're done reading (or watching), please give us your feedback via the survey below!
See how the GitLab product team plans to advance our Dev strategy over the next 12 months to three years.
Overview of our Dev product
Before we dive into the our vision for the future of Dev at GitLab, we're providing some more context on our product and how it fits into the market.
The Dev section is made up of the Manage, Plan, and Create stages of the DevOps lifecycle. These stages mark the leftmost side of the DevOps lifecycle and primarily focus on the creation and development of software. The scope for Dev stages 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 the total addressable market (TAMkt) 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 adopt these strategies. 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 using repositories and code review features like merge requests, they often move “left” and “right” to explore and use other capabilities in GitLab, such as CI and project management features.
Per our stage monthly active user data, the GitLab stages with the highest useage are Manage and Create. 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.
Vision themes
Our vision for the Dev section is to provide the world’s best product creation platform. We believe we have a massive opportunity to change how cross-functional, multi-level teams collaborate by providng an experience that breaks down organizational silos and enables better collaboration. We want to deliver a solution that enables higher-quality products to be created faster. The following themes are listed below to surface our view of what will be important to the market and to GitLab over the next three to five years. As such, they will be the cornerstone of our three-year strategy, and all activities in the one-year plan should advance GitLab in one or more of these areas.
Efficient and automated code review
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. 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 indicates 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.
For example, GitLab will:
- Load large, multi-file diffs faster than any other comparable product on the market.
- Provide tailored insights to the code reviewer, alerting them to the most important areas to review.
- Allow for client- and server-side evaluation of code where possible, and integrate it into the code review process.
Measurement and increased efficiency of the value stream
Peter Drucker has said “If you can’t measure it, you can’t improve it”. Many Dev 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 by improving existing value stream activities and making them more efficient. This focuses on making existing activities as fast as possible. The second way is to question and change 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 to the right of deployment. For example, the value created by post-launch activities, such as press releases, blog posts, and marketing campaigns should funnel into value stream management, while providing the business with the right data and insights for their value chain.
For example, GitLab will provide:
- Easy-to-use and customizable tools that measure the efficiency of the DevOps lifecycle.
- Insight into areas of waste where teams can improve.
- Recommendations based on large data sets of other teams using GitLab, for comparison.
- A visual experience for value stream management that goes beyond code deployment.
DevOps for more personas
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.
For example, GitLab will provide:
- A better experience for project management workflows.
- A space for product designers to design and collaborate on designs with product managers and engineers.
- A Web IDE experience that is able to run the GDK, serving collaborators of all skill sets and hardware, allowing them to contribute to GitLab.
Enterprise digital transformation
While we will continue to solve for the modern DevOps use case first, 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:
- Customizable workflows, unlocking enforcement, approvals, and insight into these workflows.
- More customizable and fine-grained permissions.
- Logs for everything that’s done within GitLab and allow those events to be accessible via the API and UI.
- Alerting on GitLab audit events.
Project management morphs into product management
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 there is currently no product that 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, use 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, if a specific action is prioritized by the PM. The ideal solution most likely uses data science and predictive analytics to assist product managers with decisions both before and after a feature is launched.
As examples, GitLab will provide:
- Feature management capabilities, including the ability to manage a feature as an object inside of GitLab that lives on after an issue is closed.
- An experience where PMs can quickly analyze the health of all relevant features.
- A framework that helps PMs with prioritization decisions.
- A framework for ROI analysis and measurement.
Our three-year strategy
In three years, the Dev section market will:
- Centralize around Git as the version control of choice for not only code, but for design assets, gaming, silicon designs, and AI/ML models.
- Have a market leader emerge in the value stream management space. Currently, the market is fragmented with most players focused on integrations into various DevOps tools.
- Adopt a mindset shift from project management to product management.
- Recognize the value of a single platform for all software creation activities, including product management.
- See an uptick in startups and applications being built on the backs of a "no code" framework
Considering the evolution of the Dev section market, in three years, GitLab will:
- Provide a next-generation, highly performant Git-backed version control system for large assets, such as ML models. Our goal in three years should be to host the most repositories of these non-code assets.
- Emerge as the leader in VSM and be recognized in the industry by customers and analysts as such. Our goal in three years should be to provide the best insights into the product development process that no other tool can come close to, as we have a unified data model due to GitLab being a single platform.
- Develop an industry-leading product management platform where multiple features and products can be measured and managed easily.
- Research and potentially add capabilities for "no code" workflows.
Our one-year plan: What’s next for Dev
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.
Manage
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.
- Improving tools that help compliance-minded organizations thrive. GitLab makes it easy to contribute, but administrators should have comprehensive and 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.
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 answer how much their time-to-production metrics have improved.
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.
Plan
Kanban boards: Current project management tools are capable, but suffer from usability. 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 Kanban boards for software 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, a complete WYSIWYG document view where everyone who is looking on board X is seeing the same thing (updated in real time), with rich interaction without having to leave the board. This may include changes such as having short summaries, first-class checklists, quick filters, etc. In addition, boards need to focus on common workflows of software teams such as issue triage, daily workflow, sprint planning, quarterly planning, executive reporting, etc.
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 boards in order to enable a better planning and project management experience.
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.
Easy top-down planning: Enhanced portfolio management experience allowing customers to start planning from the top: Creating initiatives, projects, and epics while laying them out on a roadmap prior to the creation of issues and milestones. Provide analytics at each level, and allow linking of each object to provide deeper dependency mapping across multiple teams and projects. Enable users to create strategic initiatives and assign work, impact, and resources to each to help them make the right business decisions. 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.
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.
Requirements management: Many regulated customers want to use GitLab for requirements mapping, dependencies, and process management. GitLab will provide these capabilites in a modern-first way.
Create
Realtime: It's time to fully embrace realtime. Many parts of GitLab update in near real time, but not everything does, and unfortunately some of the parts that are left out are critical to a great experience. Realtime kanban boards is mentioned above in Plan, but within Create, there's tons of opportunity for realtime enhancements. 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.
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.
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.
Making large files “just work” in Git: To gather more market share from industries that currently use Perforce or SVN, we must invest in making the large-file experience in Git excellent. It should “just work” without configuration or specialized hardware.
Investing in our Wiki product: Many customers currently use Wikis for knowledge bases and project management activities. Our first step in making the GitLab Wiki more competitive is making wikis available at the group level and enhancing markdown support.
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.
Enabling easier contributions to GitLab: Contributing to GitLab requires users to set up and run the GitLab Development Kit (GDK) locally. This is cumbersome and typically requires multiple hours of debugging with senior engineers. While the process of streamlining the GDK locally should be advanced, GitLab should also provide the GDK as part of the Web IDE experience. Allowing contributors to quickly spin-up feature branches should encourage more contributions from non-engineering GitLab team members, as well as the wider community.
Bolstering the editor experience: Our current Web IDE experience is useful for small changes, but has not been useful as an actual replacement for a local IDE. Over the next year, we will evaluate the impact of adding a container-based IDE solution, while continuing to streamline our editing experience, potentially by sunsetting the ACE editor. We will also improve the IDE experience with self-managed, client-side evaluation, server-side evaluation, and live-coding features for pair programming.
Creating a content management 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 toward technical users. Enabling a more WYSIWYG content management editor will help support non-technical personas use of GitLab for non-engineering driven projects.
What we're not doing
Choosing to invest in these areas in 2020 means we will choose not to:
- Invest in features that help companies answer, “Am I doing the right activities?”. Answering this question is something we will focus on in years two and three of the VSM plan.
- Treat ML models as first-class citizens in GitLab. Instead, we will focus on getting large assets to become performant via improvements to Gitaly. Once this is completed, we will focus on ML models.
- Provide recommendations where customers can improve their efficiency in the DevOps lifecycle. This will likely require comparisons amongst many GitLab users and an AI engine to make intelligent recommendations. These improvements will come in years two and three of the VSM plan.
Other areas of investment consideration
- Data science: We should consider investment into a data science team that can assist with recommendations for Plan and VSM features.
- Dark themes: We should consider prioritizing a dark theme for both GitLab, as well as the Web IDE/editing experience. This is an expected feature of most modern development tools.
- Engineering: Most Dev groups should see 50-100% headcount growth in order to make our Dev categories lovable.
- AI: We should consider beginning to invest into AI as a solution for recommendations – for example, recommended assignees, labels, etc.
Survey
Now that you're heard our strategy and plans, we'd love to hear your feedback. Please click below for a quick two-question survey.
Help shape our Dev strategy - Take our survey!
Cover Photo by Joanna Kosinska on Unsplash.
