Syste “Sid” Sijbrandij is the Co-founder and CEO of GitLab, a DevOps lifecycle tool. In this episode, Syste discusses product pricing and their approach to hiring a globally-dispersed team.

Transcript

Introduction

Michael Schwartz: Welcome back, and thanks for checking into Open Source Underdogs.

We have an epic interview this week with Sid Sijbrandij, Co-Founder of GitLab.

GitLab provides an on-premise platform for code management and continuous integration. In some ways, their story proves you don’t always need to be first. GitLab didn’t invent Git, Linus Torvalds did that in 2005. GitLab was started well after GitHub.

Sid has some great advice for open source startups. I don’t want to give it away, so let’s just jump in.

Origin Story

Michael Schwartz: Sid, thank you so much for joining our podcast today.

Sid Sijbrandij: Thanks for having me.

Michael Schwartz: So, how did GitLab get started?

Sid Sijbrandij: Yes, so GitLab got started by my Co-Founder Dmitriy.

Two things he wanted to improve in life: He didn’t have running water and he didn’t have great collaboration software at work.

He didn’t have budget to pay for either of them, so he did what he could do, without spending any money, and he built better collaboration software.

300 people joined him in contributing to that, and I saw it when GitLab was one year old, and there were 300 people contributing. I thought, this is great. All the software I use is open source, so if anything should be open source, it should be the software I collaborate with, that should be open to contributions.

I started GitLab.com – I thought a SaaS model made a lot of sense. I sent Dmitriy an email saying “Hey Dmitriy, I’m going to work on this, if you’re not going to be part of it. I hope you don’t mind.

And he sent back, “No, it’s fine. It’s open source, just go for it. I hope you make GitLab more popular.” I thought that was pretty open-minded of him.

A year later, I learned a few things. First of all, most big Enterprises are self-hosting GitLab, and they had a big need for more features.

Another thing that happened was, Dimitry tweeted out “I want to work on GitLab full time.”

So I sent him an email like, “Hey – can I hire you to pay you to make those features that customers want?”

We agreed on a price, I went to the local Western Union money station in the Netherlands, and I said I wanted to wire some money to Ukraine. They asked me, “Do you know this person, or is this someone you met over the internet?” because there were a lot of scams going on.

I took the risk, made that wire, and we were in business. We started making those features that people asked for. Dmitriy also got around a couple years ago.

Why ADD CI

Michael Schwartz: GitLab is more than a version control tool – it’s a single application for the entire DevOps lifecycle. Why did you evolve the product in this direction?

Sid Sijbrandij: Dmitriy never wanted to upgrade another Jenkins server again, so he built his own CI system.

That was kind of a side project, it wasn’t official GitLab project. We published source, and we had to improve it a bit for our own needs, and then people started contributing to that too.

And at a certain point, we got an amazing contribution from Camille in Poland, and we said, “This is amazing, we’ll make your version the official version from now on. And by the way, do you want to work at GitLab?”

And we hired him, and after a couple of months, he said to Dmitriy “Look, I think we should integrate the two projects. I think we should make it a single application.”

Dmitriy pointed out how it was wrong because everything in the marketplace, it’s separate, like there was not a single version control tool that also had CI. He disagreed, said it would be better, and he convinced Dmitriy who came to me, I also pointed out that we should have many sharp tools that you could compose together.

He said, “Well, if you don’t believe it’s better for the user, at least believe it’s less work.” Efficiency is one of our values, so we did it, and it turns out he was totally right – it was a much better user experience, which was kind of intuitive to us.

We integrated the two applications, to get it really tightly, we had like custom APIs to make them work together. But it was still so much better if you didn’t have to switch to another user interface, if you had a single-data model and could service all the relevant information. We realized that we discovered something, a secret, not in the sense that we wouldn’t tell people but in the sense that it wouldn’t be intuitive to them.

We started adding more and more features, and today, GitLab goes all the way from planning what you want to do to the point that monitoring that, securing and defending that, and managing that entire life cycle.

And it’s one of the top reasons that people like to use GitLab over stringing together 10 different DevOps tools, and then having to maintain all the integrations.

What is Open V. Commercial?

