GitLab's mission, vision, strategy, and planning follow a cadence. Along each time period, we answer various fundamental questions: why, what, how, and when. The matrix of questions vs time period is below, with mappings to the appropriate sections of this page.
| Time Period | 30 Years | 10 Years | 3 Years | 1 Year |
|---|---|---|---|---|
| Why | Why | |||
| What | Mission, BHAG | Vision, Goals | Strategy | |
| How | Values | Everyone can contribute, Customer Acceptance, Monitoring an evolving market, Risks | Principles, Assumptions, Pricing, Dual Flywheels, KPIs |
We believe in a world where everyone can contribute. We believe that all digital products should be open to contributions; from legal documents to movie scripts, and from websites to chip designs.
Allowing everyone to make a proposal is the core of what a DVCS (Distributed Version Control System) such as Git enables. No invite needed: if you can see it, you can contribute.
We think that it is logical that our collaboration tools are a collaborative work themselves. More than 3,000 people from the wider community have contributed to GitLab to make that a reality.
It is GitLab's mission to change all creative work from read-only to read-write so that everyone can contribute.
When everyone can contribute, consumers become contributors and we greatly increase the rate of human progress.
Our BHAG over the next 30 years is to become the most popular collaboration tool for knowledge workers in any industry. For this, we need to make the DevOps lifecycle much more user friendly.
Our mission guides our path, and we live our values along this path.
In summary, our vision is as follows:
GitLab Inc. develops great open source software to enable people to collaborate in this way. GitLab is a single application based on convention over configuration that everyone should be able to afford and adapt. With GitLab, everyone can contribute.
Everyone can contribute to digital products with GitLab, to GitLab itself, and to our organization. There are three ways you can Contribute,
To ensure that everyone can contribute with GitLab we allow anyone to create a proposal, at any time, without setup, and with confidence. Let's analyze that sentence a bit.
We actively welcome contributors to ensure that everyone can contribute to GitLab, the application. We do this by having quality code, tests, documentation, popular frameworks, and offering a comprehensive GitLab Development Kit and a dedicated GitLab Design System. We use GitLab at GitLab Inc., we dogfood it and make it a tool we continue to love. We celebrate contributions by recognizing a Most Valuable Person (MVP) every month. We allow everyone to anticipate, propose, discuss, and contribute features by having everything on a public issue tracker. We ship a new version every month so contributions and feedback are visible fast. To contribute to open source software, people must be empowered to learn programming. That is why we sponsor initiatives such as Rails Girls. There are a few significant, but often overlooked, nuances of the everyone can contribute to GitLab, the application mantra:
A group discussion reiterating the importance of everyone being able to contribute:
To ensure that everyone can contribute to GitLab, the company we have open business processes. This allows all team members to suggest improvements to our handbook. We hire remotely so everyone with an internet connection can come work for us and be judged on results, not presence in an office. We offer equal opportunity for every nationality. We are agnostic to location and create more equality of opportunity in the world. We engage on Hacker News, Twitter, and our blog post comments. And we strive to take decisions guided by our values.
We welcome all contributors in the www-gitlab-com project so that everyone can contribute to about.gitlab.com. GitLab uses about.gitlab.com to share our expertise with the world and believe we can build even greater levels of trust with contributions from our team and community. We strive to provide a great experience for our existing and new community members by reviewing changes and integrating the contributions into our regularly planned updates.
We firmly adhere to laws including trade compliance laws in countries where we do business, and welcome everyone abiding by those legal restrictions to be customers of GitLab. In some circumstances, we may opt to not work with particular organizations, on a case-by-case basis. Some reasons we may choose not to work with certain entities include, but are not limited to:
This policy is in alignment with our mission, contributor and employee code-of-conduct and company values. Here are some links that may give you some background at how we arrived at this customer acceptance policy:
Our mission is "everyone can contribute." This mission is in alignment with our open source roots and the MIT license our open source software is subject to. The MIT License is a free software license that allows users the freedom to run the program as they wish, for any purpose.
GitLab has a contributor code of conduct for how to contribute to GitLab, but there are no restrictions on who can contribute to GitLab. We desire that everyone can contribute, as long as they abide by the code of conduct.
GitLab has a set of values for how Gitlabbers strive to conduct themselves. We don’t expect all companies to value collaboration, results, efficiency, diversity, inclusion and transparency in the same way we do. As an open company, “everyone can contribute” is our default and transparency is our check and balance. Transparency means our handbook, issues, merge requests and product roadmap are online for everyone to see and contribute to.
Related topic: At GitLab, we want to avoid an environment where people feel alienated for their religious or political opinions. Therefore, we encourage Gitlabbers to refrain from taking positions on specific religious or political issues in public company forums (such as on the GitLab Contribute stage or Slack channels) because it is easy to alienate people that may have a minority opinion. It is acceptable to bring up these topics in social contexts such as coffee chats and real-life meetups with other coworkers, but always be aware of cultural sensitivities, exercise your best judgement, and make sure you stay within the boundaries of our Code of Business Conduct & Ethics. We always encourage discussion and iteration on any company policy, including this one.
We'll also need to adapt with a changing market so that we meet customer needs. Netflix is a great example of this. Everyone knew that video on demand was the future. Netflix, however, started shipping DVDs over mail. They knew that it would get them a database of content that people would want to watch on demand. Timing is everything.
Additionally, we need to ensure that our Platform is open. If a new, better version control technology enters the market, we will need to integrate it into our platform, as it is one component in an integrated DevOps product.
GitLab has taken existing, fragmented software tooling markets, and by offering a consolidated offering instead, have created a new blue ocean.
We would like to find more markets where we can repeat the same model.
The desirable characteristics of such markets fall into two stages: category consolidation and creation. They are:
Our goal is to develop this model to be more quantifiable and formulaic, so that we can quickly and easily assess new opportunities.
We acknowledge the risks to achieving our goals. We document them in our biggest risks page.
This is in draft until the end of 2020. We are gathering feedback in individual MRs instead of MR comments to keep it manageable.
Our strategy is looking 3 years out and fits into our cadences.
Along the road to realizing our mission of everyone can contribute, our strategic goal is to become the leading complete DevOps platform (or, what Gartner calls the DevOps Value Stream Delivery platform) delivered as a single application. We will help our customers build better software faster including developing cloud native applications, building mobile applications, and incorporating machine learning and artificial intelligence into their products and solutions. We believe that our dual flywheels (single application + open-core model) will propel us to efficiently be the default choice in the Enterprise market.
To achieve this, we will endeavor to:
Ensure that when customers buy DevOps software the single application approach is the default.
We will strive to increase the contributions of the wider community.
The customer will be the center of our operations including how we develop, market, and support our products. While we ship fast every month, we are committed to a seamless change management experience for our customers so they can get the best of GitLab in a predictable way. We have a goal that over one thousand of our customers become references.
Developing our team members is a core operating principle at GitLab. We offer a competitive, performance-based total rewards package, in addition to robust learning & career advancement opportunities. GitLab is considered a best place to work for our high performing team members as measured by its talent brand and internal team member satisfaction ( >90%).
As we execute on our strategy, it is important to use our financial targets as guide rails and mature our internal processes for building a durable business for the long-term.
More detail on our product strategy can be found on our direction page.
Our GitLab product vision is to deliver a single application for the entire DevOps lifecycle. This is a very expansive product vision that requires us to build an enormous amount of product surface area. Because we are capital constrained, we need to build GitLab as a community. When we are early in a particular area of the product, we will plant seeds by shipping a small MVC. Shipping functionality that is incomplete to expand the scope sometimes goes against our instincts. However, planting those seeds even in an incomplete state allows others to see our path and contribute. With others contributing, we'll iterate faster and will accelerate the maturity of our offering faster than GitLab could on its own. We can have a long tail of categories that are at a minimal maturity that don't get investment until they show traction. While these come with a low level of shame they allow the wider community to contribute and people to express interest. It is much more common for people to contribute to categories that already exist and express interest in categories already shipping in the product. A minimal category is the placeholder to channel energy, and it is our responsibility to till the earth with minimal iterations.
GitLab the product should eventually have depth in every category it offers. To build out real depth requires a shift in focus, from planting seeds to nurturing the product area to maturity. We should concentrate our nurture investments in the categories that have demonstrated monthly active usage, revenue contribution, and demonstrated customer demand. As a product team, we'll be particularly focused on driving monthly active usage at the stage and group level. This should lead to more Stages per User, which is important as each stage added triples paid conversion! We'll also be heavily focused on driving usability, by measuring our system usability score, which is a measure of the user perception of GitLab's usability.
If we effectively seed and then nurture, we can fully activate GitLab's two growth turbos, by creating wider community contributions and driving more stages per user.
Please see our pricing model for details
GitLab has two flywheel strategies that reinforce each other: our open core flywheel and our development spend flywheel. A flywheel strategy is defined as one that has positive feedback loops that build momentum, increasing the payoff of incremental effort. You can visualize how the flywheels work in congruence via the diagram below. The KPI and responsibilities table lists the relevant indicator and department for every part of the flywheel.
In the open core flywheel, more features drive more users which in turn drive more revenue and more contributions which lead to more users.
| Part of flywheel | Key Performance Indicator (KPI) | Department |
|---|---|---|
| More Users | Stage Monthly Active Users | Product |
| More Contributions | Wider community contributions per release | Community Relations |
| More Features | Merge Requests per release per engineer in product development | Engineering and Product Management |
| More Revenue | IACV vs. plan | Sales |
GitLab is a complete DevOps platform, delivered as a single application, with contributions from the wider community.
Compared to other DevOps platforms, GitLab leverages one or two unique turbos that boost the company:
The advantage of a single application manifests itself if people start using more stages of the application. In the graph below this is visualized with Stages per Organization (SpO), knowing that an organization using an extra stage triples conversion. Increasing SpO drives both more seats and higher revenue per seat.
In the development spend flywheel, we capture the relationship between merge requests (MRs), changes in ARR from one period to the next (Delta ARR), hyper growth R&D spend and the resulting impact on MRs. We see that more MRs increase stage maturity which drives more monthly active users and stages per user which in turn drives more seats and more revenue which funds R&D spend and leads to more MRs.
Legend with links to the relevant metrics:
To make sure our goals are clearly defined and aligned throughout the organization, we make use of Objectives and Key Results (OKRs) and Key Performance Indicators (KPIs) which are both publicly viewable.
Our yearly plans are linked from the relevant cadence section.
Our strategy is completely public because transparency is one of our values. We're not afraid of sharing our strategy because, as Peter Drucker said, "Strategy is a commodity, execution is an art."
