SID SIJBRANDIJ: Thank you for that introduction, Jim. I feel really small. By the way, all remote companies, if you want to swipe our handbook like Jim did, go ahead. It's Creative Commons so it's totally cool. So I'm going to talk today about commercial open-source business models and specifically about how in the age of hyper we bet on buyer-based open core.
A little bit about me. My name is Sid Sijbrandij, and if you can't pronounce that, that's totally fine. I'm a Co-founder and CEO at GitLab, and GitLab is a commercial, open-source software company. And what's unique about GitLab is that we're the first single application for the entire dev ops lifecycle.
So in a single application, you can go from planning to do something, creating that in a web IDE running the test, looking at the performance of your site, packaging that up, securing all that with static and dynamic tests and dependency and container scanning, releasing that out to incremental rollouts, configuring that, operating that, monitoring what the result is with metrics and logging, and defending that against attacks.
Now, that approach has been amazingly successful. We incorporated in 2014. We were five employees at the time. We're now over 500 people in 50 countries, all remote, all working from the location we prefer. And GitLab is a use with millions of users with more than 100,000 organizations, but I think the number I'm most proud of on this slide is that we have over 2,000 people who contributed back code to GitLab.
As we've grown as a commercial company, we've been able to keep the community with us, and every month, there's more than 100 improvements in GitLab that come from the wider community. There should be a lot of familiar logos on this slide. One of our customers I'd like to highlight is Goldman Sachs. They went from releasing from a cycle time, from a time to determining to do something and then getting it out there, of weeks to minutes.
It was such an improvement for the organization that they decided to invest in our last round off their own balance sheet. I think that's the most genuine compliment you can get from a financial institution. I think the biggest challenge that commercial open-source software companies face today is how to deal with the hyper clouds, and we're seeing that they are so-called service wrapping open-source projects.
So you have commercial open-source companies like Confluent who make Kafka, and then the hyper clouds take the open-source code and offer that as a service, competing with the SaaS services that these companies were betting on to generate revenue. The reaction of the commercial open-source software companies was the so-called non-compete licenses.
These are licenses that say, hey, this is open. You can use this. You don't owe us anything. You can do all the things you were doing while we were still open source, but you cannot compete with us. We will not allow you to offer a software as a service that competes with our offerings.
Until recently, it was unclear is this open source or not. On Friday, MongoDB decided to retract their license from review by the Open Source Initiative, and I think now the consensus is that this is no longer open source. Open source means you can take the code and you can start competing with us, and this no longer allows that.
The reaction to these licenses has been mixed. I think many people like these companies and what they've built, and they wish them well. They wish for them to do well, and they understand they need a business model. On the other hand, we also love open source and we love the lack of lock-in that comes with open source, the ability to pack up our stuff and go elsewhere.
And that's a freedom that these licenses don't offer. Now I'm also a business owner, and at some point, GitLab might embrace one of these non-compete licenses. I'm not saying no to them. I understand why these companies did it. But so far, we haven't, and that's what I wanted to talk about today. But before that, something that happened yesterday, there was a counter-reaction and I think it was a really smart one.
AWS has customers, and those customers were using the open-source version of Elasticsearch. And Elasticsearch is an open-core model. They have both proprietary code and open-source code. And what Amazon did is they forked and commoditized that. So they offered an alternative distribution, and in that distribution they took many of the features that people pay Elasticsearch money for like encryption and they made that open source.
They went directly after the value that people pay Elasticsearch for. I think this is a very interesting development, and we're going to see how this plays out. But it's clear that commercial open-source companies are now vulnerable to this fork and commoditize by the hyper clouds. How do you get resistant? How do you resist getting forked and commoditized?
I don't have all the answers, but here are some things we believe currently at GitLab. We believe it's more easy to be commoditized if some use cases are completely proprietary and some use cases are completely open source. We think it's more easy to be commoditized if you have fewer proprietary features because it's easier to replicate those.
We think you're more likely to be commoditized if your users work through an API. If users were to user interface, that is hard to copy. An API is a much more limited set of interactions, and you saw Amazon do this with MongoDB. Amazon now has a MongoDB-compatible offering that doesn't use any of MongoDB's source code on the back end. They made it on top of Aurora, also because MongoDB's AGPL and Amazon is hesitant to use that license.
But if the interface is just an API, it's much easier to get displaced than when you have a richer experience with your user. Another thing is the price sensitivity of your buyer. If your buyer cares about saving money, they're much more likely to flock to an open-source alternative for your product, for your paid product. And lastly, if your users frequently contribute to open source, they're much more likely to open-source the features that you ask money for.
Later in the talk, I'll show how buyer-based core is on the right side of this. It's less likely to be commoditized. But before that, I want to go back a bit to how we found our business model. We kind of did it like everything we do at GitLab. We stumbled along. We call it iteration. And it started with so-called ice cream money. Now ice cream money were the donations that people send Dmitry.
Dmitry was living in the Ukraine and he got about $7 of donations every month, and he and his wife went out from that money and bought ice cream together. At the highest point when we did a big drive, it shows that I'm not Jim because Jim can get $10 million. I got $1,000, so even a big drive couldn't even get the money to sustain Dmitry, and Dmitry was living in the Ukraine and getting his own water from a well every morning, so like even that didn't sustain him.
Then we tried consultancy. So we helped people to set up and upgrade GitLab. The problem was the easier we made that, the more we added to our documentation, the fewer people wanted our consultancy services. So we put ourselves out of a job. Then we did page development. We said, hey, there's so many people wanting new features in GitLab. We'll make them for you. Just pay us.
And people signed up and said, OK, I want to pay this much. And then other people came in and said, I want the same feature. We said, oh, we have good news. There's another company that wants the same. You pay half. And then both of them went dead because both of them were waiting for the other to pay. Worse than that, they said, hey, we have a preferred purchasing agreement with another company. They do all of our software development. We'd like to contribute to a feature.
We're like, OK. Well, they normally develop in Java, but they can do Ruby and Go too, and we ended up spending more time getting their code up to snuff than we would have spent making the feature ourselves, and we didn't get paid for it, so that didn't work. Then we tried support. You know, who you're going to call, GitLab.
But after a year, most people haven't picked up the phone once, so they didn't use it. They canceled their subscription. We tried packaging but we were a bit reluctant. Redhat does a great job with packaging, but we wanted GitLab to be used by everyone. We wanted, first of all, large companies to use it, like they do now.
But the problem was if you make your golden version, your great version, if you make that proprietary and you give everyone else a version that's behind and insecure, you're not going to get that adoption. We thought about the data play. We thought about gitlab.com. I started gitlab.com thinking, this is the new sales force. This is going to be great. But everyone was running it self-managed, so that didn't work.
We tried a so-called single-tenant service, your own GitLab server without any other people on it hosted by us. Turns out that's a lot harder than it sounds, at least for us. We didn't even go to the appliance store where we sold hardware, and we didn't want to end up in jail, so we didn't do an initial coin offering.
We settled on open core like most open-source companies. It's a great business model. It's 90-plus percent margins. It's almost all profit. But then we had a much harder decision. What is going to be open source? What is it going to be proprietary? And you want some predictability there. You want people to say, hey, I can predict ahead of time what are you going to charge for.
We tried to do it based on the SDLC stage. So like everything in Create would be open source, and everything in Monitor would be proprietary. It really hurt our adoption across stages. We tried to base it on company size. The bigger your company is, the more likely you'll want certain features, and we'll charge for those. Didn't really work. There weren't features that big companies wanted that small ones didn't want. So some small companies said, why do I have to pay the big company price, and they're the big company.
And the last thing we tried that didn't work was based on the maturity of the organization. The more mature an organization, they want certain features that companies just starting don't want. The problem is our most expensive plans were for the very mature organizations, but the customers most willing to buy were people just starting with the digital transformation. They needed the most help. They were the most willing to pay. So it didn't match with the willingness to pay.
And we settled on buyer-based open core, and I'll explain how that looks. So we have four different editions of GitLab. Our open-source edition, our core edition, is totally free, and then we have three paid editions ranging from $4 to $99 per user per month. Our most affordable edition is aimed at managers in the company. Our most expensive edition is aimed at executives in the company.
So managers want things like automation and stability and reliability. The executives want to have overview in their company what's happening, roadmaps, value streams, security dashboards across the entire organization. We also have kind of different ways of reaching people. Free product, developer advocacy. You start a product, it's self-serve. You sign up online.
The premium product in the middle, it's inside sales. You can talk with a salesperson, but in the end, you sign up via the website. The top one, enterprise sales. Someone comes to buy your organization. They bring along a solution architect, and it takes a lot longer but it's a much bigger ticket size. So buyer-based open core means putting features in pay tiers, and the type of persona that would buy determines where things go.
And the higher someone is in an organization, the more you ask, because the higher are people up, the more budget they have. And the three tiers, it's pretty classic. You do good, better, best as your three variants of your product. What's remarkable is that we have a big price difference between the tiers. It's 5x, which makes for a 25x price difference between the lowest and the highest paid offering, and that helps us compete both at the bottom end of the market and at the high end of the market, but you need a hybrid sales strategy to pull that off. You need different ways for people to purchase it, purchase the product.
Now back to that initial slide. Why does buyer-based open core help with being resistant to being forked and commoditized? So you're less likely to be commoditized if you have more proprietary functionality and if you have that kind of interwoven in the application. That's great because executives normally don't want something that nobody else wants. They just want a better overview, so almost everything has some kind of a dashboard, a company-wide overview that you can get to executives.
You're less likely to be commoditized if you have more proprietary features. Well, executives turn out to have an unlimited supply or feature requests. It is amazing what the complexities of organizations at scale. So there's always something new for us to add to the application. You're less likely to be commoditized if you interact with the user interface, which is great. Executives tend to use the web interface of GitLab and barely use the API.
You're less likely to be commoditized if someone is price-insensitive. Again, this fits really well. Executives tend to have budget authority. They can afford to spend money on something that provides some value. Individual contributors frequently have through go to a big approval process before they can get something.
And lastly, are these people contributing to open source? You'd rather not have a paid feature, really the amount of people that contribute to open source. Here again, it works. Executives tend to not be active software developers, so they're less likely to contribute it. So all of these things work out. So that was what I wanted to tell. We're a commercial open-source software company.
We face a unique challenge from the service wrapping by the hyper clouds. We're right now betting on buyer-based open core, and we think it's more resistant to service wrapping than the other open-core models. Thank you for your attention.
JIM: Hold on one second. I'll ask a question. One thing I always admire about GitLab is like you also have like an incredible internal development velocity within your org. Give us some secrets here. At least give me the secret.
SID SIJBRANDIJ: I think it's one of our values. We have two values that are very different from other companies. That's iteration and transparency, and that means we accept when things aren't done the first time, and it's very painful. I'll tell you an example. I just read a blog post about someone, and he tested our features and he's like, tracing in GitLab is not really good. It's just a link that goes through Jaeger.
SID SIJBRANDIJ: And he's right. That's the minimal thing we shipped, and it feels very painful, but guess what. In the coming months, we'll be piling onto that. But it's taking those small steps really rapidly that is the trick, because every time you take a step, you get feedback and you learn more about where you need to go, and there's less coordination needed to take this the next step.
As an organization and as a person, you have to be willing with, we call it-- oh, actually, it's Ned Friedman's words. The CEO of GitHub allowed me to say this. He calls it living with a low level of shame, so that's one of our company values. We iterate, and we're very proud of our philosophy.
JIM: Yeah. It's so impressive, I can tell you. You literally can see the GitLab at work, because again, we definitely troll your G-Suite docs. We get ideas about how to build culture. It's so impressive. Not nly is the GitLab product awesome, but you really have to check out how Sid is running the company. Huge respect. Thank you so much.
SID SIJBRANDIJ: Thanks again.
JIM: All right, thank you.
SID SIJBRANDIJ: Thank you.