Michael Schwartz: As I understand it, GitLab is open core. How do you decide which features to make commercial?

Sid Sijbrandij: It is very hard for us to figure that out. We first tried to kind of charge for features that we thought were used by bigger companies, but that’s not a really clear distinction.

So, we settled on something we called buyer-based open core, where we have four different roles in companies that care about features, they are the individual contributors. And if they care about a feature most, we make it open source. That makes it very easy to contribute back.

Then, if it’s managers, directors, or executives, we place it in one of our price plans, going from the lower tier to the higher tier.

If an executive wants a feature, for example something compliance-based, it’s the most expensive price per seed. If a manager wants it, for example, to increase the performance of the GitLab instance, it’s the lowest price per seed.

How To Distribute the Bits

Michael Schwartz: GitLab Community Edition is MIT licensed – how do you actually publish and distribute the commercial version? And what’s the upgrade path to go from the Community version to a paid version?

Sid Sijbrandij: We distribute two variants of GitLab, Community Edition and Enterprise Edition – both are very similar, both are available, and both got like all the security updates. By default, we have people download the Enterprise Edition, and you can use that without a license key or anything else.

And then, you just get all the open source features. The advantage of that is that if people want to upgrade, they don’t have to do a reinstall, but they can just give it a license key and unlock all those additional features.

Customers

Michael Schwartz: Who are the customers of GitLab?

Sid Sijbrandij: It is a very wide variety of users of GitLab. There’s over 100,000 organizations that use GitLab.

The majority use the open source version, so they are users but not customers. Many customers range from people that buy a single seed all the way to Fortune 500 companies that use it with tens of thousands of people.

Market Segmentation

Michael Schwartz: Do you segment the market at all? It’s such a broad horizontal market, I’m just wondering if there’s any way that you break up the customers?

Sid Sijbrandij: Yeah, for sure.

For the open source, we have a developer marketing team that focuses on serving the needs of our users and to make it more popular. At the bottom of the pyramid, we got self-serve, where we do a lot of automated programs. We have people mostly help themselves by our website, or our pricing is public.

For the middle of the market, we are a bit more active. We do reach out to people, we have kind of inside sales representatives that help the customer.

At the top of that market, it’s a classic Enterprise sales motion, where you have strategic account leaders that visit the customer together with a solution architect; we have technical account managers to ensure that they are successful with the implementation.

Evolution of Value Proposition

Michael Schwartz: I imagine the initial value proposition was something like GitHub but deployed on your… or self-hosted, let’s say. Has the value proposition for GitLab evolved over time?

Sid Sijbrandij: We started making features that people really needed. For example, things like protected branches, and now protected environments, were first introduced in GitLab.

We also try to cater to the organizational complexity. For example, GitLab has subgroups, so that you can make kind of a hierarchy of projects, and have better communication and control throughout the company.

Apart from the open source, or apart from the version control, we also started doing other things, the CI, but also planning tools. We now have like portfolio management, packaging, for example. We have container registry as part of GitLab, but also configuration, continuous deployment, and monitoring. We expanded the scope of the product as well.

It’s always important to, in any case, you can also add to do that. What’s helping is that not only are we thinking of stuff ourselves, we also got open issue tracker, so people can contribute ideas, and we also get a lot of code from the wider community.

Last release, last month – more than 200 features came from the wider community that was shipped.

Evolution of Pricing

Michael Schwartz: One of the biggest challenges for any open source company is pricing. If you price wrong, you end up giving away too much value. If you price too much, you might price out an important segment of the market. What process did you use to figure out how to find the right price points?

Sid Sijbrandij: I did the classic thing that a technical founder does, and I priced too low.

So, our first Enterprise customer was using GitLab with thousands of users, they were prepared to pay tens and tens of thousands of dollars reserved for that. I priced it at $1500 for all the users of a Fortune 1 company. And so that was a big mistake.

Over time, we got better at it.

Our pricing was so off that in the beginning, we doubled the pricing, and all of our customers said, “This is fine – you were really too low, but just don’t do this again.”

So then we started thinking what to do next. And first we tried kind of price features – so we had 15 different features that were all priced separately. That tended to be very cumbersome to sell and to buy for the customer.

