Gitlab hero border pattern left svg Gitlab hero border pattern right svg

GitLab Mission and Vision

On this page

Background

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.

Mission

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.

Big Hairy Audacious Goal

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.

Values

Our mission guides our path, and we live our values along this path.

Vision

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.

Goals

  1. Ensure that everyone can contribute in the three ways outlined above.
  2. Become the most used software for the software development lifecycle and collaboration on all digital content by following the sequence below.
  3. Complete our product vision of a single application based on convention over configuration.
  4. Offer a sense of progress in a supportive environment with smart colleagues.
  5. Remain independent so we can preserve our values. Since we took external investment, we need a liquidity event. To remain independent, we want to become a public company instead of being acquired.

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,

  1. Everyone can contribute with GitLab
  2. Everyone can contribute to GitLab, the application
  3. Everyone can contribute to GitLab, the company

Everyone can contribute with GitLab

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.

Everyone can contribute to GitLab, the application

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:

Everyone can contribute to GitLab, the company

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.

Everyone can contribute to about.gitlab.com

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.

Customer acceptance

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:

  1. Engaging in illegal, unlawful behavior.
  2. Making derogatory statements or threats toward anyone in our community.
  3. Encouraging violence or discrimination against legally protected groups.

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:

Monitoring an evolving market

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.

Entering new markets

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:

Category Consolidation

  1. A set of customer needs that are currently served by multiple, independent software tools
  2. Those tools may already integrate with each other or have the possibility of integration
  3. Those tools operate in categories that are typically considered discreetly (e.g. with GitLab, SCM was one market, CI another)
  4. There is no current 'winner' at consolidating this market, even if there are some attempts to combine some of the tool categories within said market
  5. The users of the product would also be able to contribute to it e.g. with GitLab, the users are software developers, who can directly contribute code back to the product itself
  6. When initially combined the categories form a consistent and desirable user flow which solves an overriding customer requirement
  7. We can offer a consolidated toolchain more cost effectively for customers, than needing to purchase, run and integrate each tool separately
  8. We can do so profitably for the company

Category Creation

  1. By combining these categories together, a new overriding category, or market, gets created - the consolidated toolchain;
  2. Further adjacent categories and/or markets can be added to deliver additional user value. For example with GitLab, you could argue that the Protect Category (as of October 2019) is an adjacent category/market to be added;
  3. The sum of the categories combined should have desirable CAGR such that entering the markets will mean entering those on a growth curve;
  4. Not all of the individual categories need to be on the upward curve of the technology adoption lifecycle (TAL) - it is however necessary that there are enough future categories with high CAGR and early on in their adoption lifecycle - see example (very rough) diagram outlining this below: (insert overlapping TALs);
  5. The ideal overlap of the TALs is that the peaks of the curves are as close to each other as possible, so that when one TAL moves to Late Majority, the next TAL is still curving upwards. This allows it to provide an organic growth opportunity for the company in the markets it is entering.

Our goal is to develop this model to be more quantifiable and formulaic, so that we can quickly and easily assess new opportunities.

Risks

We acknowledge the risks to achieving our goals. We document them in our biggest risks page.

Why is this page public?

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."

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license