April 2, 2020
Ep. #13, Two-Way Video and Beyond with Sarah Allen of Veriskope
In episode 13 of Demuxed, Matt, Steve, and guest host Nick Chadwick speak with Sarah Allen, partner at Veriskope. They discuss implementatio...
Thank you. Thanks for coming tonight. Thank you for being here. I hope to add some value by talking about how we arrived at the buyer-based open core business model we arrived at. I'm a co-founder and CEO at GitLab, and we are a commercial open source software company. We build application software. We use something called buyer-based Open Core, which I'll elaborate on. We think it might be a great way to commercialize open source software.
First, a bit about GitLab. GitLab is a single DevOps platform. It does everything you need from planning what you want to build, to rolling that out, and monitoring and securing it. We went from being version control, which you can now find under the "Create" category source code management, to doing everything you need to make software. All the way from value streams to network security. So a really, really broad product. We delivered that as a single application, one interface, you don't have to hoop to ten applications to get your code out.
In 2015, I came to the US. We were nine people at the time. We're now 900 people in the company. We don't have any offices and we mostly work from home, or some people from a co-working space. But we don't congregate together we are an all-remote company. We have people in over 50 countries that work for GitLab, the company. We also have a lot of people that contribute to GitLab who don't work at the company. Of those people, more than 2,000 have contributed code to GitLab. The first thing I want to talk about is the threat that commercial open source software is under from the hyper clouds.
The hyper clouds AWS, Azure and GCP are service-wrapping open source. For every big open source project there is an equivalent on the hyper cloud, and in that case the open source software makers, they don't get paid. It's the hyper cloud that gets all the revenue.
To prevent that from happening, many of the big open source players introduce non-compete licenses, which are similar to open source licenses where everyone can use it for free with the exception that if you are providing the software as a service to other companies, you can no longer do that. If you're a hyper cloud, it prevents you from using that.
It makes sense that they did that, but also there was a reaction from the community. Some people understood, and some people said "I understand, but this is no longer open source." There is the risk of losing the things that make open source great.
There was also a response from the hyper clouds, and I thought it was startling to see how fast and how prepared their response was. Amazon said, "We're going to fork and commoditize Elasticsearch. We're going to take your code that's open source, we're going to fork it, and we're going to try to make all the features that you have as proprietary features, we're going to try to make them open source." That's a big risk for every commercial open source company going forward.
Now , I want to talk a bit about how we manage that risk. How do we try to be less at risk of that as a commercial open source company? There's two ways we do that, being application software you cannot change later on and with buyer-based open core.
Application software is software that's used by the end user. Infrastructure software, for this purpose, is defined as any software that applications are built on top of. Databases are a very popular example. Anything that serves as a component, but that's expected to be used by the application more than the end user.
If you make infrastructure software, people are going to use your API . If you have application software, most people are going to use your graphical user interface. That makes application software more resistant, because it's much harder to replicate a user interface . There is much more fidelity to it, and that's shown for example by Amazon, who introduced document DB with MongoDB compatibility. A completely different back end, but it can still offer the same front end. Something like that is very hard to do with a GUI, but it's relatively easy to do with an API. Most infrastructure software is single tenancy. For every single organization using it, they run a separate copy of the software. It's completely isolated from everything else. Application software tends to be multi-tenancy, like Salesforce, like GitLab.com.
The hyper clouds are really good at spinning up one instance for every customer. They do that for example with RDS and things like that, so the more you look like multi-tenant software, the less you are at risk from the hyper clouds. The last thing that hyper clouds care a lot about in this context is compute power.
They are basically in the business of selling compute and storage, so if your application drives a lot of compute, for example Elasticsearch, a lot of compute. They are more likely to eye that and say, "Look.. That is a good business. We don't want you to run that in your data center or in the data center of Elasticsearch, we want to run that in our data centers because this is what we're good at. We sell compute and we make a good margin on that." In general, and it's not absolute, but in general application software tends to drive less compute. It's further removed from the hardware and it's less at risk of being very clear that it drives a lot of this. The second thing is buyer-based open core.
First, let me introduce what's buyer-based open core and what's not. It's not what you typically think of open core, and which I'll define as "Module-based open core." For module-based open core, you keep the parts separate that are functionally and technically separate. So you'd have-- I think Elasticsearch is a good example, you have the core Elasticsearch packets and then you have the separate management packet or separate authentication packets, that tend to live many times as separate repos or it will separate it in the code base.
It's very natural for a company to draw the defining line between open source and proprietary features at that part where they separate. What you get if you do that, you get most of the time relatively few proprietary features, because there's very few things you can split off like that. You get single use cases that are either in the open source part or completely in the proprietary part, your buyers tend to be more price sensitive, and there's a few other things. Maybe these make more sense in context, so I'll continue to buyer-based open core.
Buyer-based open core is the opposite of module-based open core. It's a business model where you make the features proprietary depending on which buyer they appeal to. If the buyer or the person that cares most about a feature is an individual contributor, you make them open source. If the person is in management or is an executive, then you charge the highest amount of money. It's no longer about "Where is that feature technically?" Or "How much more work was it to make?" Or "Where in the repo does it live?" It's about, "Who cares about this feature? Who cares most about this feature?" Disadvantages of this, it's hard to keep the open source code and the proprietary code separate . At GitLab we wanted to make super sure that those code [inaudible]. We were able to split that code up and it took us 1.5 million lines of code to make sure that we could combine the code, but we could also separate the code because there wasn't a clean interface to cut. So, that's the disadvantage.
We'll get to the advantages, but I want to detail a bit about "What is buyer-based open core?" Or "How does that work?" You split the features up in different tiers, and the higher-paid the role of the person that wants the feature, the higher the tier is that they have to pay for your software. I don't think that in case you have an executive feature and the company wants that, only the executive pays. That's not sustainable. Everyone in a company pays the same price, so if you have an executive and they want features, everyone in the company gets it and everyone moves to that higher tier.
There's a couple of things that are natural if you do this model. It's natural that if you have a single use case, there is a mix of features individual contributors care about and features the executives care about. You start mixing the open source and proprietary features in a single use case, and an example at GitLab is our merch request workflow. Merc requests are pull requests at GitHub, in GitLab we call them merch requests. That functionality is in core, but approvals, if you haven't a very sophisticated approval flow with all kinds of different groups that have to approve, that is a paid feature in GitLab because we found that individual contributors care less about that than managers.
Another advantage is that there tends to be a whole lot of features that higher ups care about that are not functionally separate, that are interwoven in the source code, but it is almost no end to the amount of features leadership wants to see. At least, we keep getting inundated. We have more than 10,000 open feature requests at GitLab. So because the needs of leaders are frequently more complex, there's a lot of features you can build this way, so there's no end to features you can ask money for.
Another great attribute is that executives tend to be less price sensitive. They tend to have budget authority and they can decide to spend money. For example, a lot of the security features at GitLab are proprietary because a chief information security officer has the spending power to pay for that.
Another thing that works out really well in our case is that executives are much less likely to contribute back to open source. You can imagine that if you contribute back to a company, it's a mixed feeling if they monetize the same feature you contributed back. Because executives are less likely to contribute back, you have less of that problem. We're also blessed with really nice customers that frequently don't have any problem contributing something back to a proprietary feature. They're already paying for it, they just want to see it getting better. But it works out better if all the features for individual contributors are open source. You can imagine that if you interact via a user interface, that's much harder to replicate.
We invested GitLab very heavily in R&D, in what we now call "Job to be done," things where we give GitLab a report card for workflows to the entire application. That tends to be harder for hyper clouds to replicate. Hyper clouds are very focused on shipping functions and two [inaudible] teams, and for them very long workflows are not their natural strength. I want to elaborate a bit on how we arrived at this business model, because this didn't come dropping from the air. This was democracy after we tried everything else and failed at that.
First we went for SaaS only, I thought "GitLab.com is going to make the money." GitLab was already around, it existed for one year in 2012, so I did a show Hacker News post and I said "I'm going to start GitLab.com, please sign up here." I had 300 people sign up, so I thought, "I have a business." But the problem was all of those people didn't want to pay. They like GitLab, but they were in it for the freedom and they didn't want to pay anything. We thought, "Maybe donations will help." Dimitri called it "Ice cream money," because it was about $7 a month and we did a really big drive and we got to $1,000 dollars, which even Dimitri in the Ukraine couldn't live on. So, that didn't work.
Then we did consultancy. We said, "You need help with GitLab? You need help upgrading? We'll help you." There were a lot of people who needed help installing and needed help upgrading, and every time we helped a customer we improved the documentation. Because those were not-- It was not their fault that they couldn't upgrade, we just missed something in the documentation, so we found that and we fixed it. We fixed it for many other people, but the business dried up because nobody needed help anymore. We also did paid development, so we said "Look. If you want a feature in GitLab, just pay us and we'll make the feature." Then every time we had multiple people coming in wanting the same feature, and we told them, "You only have to pay half. There's another person that wants the feature as well."
They both stopped responding to our email, so never do that. They will wait for the other person to pay for the feature.
You should have just said, "OK, we will charge them afterwards half." But anyway, lots of coordination costs involved, and also companies have a very hard time paying for software development. We talked with a company, they say "We want this feature. Your bargain, we'll pay for it." And then it gets stuck in purchasing because they have a preferred vendor. They have a [inaudible] development shop that they have a contract with for a very low hourly rate, so they want to use that instead of ours. We're like, "But do these people know Ruby? Do they know GitLab? No, they don't." Then we ended up spending more time developing helping them than developing it ourselves without getting paid for it. So, it didn't work. Don't sell software by the hour. It's a shitty business. Try to get licensing revenue.
We saw the same thing that we saw with consultancy for support. If you make it easy to use, people don't need your support. People were subscribed for a year for incidents. They didn't use it, they didn't place a single call, and they stopped paying for it. We considered a model more like Red Hat where you say, "OK. All the code is out there, it's open source, but if you want the packages you're going to pay us and that's going to be the way we keep it up to date." The consequence of that would be that everyone else would be on a less good version, a less secure version, a slightly older version. We wanted GitLab to spread because open source is all about creating a whole ton of value and then capturing a little part of that, and we wanted to create a lot of value that meant the free version had to be as fast and as easy to install as everything else.
We also tried something that's a single tenant service, competing in the way that the hyper clouds run things, like one copy per customer. I think in the open source world, Acquia that runs Drupal is a good example. It was much harder than we thought to do that, and also customers when they know they have their own instance, they want customizations. They want their firewall, they want their favorite web server, all kinds of requests that we couldn't handle, so we got out of that business. Also considered selling hardware or GitLab in a box, or something with data and ICO , but we didn't want to end up in jail so we settled on open core and it really helped.
If you can just say "This is licensed software," every company in the world is already paying for licensed software. They are used to paying for it. There is extremely high margins, for us it's 90%. The challenge for us was, "What's open-source? What is proprietary? How do we define that?" Because we wanted to give our users predictability, to know what to expect, instead of having to second guess us every time we make a decision.
We considered pricing based on the stages of the software development lifecycle. Plan, create, verify it's open source, and the other ones aren't. But that hinders adoption, and the core benefit of GitLab is that you don't need 10 different applications. In order to convince people to keep using GitLab, we want everyone to have that benefit, so it didn't seem right to us.
Then for a long time we tried to say, "OK. It's based on the company size. The bigger your company is, the more likely you'll need a feature that is proprietary." And it turns out that some small customers have super sophisticated needs, and then telling them "Yes you're a small company, but you have big company needs." It doesn't resonate with them. They didn't like it, it was not true, they were a small company and they had small company needs but they still had the complex approval process or something like that. So, lots of discussion and it didn't feel good.
They weren't happy with it. Then we say, "We're going to charge for the maturity of the DevOps transformation. If someone is using all the features of DevOps, like incremental rollouts and feature flags and things like that, then we're going to charge them the big bucks. People just starting their journey, we'll charge them less." It was almost completely opposite to the willingness of customers to pay, big traditional car manufacturers that are undergoing digital transformation are some of our best clients. Netflix is not one of our clients. So the willingness to pay was almost opposite to how advanced they were in their DevOps transformation. So, it's the opposite business model. Maybe we should have tried the opposite, but we didn't.
We settled on changing based on the persona of the buyer, "Who's likely to care about the feature?" And we're not done yet, and I don't think there's a perfect model. It's also really hard to say which feature is liked most by which buyer. It's a bit arbitrary, but it's working a lot better than every other model that we've tried.
We also did some genius-- I had some genius pricing ideas. For example, there was this Fortune 100 company that wanted an enterprise license for thousands of users, and I heard in hindsight that they had more than $30,000 dollars lined up, but I charged them $1,500 bucks. Then to fulfill the order I had to get insurance, and the insurance was more than $1,500 bucks. We had a negative margin on the deal and we spent two engineering years of work to build the features they wanted. So, not great.
The thing was the features they wanted were very representative of what other customers wanted, so we got great guidance on what to build, which sometimes is super helpful. I also tried to price per module. We just said, "OK. You get the basic subscription and then you can just buy additional modules." That sounds clean, and that has a nerdy appeal. It's an honor system where you just pay for what you use. I later learned that it's like academically proven that bundling works. There's both a supplier and a purchaser benefit to bundling.
There's a reason everyone bundles things in, and this was way too complicated because every one of those modules they had to make an individual purchasing decision.
That took a lot of time, so the sales efforts was enormous and there was a lot of confusion from customers on what they needed. Our salespeople had a super hard time and it was a really bad idea.
So today we charge for three tiers, "Good," "Better," "Best." And we have our open source tier. Maybe a thing to note here is that there is an enormous difference in price. Our lowest tier is twenty five times the price less than our ultimate tier, and I think our open source here obviously is infinitely more affordable than any of those in licensing costs. There's a big difference between what different people are willing to pay, and 90 % of our users are using the open source tier. It's our biggest competitor. Only a few of our customers are on the ultimate tier, but it's starting to add up to significant amount of our revenue these days.
I hope that with the talk today you have an idea of how you can resist the risk of forking and commoditization by the hyper clouds. I hope you're making application software that will make it easier. Some of you are making infrastructure software, and in that case, consider a buyer-based open core model.
What we try to do is we try to iterate, and it's one of our top three values. It's our hardest value. Everyone who joins the company says "I love iteration," and we know that they've never really done it because it's super painful, and we never ship a feature that takes more than two or three weeks to make. Every time we get a really complex request from a customer, we try to see "OK. What's the biggest chunk of value versus time that we can do?" And it has to fit within those few weeks, because we want to get it out in one release, and then we'll take it from there. Then for every iteration we ship, we can make a separate decision whether to monetize that or not.
I do very much believe in customizing for certain verticals. I think if you want to look at a company that's doing a really good job there, it's ServiceNow. They basically have a really good issue tracker, but by customizing it for every vertical they're able to generate a ton of value for all the customers. I'm really impressed with that, and we [only have to live there]. It's a $60 billion dollar company now. I think that's largely on the ability to go into different verticals. So we're certainly looking at that, but for us the biggest challenge today is making sure we got a great product across the lifecycle. That's where our energy is focused, but we will not hesitate to start picking off specific verticals.
One vertical that we are really interested in is data. We think the data lifecycle is broken, and we started a completely new project for that. It's called Meltano, and the general manager is Danielle Morrill. She's here, so if you're interested in that Google Meltano and maybe talk to her afterwards. But really good suggestion for every startup verticalization, sometimes you just change a few labels and a few columns and suddenly it applies to a whole different industry. So, great idea.
Our first 300 people signed up through Hacker News. I did a show on Hacker News and said, "Look. There's this thing, GitLab. It's awesome. It's been around for a year, there's 300 people contributing to it, if you don't want to host it yourself I'm going to start the first GitLab as a service, GitLab.com." I only knew of GitHub at the time, so I said "It's going to be free private repos." It didn't trend on the home page, so I was super sad. I went downstairs to make pancakes and I checked my phone one more time, and there it was on the home page. My wife was like, "Can you finish making the pancakes?" I didn't even say, "I'll be right back," because I think we both knew what was about to happen. I spent the rest of the night behind the computer. People informed me that BitBucket already had free repos and was growing really fast, so it was a good idea but I was a bit late to the market. But anyway, we got the service up and we started inviting those people over a couple of months, and started not making any money.
Luckily I speculated a bit in bitcoin, so I doubled my money from $50 to $100k, and that's how we survived the first couple of years. We kept trying new business models.
That doesn't answer 10,000 users, I guess. For me, it was being relentlessly resourceful on Hacker News. I posted a lot there. Anything that might be remotely relevant to GitLab, I was in that comment thread talking about GitLab. That's why we got some awareness, and I think a lot of big companies were really looking for an open source solution. Their preferred standard was "First we're going to use open source, and if that fails, we'll go for a proprietary solution." That was about happening at the same time we were starting up, 2013-2014. I think that's a big advantage if you're an open source vendor, if you haven't a proper open source license, then really big companies that are more advanced will consider that first and will be willing to help you to improve the product.
The tiers we do are not based on the sales model. On one hand, we have a hybrid sales model. For SMB, small/medium businesses, it's self-serve by our website. For mid-market it's inside sales, people reaching out but not visiting you in person. And at the top end of the market a salesperson will come by with a solution architect and everything. We make 72% of our ARR on the enterprise side, but we do want to serve the entire market because the SMB part of the market is where probably new competition is going to arise from at some point. So you want to serve that as long as you can, and even the people, even these SMB companies buy our highest tier.
Even some of the biggest companies by our lowest tier, so there's not a big correlation there. We thought that, but it wasn't a case. We first started with the first tier, you just start charging for something, and then we realized we way undershot on price so we doubled our price. I don't think we lost a single customer, but every customer said "This makes a lot of sense. It makes sense for you to do this again, but you're not going to do this again because we'll get really angry." So, it wasn't possible to raise the price further. What we then did is we introduced a new tier, and I've read in the literature that a free pricing tier is the standard. So, let's do that. One of our sub values is boring solutions. Then I gave a presentation during my A round about the total addressable market, and I said, "We're going to charge $1,000 dollars per user per year," because that was easy to calculate with. Then they asked how much we were charging at the moment, and it was $20 dollars.
Nobody in that room believed we'd ever get to $1,000 dollars. But I promised it, so I figured "OK. Our best thing, maybe we might never sell it, but it's going to be that."
Then I split them the difference down the middle, and then when the middle one was generating more than half of our revenue, we introduced the new top tier. We did very heavy discounting in the beginning, we e-mailed everyone "You can get it for almost the same price, etc." Just to get people started with it, and then shipped great features like crazy, a lot of security features. It continually builds value, and I don't even think we're at the top. We now have people buying this with more than 1,000 users full price. It's $1,100 dollars per user per year, and I think there is room to go. Developers, operations and security people are the highest paid people in many companies, and you can make them more effective. People are able to bring the time that they take to release an application down from weeks to minutes with GitLab. You can charge even more than $1,000 dollars. So, I really underestimated.
I think it's a typical beginning technical founder mistake to underprice, and the way we solve that is just by going to new tiers. We never took a feature away from someone, and I think people are still very-- That's why people accept us introducing new tiers. If I had to do it over again, I'm not sure we would have tiers at these super low prices, but it might be in hindsight a really good thing that we have because it's eating-- Like, every tier has different competitors. Our lowest tier is probably competing with Atlassian BitBucket, and our highest tier is probably competing with software from Computer Associates and people like that. So we're able to have one product and many types of clients, and many types of competitors. It might end up being a good thing, but it was incompetence that got us to there.
I wasn't aware of BitBucket. I was aware of GitHub, but all the software I used was open-source. I was on a Linux laptop and every single piece-- I used to be a Ruby on Rails consultant, so everything was open source except for the collaboration software. I always found that really ironic. How could it be that collaboration software is stuff you cannot contribute back to? If anything, that should be open source. So when I saw GitLab I was like, "Yeah. This makes so much sense." It was really this, "This is a logical" idea. I opened up the project and the code base was pristine, and already 300 contributors had been merged in. Most people who start something in their spare time who don't have plans to monetize it, they try some new framework or some new way of programming or something and they mess up their code base. This is just idiomatic rails, so this might have legs.
Yeah, it was a big boost to our business . In that press cycle we got 23% share of voice, which is remarkable. Our next competitor, Atlassian, was at about 3%. So people took note of that, "What are the alternatives?" They looked at GitLab and they were like "GitLab is more than version control. They can do all these things. That's neat."
And the other thing that happened is that companies are realizing they are going multi-cloud, and to do that they need workflow portability. They need to work the same way irrespective of what their deployment target is. They need the same productivity metrics, they need the same security systems, they need the same compliance. We're an independent provider and they tend to reach out to us earlier than someone who is aligned with a hyper cloud and probably bought GitHub to steer more traffic to Azure.
We never make someone change to a new tier, we're not adjusting for inflation yet just because we want the conversation to be "Should I be using a higher tier?" So what we're trying to do is getting people to up-tier. We're not super good at that yet. They all say, "We love the product, we don't need anything else." So we have to do a better job at that. We do have great net expansion, so our net expanse is way north of 150%. If you take a cohort of customers next year, it's way more, and that's two thirds of that is driven by seat expansion. Just more people in the company using it.
Thanks for the mentioning the handbook, we have a handbook of over 3,000 pages. It's all public, just Google "GitLab handbook." If you like pricing like we discussed today, there's a lot more to pricing if you type "GitLab CEO Pricing Handbook," you'll find a page with everything we think about regarding pricing, like why you should invoice a year up front, etc. All those things and everything we thought through so far. Thank you very much for your attention and the questions on the conference, I really appreciate it.