Then we switched to a pretty classic “good-better-best model,” and there’s a pretty steep change between the different plans: So our lowest plan is $4 per user per month, and our highest plan is $99 per user per month.

First we had the, kind of, the “good plan.” We introduced a better plan at a five times higher price. And in the beginning it was like, “Well, this is too expensive,” but over time we were able to add more features to it. And then we did the same thing again while we introduced a new tier, at five times higher price.

In the beginning it was too expensive, and we had to discount. But over time, we were able to add more features, and add more value to it. And over time, we were able to do it with less discounting. We have already started seeing that, where we’re now selling that at full price.

More On Pricing

Michael Schwartz: How many times per year do you tweak your pricing?

Sid Sijbrandij: So far, we haven’t done that. It’s a good business practice, I think, to adjust your prices, for at least inflation, once a year.

For us, because there’s a 25x difference between our lowest and the highest tier, the focus has been to move people up to higher-price tiers.

Michael Schwartz: I see. So, your pricing has sort of stabilized. Once you figured it out, you were able to sort of stabilize pricing, and you haven’t had to tweak it that much.

Sid Sijbrandij: Yeah, we tweaked it by introducing new tiers. And what’s really important to our customers is we didn’t take any features away from the existing tiers.

So if they paid for something, we didn’t change the pricing on them, apart from that one-time doubling of the pricing. But after that, we kept that stable, and we focused on convincing customers that there was value in moving to a higher-price tier, with more features, and functionality, and support.

Partnerships

Michael Schwartz: So, changing gears a little bit, I’m wondering about partnerships – were there any partners to GitLab that were materially helpful for building the business?

Sid Sijbrandij: I think in the beginning, it is very, very hard to partner because you’re so small. It can lead to a lot of wasted time.

For us, that changed after GitHub got acquired by Microsoft. And now other kind of platform partners, people that have Cloud or Kubernetes distributions, see the risk that if people stay on GitHub, that Microsoft and Azure are going to be very, very close to that customer.

So now we’re partnering with partners like AWS, GCP, VMware, and RedHat, to make sure that if people have a Kubernetes cluster, that we recommend the GitLab to them in order to deploy their applications there.

Community Cheerleading

Michael Schwartz: How have you energized the community to such an extent that you’re able to generate such a great amount of contribution?

Sid Sijbrandij: In the first place we’re really lucky, because we make a product that is used by developers, by security people, by operations people – and those people tend to be proficient at coding, so for us, it’s easier to get those contributions.

But as GitLab grows as a product, it’s harder and harder for people to see where they can contribute. So we label certain issues with accepting merge requests to say, “Hey, consider contributing here.”

People are free to contribute anywhere they want, and then when they do so, we have merge request coaches that help them get over the finish line.

Because sometimes the code is there, but it’s not according to the coding guidelines; or they have the code, but they haven’t written tests; or they have code and tests, but they haven’t written the documentation. And those merge requests coaches help with doing that.

We also make sure to kind of flag the contributions, especially first-time contributions that make sure our product managers are aware, and that we kind of take action on them in a
response, in an appropriate amount of time to the contribution. And then when it gets merged, we send them a thank you gift, just a small token of our appreciation for the contributions.

We also do regular hackathons.

I want to shout out to Ray – Ray is kind of like coordinating this effort. In the last six months, we’ve seen the number of contributions double from about 100 to about 200 every month.

So just being receptive and having a program around it has been a major improvement for increasing the number of contributions.

When to Open Source Software

Michael Schwartz: Do you have any thoughts about what type of software should be open source, and what type of software should be commercially licensed?

Sid Sijbrandij: Well, first of all, GitLab is open core, so we’re doing both.

But I think open source makes sense if you’re making something that is foundational to a lot of other things. If almost everyone in the world needs that, it makes a lot of sense.

Almost everyone in the world needs a database. Almost everyone in the world needs great DevOp software, like GitLab. So I think projects that are going to be used by so many people, then open source works.

I think when you make something that’s going to be very much aimed at a specific vertical, let’s say biotech, and the users of the software are unlikely to contribute back – it sometimes makes more sense to make something proprietary.

