 Thank you so much, Jim, for that introduction. Hello, everybody. So as we discussed today, I'm going to talk about open source and startup business models. Just to put a little bit of perspective on my background with Jim, I already shared so well. I work at GitLab, which is a complete DevOps platform delivered as a single application. Great one-liner, our marketing team came up with. And also serve on the board of the CNCF, which is home to very key DevOps projects, such as Kubernetes, Prometheus, Fluendy, Yeager. And I contribute to some of them as much as I can in my copious free time. I spend a lot of time on Twitter, so you can always find me there, here's my handle. Feel free to reach out after this talk if you want to discuss further. This is my first time in France, and I'm so excited to be here. I'm based in San Francisco, and I've always heard just how amazing the food in France is, et cetera, et cetera. Having never been here in my adult life, I didn't quite know what to expect. Yesterday at dinner, I had fresh cow's milk cheese. And as someone who grew up with dairy cows at home, I thought I knew all about fresh cheese. No, no, they do it way better here. All that is to say, I'm so happy to be here, and thank you to the Linux Foundation for hosting me. So let's get down to business. What are we going to talk about today? Well, the key thesis of my talk today is that commercial open source companies, or companies that are based on open source projects, are solid net positive for the open source community. But they face a lot of challenges building a business, just as any company would. But there's specific nuances here. And in the age of hyper-clouds, which is the big cloud computing renders, building an application software and monetizing it with a particular business model called buyer-based open core can be a very successful strategy in being successful, well, successful strategy to having a solid business. And in this talk, I'll share the details. So this is a brief overview of what we're going to go over today. The SCQA framework is something that I follow a lot. It's, I think, the Minto pyramid, highly recommended for people if they're structuring their talks. So the situation, or the S, is that commercial open source companies, in my opinion, augment the open source ecosystem. But there is a risk that they could be totally annihilated if they're forked and commoditized by hyper-clouds. So how do you manage that risk? Today, I'll share how our perspective at GitLab, which is by building an application software and monetizing it with buyer-based open core, we've been able to be more resistant to the threat. If we have time, I'll go into the case study of how we chose the business model and defined our pricing. And hopefully, this will be useful to some folks in the business who are considering side businesses or monetizing their work, many, many ways. And also, even if you don't want to start a business, as you utilize various products, it can be an interesting perspective to know about. So open source and business have been so closely connected since forever. This is pure Wikipedia fact. In 1953, what looked like the first open source project by a company, A2 System, came out by Remington brand. Over the years, software became copyrightable. Then Netscape was open source. And the big companies like Sun, Oracle, Microsoft, everyone has been in the news so much in the last two decades, I would say, in relation to open source. In the last five to eight years, I will say, though, things have changed in that a new breed is gaining traction enough to be a mainstream discussion point. And that is commercial open source software companies that get started every day. So let me quickly define commercial open source software. These are companies that fundamentally depend on a single core open source project for their existence. And they wouldn't be there if this project didn't exist. By nature, they are the exact antithesis of the proprietary software companies, which are the more traditional models that we have seen come out as SaaS products or commercial off-the-shelf products. So great examples of commercial open source companies are, for example, Elastic Search, which is based on Elastic. Cloudera, which is based on Hadoop. GitLab and GitHub are based on Git. And there's such a long list. In these slides, which will be available later, you can see a link to a spreadsheet which catalogs over 50 of such companies. The proprietary software is more traditional, as I said. So SAP, Oracle, Workday. Most companies are FPS. In my opinion, commercial open source is a net positive for our ecosystem. It takes open source and makes it go beyond the domain of large enterprises. There's a bigger diversity of contributors who come in, because there are different kinds of motivations to contributing to open source. There is two sides of the coin, so there can be good and bad. But net net, more people contribute, more open source software is generated. Contributors often have skin in the game if they're part of a commercial open source software startup, because they're so excited to build their company, et cetera. A really good example of this net positive effect is if we look at the Kubernetes ecosystem. So much great work has been done there. So many amazing companies came out of that ecosystem, because this cost thing has taken off. So now that I've level set a little bit about how we define costs and my perspective on their value, let's talk about the risk that they face of being forked and commoditized by hyperclouds. So the hyperclouds are service wrapping these commercial open source projects. So examples, as you can see, confluent the cost companies based on Kafka. And there is service wrap projects available both on AWS and Azure for using, basically, managed Kafka service. And there are other examples, MongoDB, Elasticsearch, Redis. And that can be very threatening for these cost companies just because suddenly their bread and butter, the value add is forked and commoditized. Of course, they had to think of a business reaction to that. So we saw non-compete licenses come about. There are many perspectives of these on these non-compete licenses. There are different versions like SSBL, there's special ones like Confluent Community License, Commons Laws, so many different things. There are different takes. And when that happened, the community's reaction was pretty hot. There was a lot of opinions and many people thought this was, in some ways, a betrayal. And then, of course, there was a counter reaction. When this was all happening in the earlier part of the year, it was very much like biting my nails, checking Twitter every day. As AWS launched an open distro for Elasticsearch to combat the special license that had come out. So things like that can be very damaging to a company that's based on an open-source project. So how do you manage the risk? As I mentioned, at GitLab, we do that by building an application software and monitoring it with a buyer-based open-core model. So let me talk about these two aspects and why they are, in our opinion, more resistant to being forked and commoditized by Harper Clouds. So application software is antithetical in this conversation to what we call infrastructure software. So application software is top-level. People interact with it very, you know, you often have a GUI and people are using it as a product. Good examples would be GitLab, WordPress. Infrust software is different in that the application software is built on top of it and so this is kind of the middle layer and people often consume it in the form of APIs. So things like MongoDB, Confluent, Redis, a lot of these people. When we think of these two, infrust software versus application software, application software is very clearly much more resistant to things like forked and commoditized. The first piece being the graphical user interface versus the API consumption model. It's just a fact that a GUI is much harder to replicate by anybody. So it's a lot more work than working and commoditizing an API-based system. Another thing is often application software is multi-tenant and the reality is that hyperclouds are very, very good at running single-tenant software like Amazon RDS for databases and so it's a little out of their wheelhouse. And then finally, and I think this is a really key point, application software doesn't need that much compute power and for hyperclouds the key business is driving compute so it's less interesting as compared to infrust software. Now let's talk about the second strategic piece in our arsenal which is buyer-based open core. It's quite a mouthful but it's a pretty great business model. So again, I'll compare and contrast buyer-based versus other options. So first off, open core. Open core means there is an open source layer and then there's proprietary features baked in into the product that a company offers. And then what type of open core you are determines how you price different things. So buyer-based open core is a business model where tiered features are targeted to different personas, different likely buyers and they're embedded throughout the code base and it's very tightly knit to a unified experience and so it actually means that it's not easy to keep these functionally separate. So that's just a fact to know. Module-based open core is where you charge for different parts that are functionally separate. So that means there's fewer proprietary features and single use cases and often the buyers tend to be and the end users which is the developers who tend to be more price sensitive. In terms of just to illustrate for you just how sort of weaved in the buyer-based open core products tend to be, at GitLab it took 1.5 million lines of code to combine the open source and proprietary code in the same repository. It's a lot. So some key features of buyer-based open core. There'll be certain features that are paid in the sea of a lot of open source free stuff and the cost and tiers are based on the buyer. So you'll have ICs, individual contributors and ideally everything is free for them. Then there's the managers who have some team dashboard needs and you charge for that, then there's the directors who need to look at org levels and you charge a higher price and then there's the executives who need dashboards that give them the health of their entire organization and you charge ideally a lot more for that. Everybody in the company, whether it's the IC or the executive is on the same plan and that really helps a from monetization but also because everybody gets the same features. So adoption of the product can just grow, grow, grow and perhaps the tiers also enhance over time. So let me quickly share why buyer-based open core and application software are much more resistant to the fork and commoditized problem that commercial open source companies face from the hyper clouds. Well, a key trait is if a lot of open and proprietary features are deeply embedded and mixed together then the features that executives want are across use cases and so it's harder to separate out the proprietary and open source and it's just harder to fork and commoditize. The more proprietary features that are sprinkled throughout the code base the better it is for the business. If the buyers are price sensitive then that's just bad for the business and also just not very healthy for the ecosystem because ideally you want your buyers, your end users to be contributing code back, to be participating in the community but if there's a tension between the business's desire to monetize people and to get open source contributions from them that's not healthy. If there's a user interaction through the GUI which will be the case when it's an application software as I said it's just that much harder to replicate and then we've already talked about multi-tenancy and the need for compute as factors in resisting fork and commoditize by the clouds. So I gave you a somewhat theoretical story of things that work but how arriving at these at least for us at GitLab has been an iterative process and it's something that we came to over time. So I'll quickly share with you the things that we tried that didn't work and that led to this final realization of application software being more resistant and buyer based open core being more resistant. So as I said, GitLab is a complete DevOps platform delivered as a single application so it's a very big project, sorry. All right, there we go. And it was incorporated in 2014 and over time we're now at over 1,000 employees. I blink and there's more people in the company so this slide is slightly out of date. And we recently raised $268 million in a series E funding and that's been great and it's happened because we've had broad adoption, 100,000 plus organizations use us with millions of users. And we have a very strong community with over 2,200 code contributors. And to get to this point, there were lots of things we tried, as I said. So there were many business models we considered and I'm gonna go through these in the pros and cons. First, Sid, our CEO when he started building GitLab was like, I'm going to sell GitLab.com to be the next sales force. People actually wanted the self-managed version and at the time not that many people use GitLab.com. Donations-based model. It's very similar to what Wikipedia does and there's lots of other success stories there. For us, in the best case scenario, we made 1,000 bucks a month and usually it was more like ice cream money for Dimitri, the creator of GitLab and his wife to go have an ice cream date. It's $7 in every month. That didn't work. Then people looked at consultancy which is helping people set up and upgrade GitLab. But here there was a perverse incentive because if they improve the product, improve the documentation, which is the right thing to do for the open source project, which is the right thing to do for the product, the fewer people need consulting. So that wasn't good. Then paid development. They thought they would do paid development for new features in GitLab based on demand. It got really complicated because customers wanted to share the cost. If multiple of them wanted the same features, sometimes they wanted to bring their own consultants and then the GitLab team was spending all the time working with the consultants and making their code production ready and it was just not worth the effort. Support. Another perverse incentive because if you have an easy to use product with good documentation, people have fewer support issues. People would buy the yearly license and then not call the whole year so everybody started cancelling. So that didn't work. Packaging. Well, Red Hat has done this in the best way possible but for us, we figured it hindered adoption because the free versions are not as good as the golden anointed version. They're not secure, not stable, not easy to install. It just didn't feel like the right stewardship. A single tenant service. We thought about that but it was just very complex to build and operate and there was overlaps with GitLab.com. It was just complex so we were like let's not do that. There were things we didn't try out, of course, and one was selling some kind of hardware option solution, some data play and we considered an initial coin offering but then decided let's not go to jail. And then, finally, we landed on OpenCore where some parts were open source and then some parts proprietary and it was awesome because successful models have 90% plus margins. That's the kind of business you wanna be in. But then, what is open source and what's proprietary? You wanna be the good steward of the project and at the same time have a healthy business. How do we define our pricing? Well, we considered lots of options. First was based on the software development lifecycle stage to whether you're just, you know, the development side, the operation side but that hinders adoption across the entire DevSecOps lifecycle reducing the value of the product. It is a core belief for us that the software development delivery needs to be one integrated experience and people need to be in contact with each other whether they're developers, security people or operations people and that just doesn't happen with this kind of pricing model. It silos people based on company size. This one was interesting because there were very small companies that wanted the whole thing and they wanted to pay for it all and focus on what they were building and then there were big companies that just wanted to use, let's say, the version control. So it wasn't if, and the opposite was also the case sometimes. So there was no real divide and feature needs by size. Then based on digital transformation maturity. So how advanced are people in the DevSecOps transformation? How in the Kubernetes landscape are they? Well, the thing was that the people who were willing to pay the most were people who were fairly early in their transformation. So we couldn't justify charging the more mature people more money. Maybe we could have tried the other way around but we didn't do that. Then we landed on buyer based open core and their tiers up based on the buyer person are regardless of company size and maturity and that worked. We also had some pricing fails along the way. So it wasn't just like win, win, win. So we sold one of the first enterprise licenses. Say it tells the story, I said our CEO tells the story of how there was a Fortune One company and he was so excited that they were interested that he was like, I'm going to charge you $1,500 in the enterprise license. Then turns out they ended up spending two years building features for that company. Luckily, it worked out because they were a good barometer of what the ecosystem wanted. They also did module based pricing which was just crazy all over the place and that didn't work. So just FYI for anyone starting a business here, consider this as you go through the things and don't undercharge your first enterprise license. Be confident. And today we have the good, better, best paid tiers and as you can see, there is a five X price difference between each tier which is great because there's clear demarcation and also there's between the lowest and the highest there's a 25 X difference. So it's a really healthy business model and at the same time, please notice that the core is always free for individual contributors. They get everything of the entire DevSecOps lifecycle. It's because we're based on open source, it's the right thing to do and it's the right stewardship of the project. So to recap real quick, it is my opinion that commercial open source software companies are a huge niche positive for the open source community. I think it's good for us that this healthy frothy ecosystem exists. The Kubernetes landscape is such a great example of what can be with a lot of commercial open source but there are myriad challenges to building that business and one of those challenges is the threat from hyper clouds being sort of getting service that does a commercial open source project. Being an application software where you have a GUI and are multi-tenant and being a buyer based open core model has been a resistant way for us at GitLab and we're just a case study. So as you consider your work in open source, your contributions and sometimes consider maybe building a business or have ideas, I hope this presentation is useful for you. I hope you will all keep contributing to open source, keep doing the great work and being part of this community. Thank you so much. Thank you so much. Thank you so much.