We think that it is logical that our collaboration tools are a collaborative work themselves. More than 2,000 people have contributed to GitLab to make that a reality. We believe in a world where everyone can contribute. 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.
In summary, our vision is as follows:
We believe that all digital products should be open to contributions, from legal documents to movie scripts and from websites to chip designs. 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.
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 mission guides our path, during this path live our values.
Everyone can contribute to digital products with GitLab, to GitLab itself, and to our organization.
To ensure that everyone can contribute with GitLab we allow anyone to create a proposal, at any time, without setup, and with confidence.
To ensure that everyone can contribute to GitLab the application we actively welcome contributors. We do this by having quality code, tests, documentation, using popular frameworks, 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 that allow 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.
Ensure that everyone can contribute in the 3 ways outlined above.
Become most used software for the software development lifecycle and collaboration on all digital content by following the sequence below.
Complete our product vision of a single application based on convention over configuration.
Offer a sense of progress in a supportive environment with smart colleagues.
Stay independent so we can preserve our values. Since we took external investment we need a liquidity event. To stay independent we want that to become a public company instead of being acquired.
We want to achieve our goals in the following order:
In CY2015 we became the most popular on-premises software development lifecycle solution, and we want to continue that.
We want to become the most revenue generating on-premises software development lifecycle solution before going public.
Around going public we want to become the most popular SaaS solution for private repositories (a complete product that is free forever is competitive since network effects are smaller for private repositories than for public ones).
After going public we want to become the most popular SaaS solution for public repositories. This market has a strong network effect since more people will participate if you host your public project on a site with more people. It is easier to overcome this network effect if many people already use GitLab.com for hosting private repositories. Having people on our SaaS helps drive awareness and familiarity with GitLab.
Our BHAG is to become the most popular collaboration tool for knowledge workers in any industry. For this, we need to make the git workflow much more user friendly. The great thing is that sites like Penflip are already building on GitLab to make it.
We want to go public in CY2020, specifically on Wednesday November 18, 2020 is five years after the first people got stock options with 4 years of vesting. To go public, we need more than $100 million in Annual Recurring Revenue (ARR). To achieve that we want to double Incremental Annual Contract Value (IACV) every year. We focus on an incremental number instead of growth of our Annual Recurring Revenue (ARR) because ARR growth is misleading. So far we achieved the goal of doubling IACV in CY2013, CY2014, CY2015, CY2016, CY2017 and CY2018.
Why CY2020? It's aggressive, it's possible, and it's realistic. Having a goal gives us clarity on what we need to achieve. Our ambition is clear, and we want to be a growing and independent company. We are in an enormous market, and we're winning that market.
While we achieve our goals one by one, this doesn't mean we will focus on only one goal at a time. Simultaneously, we'll grow our userbase, get more paid subscribers, grow GitLab.com, realize our scope, and make version control usable for more types of work.
During phase 2 there is a natural inclination to focus only on on-premises since we make all our money there. Having GitHub focus on SaaS instead of on-premises gave us a great opportunity to achieve phase 1. But GitHub was not wrong, they were early. When everyone was focused on video on demand Netflix focused on shipping DVDs by mail. Not because it was the future but because it was the biggest market. The biggest mistake they could have made was to stick with DVDs. Instead they leveraged the revenue generated with the DVDs to build the best video on demand service.
We realize our competitors have started earlier and have more capital. Because we started later we need a more compelling product that covers the complete scope with a single application based on convention over configuration in a cloud native way. Because we have less capital, we need to build that as a community. Therefore it is important to share and ship our vision for the product. The people that have the most knowledge have to prioritize breadth over depth since only they can add new functionality. Making the functionality more comprehensive requires less coordination than making the initial minimal feature. Shipping functionality that is incomplete to expand the scope sometimes goes against our instincts. However leading the way is needed to allow others to see our path and contribute. With others contributing, we'll iterate faster to improve and polish functionality over time. So when in doubt, the rule of thumb is breadth over depth, so everyone can contribute.
If you want an analogy think of our product team as a plow way in front that tills the earth. It takes a while for the plants (complete features) to grow behind it. This tilled earth is ugly to look at but it surfaces the nutrients that the wider community needs to be inspired and to contribute.
If we can make a product that is strong with all features from planning to monitoring, and it works well, then we believe we can become the number one solution that companies standardize around. We need to offer the benefits that you can only have with an integrated product.
So breadth over depth is the strategy for GitLab the company. GitLab the project should have depth in every category it offers. It will take a few years to become best in class in a certain space because we depend on users contributing back, and we publish that journey on our maturity page. But that is the end goal, an application of unmatched breath and depth.
Founder control: vote & board majority so we can keep making long term decisions.
Independence: since we took financing we need to have a liquidity event; to maintain independence we want to become a public company rather than be acquired.
Low burn: spend seed money like it is the last we’ll raise, maintain 2 years of runway.
First time right: last to market so we get it right the first time, a fast follower with taste.
Values: make decisions based on our values, even if it is inconvenient.
Free SaaS: to make GitLab.com the most popular SaaS for private projects in CY2020, it should not have limits for projects or collaborators.
Reach: go for a broad reach, no focus on business verticals or certain programming languages.
Speed: ship every change in the next release to maximize responsiveness and learning.
Life balance: we want people to stay with us for a long time, so it is important to take time off, work on life balance, and being remote-only is a large part of the solution.
Open source user benefits: significant advantages over proprietary software because of its faster innovation, higher quality, freedom from vendor lock-in, greater security, and lower total cost of ownership.
Open Source stewardship: community comes first, we plays well with others and share the pie with other organizations commercializing GitLab.
Innersourcing is needed and will force companies to choose one solution top-down.
Git will dominate the version control market in CY2020.
A single application where interdependence creates exceptional value is superior to a collection of tools or a network of tools. Even so, good integrations are important for network effects and making it possible to integrate GitLab into an organization.
To be sustainable we need an open core model that includes a proprietary GitLab EE.
EE needs a low base price that is publicly available to compete for reach with CE, established competitors, and new entrants to the market.
The low base price for EE is supplemented by a large set of options aimed at larger organizations that get a lot of value from GitLab.
Most of GitLab functionality is and will be available for free in Core. Our paid tiers includes features that are more relevant for managers, directors, and executives. We promise all major features in our scope are available in Core too. Instead of charging for specific parts of our scope (CI, Monitoring, etc.) we charge for smaller features that you are more likely to need if you use GitLab with a lot of users. There are a couple of reasons for this:
Because we have a great free product we can't have one price. Setting it high would make the difference from the free version too high. Setting it low would make it hard to run a sustainable business. There is no middle ground that would work out with one price.
That is why we have a Starter, Premium, and Ultimate tiers. The price difference between each of them is half an order of magnitude (5x).
We charge for making people more effective and will charge per user, per application, or per instance. We do include free minutes with our subscriptions and trials to make it easier for users to get started. As we look towards more deployment-related functionality on .com it's tempting to offer compute and charge a percent on top of, for example, Google Cloud Platform (GCP). We don't want to charge an ambiguous margin on top of another provider since this limits user choice and is not transparent. So we will always let you BYOK (bring your own Kubernetes) and never lock you into our infrastructure to charge you an opaque premium on those costs.
Losing the interest of the open source community would be detrimental to our success. For example, if someone wanted to make a contribution to CE and decided not to merge it because a similar feature already existed in EE, we would have lost out on an important contribution from the community.
We'll also need to adapt with a changing market. 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.
If a new, better version control technology dominates the market, we will need to adopt it and keep an open mind. Hopefully, we will be big enough at that point that people will consider us an integrated DevOps product. If not, we can always change our name, but we are currently investing to make git better for everyone.
For more thoughts on pricing please see our pricing model.
GitLab has two flywheel strategies that reinforce eachother. A flywheel strategy is defined as one that has a positive feedback loops that build momentum, increasing the payoff of incremental effort. Both are listed below as well as a table which lists the relevant indicator and department for every part of the flywheel.
| Part of flywheel | Key Performance Indicator (KPI) | Department |
|---|---|---|
| MoreUsers | Stage Monthly Active Users | Developer marketing |
| MoreAcceptingMergeRequests | Accepting Merge Requests issue growth | Product Management |
| MoreContributions | Wider community contributions per release | Community relations |
| MoreFeatures | Merge Requests per release per engineer in product development | Engineering |
| MorePipeline | Pipe generated vs. plan | Marketing except community and developer |
| MoreRevenue | IACV vs. plan | Sales |
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 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."