What you get with open source is that you create a ton more value because you get a ton more usage – but you can charge less relative than proprietary variance.

So you’ve got to make sure that increase in distribution that open source gets you will be so big that it compensates for, kind of, a lower take-rate or capture-rate in the form of pricing for your software.

Breadth of Depth

Michael Schwartz: I was reading the GitLab company handbook, which is quite extensive, and quite transparent. And in your strategy section, you mentioned that your competitor started before you got more capital, and that you needed to focus on breadth over depth. I was wondering what exactly does that mean?

Sid Sijbrandij: Thanks for asking that question. We have an amazing community that contributes back a lot of improvements to GitLab; and those tend to be things that are features that are missing within a specific stage.

So, we introduced a new monitoring stage, and hopefully at some point it becomes like interesting enough for people to start using it, and then they miss a certain thing, and they’ll add to it. What we haven’t seen from the wider community is biting off more scope.

When we had version control, the community contributed to that, but they didn’t add CI, we had to add CI. Once we had CI, the community contributed to that, but they didn’t add packaging. And the same story again for all of those at different stages.

That’s because, if you create a new stage, it takes a lot of coordination. It takes, like, working the user interface; it takes kind of fundamental architectural changes; it takes a deeper understanding of the product.

And to do that, it’s a full-time job. To make such big changes, you have to be well-versed, and it takes a team of people to do that. And someone making a contribution is unlikely to have that much time and that big of a team to make that change.

So, we as a company, want to focus on increasing the breadth of the product, biting off new scope, going into things that haven’t been there before. Then, the wider community helps us to add depth to it.

We want to till the land and then make sure it’s fertile, so that the wider community can grow things on it

Remote Workforce

Michael Schwartz: GitLab is sort of well known for being having a remote-only workforce. And I’m curious if you could share some of the lessons learned about pursuing that strategy for building the team?

Sid Sijbrandij: We’re an all-remote team, we have now 650 people across more than 50 countries. It’s been amazing that we’ve been able to hire people, in like 90% of the cases. Normally, you’re constrained to the places where your offices are. And at GitLab, we hire people irrespective of where they are.

Today, we got someone who moved from our Support team to our People Ops team. She lives in Kenya, and she mentioned that she’s regularly late for airplanes, which was a fun fact. We see people from all kinds of places all over the world, and because we don’t have a headquarters, nobody is, like, in a satellite office. Everyone is on an equal playing field. And we did that from the beginning to be on the same level as the wider community.

We work in our open issue tracker, so you can see the real work going on, all kinds of things, but also like a marketing and finance issue trackers – how we run the company. Not everything can be public but a lot of things are public, and you mentioned the handbook is over 3,000 pages with all of our processes.

Regarding hiring, it’s a pretty conventional part of our process. There’s different interviews, it’s all done over video – unless you are local to someone, you can meet up if you want – but most of the time, it happens over video. We make sure that people can get a good feel of the company before they join, so you kind of know what you’re getting into.

We recently hired Mike Pyle, our new VP of Enterprise Sales, and we said afterwards “Zero surprises, like I was completely aware of what I was getting into.”

We like to do it that way, and that way we can retain people longer.

What If GitLab Changed License To Commercial

Michael Schwartz: Here’s sort of a question from left field… If you made GitLab commercial tomorrow, do you think that it would negatively affect the business?

Sid Sijbrandij: I assume you mean that from tomorrow on, all of our code would be completely proprietary? Of course, we cannot take back the code that’s already there, so what would happen is that someone would fork the project almost immediately. There’s over a hundred thousand organizations using it, and a lot of them would like to see it open source.

I do think that short-term, we’d probably make more money. There would be more people willing to pay for the support and updates that would, from then on, only be available if people pay us.

But the flow of contributions would stop.

There would be a fork. I think the fork would not attract as many contributions as before. There’s confusion, there’s no merge request coaches anymore, there’s no people helping to get stuff over the finish line.

Both projects would peter out.

Our commercial variant would see almost no contributions, and the open source fork would have troubles kind of keeping up with the rate of contributions, and bugs that get released there – we pay full-time people to handle that, and they won’t have that.

I think our numbers would look better after a year, but if you look at a 10-year outlook, it wouldn’t end well for us, and it won’t end well for the community. We have stewardship promises, which you could Google by typing in “GitLab stewardship,” and we intend to keep those, and that includes always keeping this open core model.

SaaS GitLab

Michael Schwartz: You initially launched a cloud-hosted version of GitLab.
And we’ve heard from other open source entrepreneurs, particularly Eliot Horowitz from MongoDB, strongly advocate for a cloud model. But in your case, there’s another very well-known company called GitHub that is in a similar business – so you’re sort of in a unique position.

I’m curious about your thoughts about how you see the cloud-hosted version of GitLab progressing, and where you think that fits in the market?

Sid Sijbrandij: GitLab.com is our SaaS version. We tend to not call it “cloud” because most of our self-hosted instances, self-managed instances, are also hosted in the cloud on AWS, or GCP, or Azure.

But our SaaS business is growing at a very rapid pace, people are embracing that. We invested a lot of time and money to make sure it’s a great experience.

In the beginning of GitLab, I think we had an edge in that GitHub was paying more attention to their SaaS version than their self-managed version, and that was a way for GitLab to enter the market.

Although we’re still strongly self-managed, by now the product is so complete, that people that want an end-to-end DevOps experience don’t want to be maintaining all their tools, and they’re flocking to GitLab.com. So we’re seeing strong growth there.

Open Source Challenges

Michael Schwartz: What do you think are some of the biggest challenges facing open source startups today?

Sid Sijbrandij: One of the most obvious ones is how you monetize a product, and the threat of the hyperclouds commoditizing your product.

I did a talk about this on the Linux Open Source Leadership Conference. And I talked about like, how big is that threat?

I think it’s differs a bit from company to company. But if your product is kind of a service that other things are built upon, like a database for example, that has a limited API, and it’s already offered as a service by hyperclouds like AWS – there is a risk that they will kind of take the project over, or what they did in case of Elasticsearch – they forked and commoditized the project.

And that is within their rights, but that makes it harder to kind of start-up around open source. So people are exploring different licenses.

At GitLab, although that risk is there, it’s reduced. Although we have APIs, it’s also a user-facing application, with a user interface. And currently it’s not offered as a service by any of the hyperclouds.

So for us, the problem is less acute. Also, for us, it would not be possible to change our licenses as others did, because we switched to DCO, a Developer Certificate of Origin. So if you contribute to GitLab, you retain the copyright on the code you contributed.

Hypercloud a Victimless Crime?

Michael Schwartz: So, to play devil’s advocate a little bit. The companies – for example, MongoDB or Redis or Elastic – they haven’t exactly lost a lot of value. Is it really a victimless crime because they seem to be doing better than ever?

Sid Sijbrandij: It’s great to see open source doing great. I think we’re able to build companies on open source projects – that didn’t used to be the case, and now that’s possible. So, that’s a great benefit.

I think the whole industry is watching what’s happening with open distro for ElasticSearch, and whether that will bite into the monetization that Elastic, the company, is able to do.

Advice For Entrepreneurs

Michael Schwartz: The last question is more about the people than the company.

You’ve had quite an amazing entrepreneurial journey, and I’m wondering if you have any advice for the people who are starting these companies. What advice would you have given yourself if you could go back in time?

Sid Sijbrandij: I think one of the things I did that I thought was kind of a bad thing but turn out to be a good thing, is I optimized for interestingness. And if I find something interesting, I dive into that, and I follow that.

And it’s served me really well. And I thought that was a very selfish thing – I did it because I liked it – but it also tended to lead to great business outcomes.

So if you follow your own interests, it’s more okay than you might think.

Credits

Michael Schwartz: Sid, thank you so much for joining us today.

Sid Sijbrandij: Thanks for having me.

Michael Schwartz: Thanks to the GitLab team for helping to organize the interview.

Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke For Free and Chris Zabriskie.

Our amazing audio editor is Ines Cetenji.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

Follow us on Twitter! Our handle is @fosspodcast.

Tune in next week for an interview with John Newton from Alfresco, one of the first pure-play open source companies. I’m sure John will be super interesting.

Until then, thanks for listening!