How To Innovate Faster with Community: Insights From GitLab CEO Sid Sijbrandij

From weeks to minutes. The majority of the Fortune 10 is using GitLab, and there's people using GitLab on a Raspberry Pi somewhere. We kind of need to collaborate with all the companies in the world to make a platform that can do everything. Over 5,500 improvements in GitLab came from our users. Open source has shown that there's something better. There's an enormous energy from outside the company to contribute new things to GitLab. 90% of the hires we make is inbound. We get 3,000 applications every week. As we scaled, we didn't have, like, tax because of being remote. We actually did better. The vast majority of the people on Earth, if they want to work for GitLab, they can. Today is an incredible milestone in our journey. I believe we are the first all-remote and the most transparent company ever to go public. Our rate of improvement is growing exponentially. Our product is better because of the people who choose to share their improvements. With the whole world. The most important—

Awesome.

Welcome everyone, thank you so much for joining us at SaaStr Scale and for this next session. Really excited to announce Sid Sijbrandi. He's the CEO and co-founder of GitLab. He's going to be walking us through how to innovate faster with community and sharing some insights from co-creating product with community. Sid, thanks so much for joining us. Before I pass it over to you, just a couple housekeeping reminders. We do have time for Q&A. This is a 50-minute session, so make sure you drop your questions in for Sid into the Q&A function at the bottom of your screen, and he's going to be getting to questions at the end. Sid, going to pass it over to you. Thank you.

Take it away.

Yeah, thank you so much for that introduction. I'm really excited to be here today and share our experience at GitLab as we've developed the GitLab product with a wider community. But first, I'd like to share a little bit about how the GitLab community got started in the first place. So GitLab's journey began when my co-founder Dmitry Zaporozhets created GitLab in 2011 as an open-source collaboration tool while living in the Ukraine. He used the Ruby subreddit and later Twitter to get interest from the developer community, and GitLab received over 300 contributions in its first year. It was the next year, 2012, when I discovered GitLab from my home in the Netherlands, and I was really impressed by their code quality and the open open source community behind it. I thought it makes so much sense that something you collaborate with is also something you can contribute back to. And thinking that software as a service was the future, I asked the people on Hacker News if they would be interested in using GitLab.com, a service. And the community responded. Soon hundreds of people signed up for the beta. As we started a company around the GitLab project, we were pretty intentional in how we defined our community. The GitLab community includes all GitLab users, including the GitLab Inc. team members, GitLab contributors, free users, and paid customers. And when speaking about members of the community that are not company team members, we use the term wider community, and that's a reminder that the community includes every team member of GitLab the company. Company. We, we're part of that larger community. We also try to avoid terms such as, such as community manager. A community is something that each of us as team members are part of and helping. That's something that can be managed or controlled. Building an active community requires intentional effort, and it— but it's very valuable. An active wider community helps co-create the product. Which leads to a more complete product and maturing at a faster rate. It also provides feedback about what is working. It helps us to iterate and improve the product more quickly. And it creates awareness and champions for the product and the company. This wider community is at the heart of our dual flywheel strategy. That strategy leverages both our research and development group and our open-core wider community. By leveraging the power of each, we create a cycle where more contributions lead to more features, which lead to more users, leading back to more contributions. In the third quarter of this year, we introduced over 100 new product features, and from January to, to October of this year, we've merged on average 335 wider community code contributions. each month, a significant accelerant to our development efforts. Next, I'll speak to our open-core strategy. Open-core is a business model in which a subset of the functionality in a product is free and open source, while additional functionality is proprietary and monetized. GitLab is open-core, and our proprietary core is source available. That means that the code requires payment to be used in production, but that anyone can freely download, modify, and submit modifications to the proprietary code. This ensures that all GitLab's code is available for users to contribute to it, whether it's part of the free code or not. Companies like Confluent, HashiCorp, and others have similar business models. That are open core, providing both open source and proprietary features. By making proprietary code source available, customers feel empowered to co-create the product that they need. Customers don't need to sit around and wait until we prioritize the feature they want. If a customer has a business need for a feature, they can contribute to it. Looking at GitLab's wider community contributions from January to October of 2021, where 50% of them came from users in our paid tiers. These contributions in turn help other customers with similar business needs. Source Available can be a good option to consider as you look to co-create with a wider community, but you don't want to open source part of the code. Community leads to people loving your brand, which helps with loyalty, retention, and expansion. At GitLab, our dollar-based gross retention is 97%. Our customers love our product and they love being part of the community. The model allows us to do 4 things: actively invest in a free open source product from which the community benefits, and this in turn helps create product champions that help us grow the wider community. The open core model also enables us to generate revenue from our proprietary features. As I mentioned earlier, customers also benefit from being able to contribute features to the product. And Open Core also enables to do a flywheel strategy, where contributions lead to more users, which in turn lead to more contributions and revenue. So far, we've discussed the beginnings of the GitLab community and the benefits of Open Core. Next, I want to talk about some of the learnings from the past decade. From building trust, fostering community engagement, and building a company around the GitLab project. Commercial models around open source, such as open core, typically face challenges around 3 things. First, the lack of transparency around the direction of the project. Second, putting the company's interest before the project. And third, a reduction in company involvement in our support of the open communication channels. We've meaningfully invested to address these concerns and continuously build trust with our community. First, I want to talk about how we aligned our company values with the open source ethos in order to bring the transparency that the community needs. In 2016, a year after incorporating GitLab as a company, we published a blog post with a clear commitment to transparency. The three parts that form our transparency policy are as follows. First of all, develop in the open. Anybody can submit issues in our public issue tracker, and we also develop in public. Second thing is business in the open. Our company handbook and our policies are publicly available, over 2,000 pages of how we work as a company. Third, a clear direction. Our direction page clarifies our priorities and what we are planning on developing in upcoming releases. As GitLab has grown, we've lived up to this policy to continue building trust with our community. We default to working openly and transparently, with exceptions only when necessary, such as legal requirements. A recent example to our commitment to transparency: on October 14th, GitLab became the first company to publicly livestream the entire IPO listing day events at NASDAQ. Throughout the process of going public, we were able to keep most of our information publicly available. Our transparency policy is part of our stewardship promise, which is also on our website. On this page, we also document an explanation of our open-core business model, the criteria that we use to determine paid-only features, and an explanation of how the open-source code benefits from open-core. Our stewardship page demonstrates a strong commitment to the open-source ethos and is very specific about what we will and won't do. Some specific promises that we make are that we won't move features from free code into a paid tier. We won't artificially limit or delay features for the free tier. For example, in our code base, we're not putting a limit on repositories, user size, or performance in the free tier. The free tier will have the essential features to run a large Forge with both public and private repositories. We will actively contribute to the open source code, with the majority of features built by GitLab Inc. being open source. By publicly and transparently making commitments to the wider community and demonstrating these commitments, we have built trust while also building the business. We have to balance our stewardship of the project with the need to generate revenue. And one of the most essential decisions in there was determining what we would charge for, what would be our business model. We explored many different business models before choosing open-core. We started with donations. They topped out at $1,000 per month. It wasn't enough to sustain the business. We tried consultancy, but consultancy doesn't let you have high margins. Those high margins are needed for you to be able to invest back into the product, to pay for work that is unpaid otherwise. We tried paid development, but it was really hard to coordinate. We tried paid support, but we saw customers canceling after 1 year. Like, they didn't need the support, and they didn't because the product kind of was easy to run. And then we considered charging for packaging, kind of charging for a product that's easier to install, but that means your open source product is harder to install. That hinders adoption by free users. So we ended up choosing an open-core business model, which has high revenue potential, and it also allows us to be good stewards of the open-source project. Those margins allow us to reinvest. After choosing the open-core, we needed to decide what functionality to monetize, what would be the paid features. We first considered pricing based on the SDLC stage, the stage in the software development lifecycle. So GitLab consists of 10 different stages, so we could price based on— do you use Create or Verify or the other stages? The problem is, if you try to price separately for each, you hinder adoption of multiple stages. The value in the product comes across when you use multiple stages. So we wanted the pricing model to make it as easy as possible to adopt multiple stages. So that didn't work. To price per stage. Then we priced, and we said, it's kind of based on company size. If you are a bigger company, you're going to use more advanced features, and you're going to pay for them. The problem is that smaller companies still needed the advanced functionality. And they said, look, your pricing model is not fair. We're small companies, still have to pay as a big company. and then we tried to price based on the maturity of the customer. And the problem there is that customers that were new to DevSecOps were getting a ton of value from GitLab. They were benefiting enormously from the product. They were able to kind of— they didn't have a lot to replace, so they quickly adopted the product. And GitLab has many ingrained best practices. It didn't make sense to charge people who were less mature in DevOps less money because we were providing much more value to them. So we ended up charging based on the buyer. For features that are used by an individual contributor, we put them in the open source code base. For features that are the focus of an executive, we put them in the highest paid version. That works really well because individual contributors are much more likely to contribute. And if they contribute, that code is open source. Someone is an executive, they tend to have more budget, so they don't mind as much that the features that are important to them are in a higher tier. They're able to pay for it. I believe this buyer-based open-core model best aligns pay tiers with customer needs. I also believe it best balances the revenue potential and providing benefits to the contributor community. Beyond transparency and picking the right business model, we invest heavily in engaging and growing the wider community. We use key performance indicators to decide what community engagement programs we build. Some of the indicators that we use include the number of individuals from the wider community making contributors— contributions to GitLab. Also, the total number of contributions from the wider community that we merge into our codebase each month. And we're also developing a new KPI, MRR, which looks at the contributions activity from the largest customer based on what they spent with us. By measuring and monitoring these metrics, we understand the impact of our wider community engagement programs, and we invest in programs that are designed to grow our wider community. We offer free licensing of our paid plans to education institutions, open source organizations, and qualifying startups. Our goal with these programs is to grow a wider community while supporting causes that align with our mission of enabling everyone to contribute. We recognize that contributing to a large and complex, complex codebase like GitLab is often difficult and intimidating, and to help with that, we've hired Merge Request Coaches. These are GitLab team members who triage incoming contributions and engage with the contributor and guide them through the process of making a contribution to GitLab. Their goal is to help these merge requests from the community get merged into the code base. This includes wider community code contributions, documentation improvements, and code quality improvements to our tests. We also hold regular hackathons. Initially, I was a bit skeptical about the efficacy of a hackathon, but they've been a great success, bringing the community together and helping them contribute. In our latest hackathon earlier this month, we saw 244 submitted merge requests, and that hackathon followed our most successful hackathon to date in Q1 2021 when we received 390 merge requests. We also make a point to celebrate our contributors in multiple ways. First of all, GitLab core team members are volunteers that have made significant contributions to GitLab. This group acts as a steward for the wider GitLab community. Up to a third of the core team are people that are also GitLab Inc. team members, with the rest being part of the wider community contributions. There's also a program called GitLab Heroes. They recognize makers, members of the wider GitLab community who make outstanding contributions. We reward these GitLab Heroes by inviting them to special events, supporting their travel, and providing GitLab Ultimate licenses, swag, and more. And GitLab Heroes sometimes contribute code, but sometimes help write blog posts or do other things. And lastly, with each release, we select the community contributor who made the most valuable contribution. This MVP, most valuable person, is chosen by GitLab team members and members of the core team and is recognized in the MVP Hall of Fame. And we send them swag. As you invest in the wider community or growing your business, you should be mindful of a few things. As you scale, it might be tempting to hire from the wider community. Over time, you should focus your active recruiting efforts elsewhere to avoid depleting your wider community. Second, stick to your stewardship promises. For example, the quickest way to lose goodwill is to make an open-source feature proprietary. Third, make sure you have clear goals for wider community engagement. For example, the number of people who contributed code over a period of time. And fourth, start early. It's very difficult to build a community from scratch later on in a company lifecycle. A great community makes for a great project. But a community is hard to build and easy to lose. So invest heavily in your community and keep it top of mind. With every decision that you make. To conclude, I want to share some examples of the impact that the wider community had on GitLab. A small team at Siemens adopted GitLab in 2013 for collaboration and version control. Over time, it scaled to more than 40,000 users. They have had 38 million CI builds. We've celebrated two Siemens employees as GitLab MVPs, and also recognize them as GitLab Heroes. Siemens has 150 merged MRs in GitLab as they continue to improve the product for their own purposes as well as for the wider community. Their contributions lead to more features we can release, which leads to more users and more contributions. We also hear from GitLab's wider community about how contributing to GitLab helps them advance their skills and their appreciation for the community. That's what makes a community unique, valuable, and difficult to replicate. These were just a few examples of the community. It has millions of users with thousands of people contributing code, language translations, and documentation updates. These contributions help us deliver more functionality in our releases, help paid users and free users. We feel very fortunate to be part of the community and we take it very serious. To be responsible for it, and to continue to cultivate it. The open-core business model has enabled GitLab to be good stewards of the open-source project and generate revenue. Revenue growth is 58% year over year, and our dollar-based gross retention is 97%. That's partly due to GitLab's collaborative relationship with customers contributing to the platform. I hope this presentation is helpful to you as you consider models to co-create with the wider community. As we have learned with our experience at GitLab, and engage wider community can be very valuable and lead to a dual flywheel model of growth. But fostering trust and growing this community requires you to align your company values, to build trust, to be transparent, and be a clear and clear and reliable steward. You also must pick a business model that balances the revenue with the needs of the wider community, such as GitLab's buyer-based open core model, and invest in programs to engage, support, and grow your wider community. Thanks so much for your time and attention today. With this, I'll— we'll move to Q&A.

Thank you, Syd. So moving to Q&A, we have our first question in. When measuring the health of your community, is there a top KPI you look to or would recommend for other organizations pursuing this model?

Yeah, thanks for that. The top KPI that we look at is how many contributions did we get and from how many people. And if I have to pick one, I would say how many people contributed in any month. So right now that is in the, on average, kind of 200-ish people who contribute to GitLab in a given month. And that's really important, and we focus on the number of people over the number of contributions because sometimes you split something up in more or fewer things, but the most important thing is how many people do you have engaged. And that's a metric that we also look at, like in a hackathon, how many people that we gain, how many people contributed something.

Okay, next question: Where's the line between community and simply active users?

Yeah, that's a great question. We consider all our active users part of the community, but of course, like, there's, there's different activity levels. You can see someone who is a user and, and kind of uses it day to day. Then someone can go to a champion where they're kind of fan of the product and they advocate for it and they tell other people about it. Then there's people who kind of actively engage with others. For example, we have an issue tracker where people talk about new functionality, so people participating there. Then there's people kind of creating content, and it can be in the form of a blog post, that can be in the form of a translation or an update to the documentation. And then there's people who contribute new functionality and code and grow the product that way.

When having conversations with your largest, most strategic prospects, is your open-core community model something that intrigues them or defers them? Is this something you need to spend more time explaining?

Yeah, we— it's, it's never a negative. It's not top of mind for all customers. So some customers are really familiar with open source, and they, they get it, and it's, it's something they look forward to. Like, it gives them more control. What GitLab does— GitLab replaces DIY DevOps. So commonly what the customer has currently is a whole bunch of point solutions that they stitch together with all kinds of custom integrations, and they have people kind of working on that and spending time on it. When they replace that with GitLab, they get to a single application, a single data store, a single interface, with where they no longer have to spend all that time. But frequently what they do is they have a few people or a little bit of their time they now spend on making GitLab work for them. So instead of having to create the whole DOI DevOps, they contribute a little bit to the DevOps platform, and that allows them, if they have an urgent business need, to quickly add that to the platform. And for those people, it's super important that they have the ability to modify the code and make their own improvements, and they never, never have to wait for us.

You spoke of GitLab as being source available for proprietary functionality. Do you think that keeping some proprietary code as closed source, for example, proprietary algorithms that are a competitive advantage, would negatively impact community trust?

Yeah, that's a really good question. I don't know. We are not shipping a ton of models with GitLab yet. I do think that you can do that. I think there's a balance. There's a balance between like, if you give people these models, they're able to kind of reverse engineer it and kind of maybe learn from it, I think that is a small kind of, a small risk compared to kind of the benefit that they get being able to understand that. So I don't see a reason to treat these models any different than we treat the proprietary code today. And I think we're comfortable with that. I can see other companies maybe treating models different than source code. And every application of the future will have code, data, and trained models. And those are different things. So I can see the argument. I don't think we plan to treat them differently.

Can you recommend any framework for our SaaS solution to enable our users to vote, weigh influence on our product roadmap?

Yeah, so if you use GitLab and the GitLab issue tracker, there's a built-in functionality to upvote things. So thumbs up, thumbs down, it's native to the product and it allows you to sort your issues by like highest voted ones.

Why did GitLab choose so early to go enterprise?

It's a great question. We've always made the majority of our revenue from larger companies, and we found that larger companies were more prepared to pay for GitLab. Um, also larger companies tend to have more complexity. What's happening in the world is that people have more and more DevOps tools and they have more and more projects. And together that's causing an exponential increase in the number of tool project integrations. And if you are trying to keep up with that with a DIY DevOps platform, you find yourself spending more and more time building all these custom integrations. That's the problem we solve with our DevOps platform. And I think that the need for that is the highest at the most complex organizations. Although we see kind of software development getting more complex in all kinds of organizations, so over time you have everyone shift into it, but we found an early audience with these bigger enterprises.

Can you, can you talk a little bit about how this model relates to or affects security?

Yeah, there's two things in security, like there's the security functionality in GitLab, There's a ton of that static and dynamic code analysis, fuzz testing, dependency scanning. So there's a ton in there and we get contributions from the wider community. But the question is fully about vulnerabilities in GitLab, the application. Being kind of public about all the code is a two-sided thing. Like on one hand, you give it, you allow kind of bad people to kind of look for vulnerabilities. On the other hand, you allow the good people to also look for those vulnerabilities. So far, we've never seen kind of a zero-day in GitLab where the bad people found it before the good people. And I think if you think about it, it's much more pleasurable as a researcher to kind of look at open source code. We don't have to go back into a binary or something like that. So although there's pros and cons, I think the balance is that we think it's more secure because it's open. And it also allows customers to get more comfortable because they're able to inspect the code base so they can do their own security diligence and research.

An additional question along the same lines: given GitLab's scale and developer reach, how is it evolving its responsibility, specifically open source cybersecurity concerns?

Yeah, thanks for that. The most important thing is that we make— we allow our customers to shift security left. With GitLab, they're able to do all the security scanning earlier when problems are easier and quicker to remedy. So that's what we enable, and that functionality, those advanced security features in GitLab, are the most common reason to buy our Ultimate tier, which has grown from 17% to 29% of our revenue in the 5 quarters before our IPO. So that's on top of all our regular growth. So it's becoming very clear that you don't, you don't want to have a Dev platform, you want to have a DevSecOps platform. And GitLab allows people to bring security as part of that lifecycle and retire the point solutions where previously you made everything and then your security department would look at it with their tools. That slows everything down. With GitLab, they're able to do it earlier, address it quicker and cheaper, but also make sure that you scan 100% of your applications 100% of the time. So we're very focused on that. And as the company goes, like, we, um, we keep investing in security. And for example, we have very active bug bounty program, and we have an internal red team at GitLab.

So how do you continue to keep up with new releases per month, and is that embedded in GitLab's culture?

Yeah, so we had, since the beginning of GitLab, we've released a new version on the 22nd of every month, and we've done that for more than 100 times. What drives that is that that release contains whatever was ready, so we never wait for something to be ready. The train runs on time, and you're either going to make the train or not, depending on whether you're on time at the station. That reliability of the trains running on time is really motivating. If you contribute something to GitLab, you know it's gonna, when it's got merged, you know when it's gonna go out. And that creates a great incentive for people to contribute and very proud of the ability of us to ship over 100 new features in a quarter. With that help of the wider community.

Yeah. Community-wise, what do you think is the impact of companies purchasing open source projects? Even if they keep them open and free, does it affect activity and engagement within the community?

I think there's— when a kind of— a thing that previously was an open source project, when there's a company formed around it, I think two things can happen. There can be a slowdown in the open source project as the company kind of causes this focus to shift to closed source, or it can be that the open source project goes faster because there's now more money to do things. A lot of the work that we do on GitLab is not very glamorous, glamorous. It's like updating dependencies, fixing performance problems, making the UI easier to use. All these small things that are really important and that frequently are really hard to get a community to do. Communities tend to focus on new features and new functionality. When we started GitLab, the community was kind of skeptical, and that went away because they saw that we were able to kind of do more in the open source code base because there was a company behind it. And I think that's what you have to prove as you start building a company around a previously— previous open source project that didn't have a company around it.

Do you see your smaller customers grow into bigger customers?

Yeah, I won't take credit for all the growth, our customers do, but we certainly see that customers kind of adopt a DevOps platform over time. According to a Forrester study we had commissioned, our customers replace 3 point solutions in year 1, year 2, and year 3. So as they become more familiar with GitLab, they get to replace more point solutions. In the beginning, they might just replace Bitbucket and Jenkins. Now over time, they replace JFrog Artifactory And they replace their custom release scripts, and they replace Synopsys and Veracode and Black Duck. So it's a gradual process of adopting. And in our S-1 filing, we talked about our net retention. It's the money that customers spent with us, and it's grown more than 150%, which means that if a cohort of customers is spending $100 with you last year, they're now spending $150. The majority of that is being driven by kind of user expansion. Over time, the number of users grows because people see the results. People see that they're able to do more with the people they already have and get software out faster, make it more reliable.

What are your thoughts on the feasibility for organizations wanting to shift current business models into open core?

Yeah, I think what's really crucial to realize is that you're going to have kind of a bigger pie and a smaller piece of it. Another way to say it, your open core makes it easier to grow the number of users you have, but your monetization of them is going to be lower. And that has to fit within your business model. Companies are attracted to open core products because they tend to be a better deal. And they tend to be a better deal because there's all this amazing functionality that got created. But as a company, your ability to monetize is reduced because you're— and the core of your application is, is open source. So That's the thing you have to balance and get comfortable with.

Can you elaborate on your pricing model? What would you recommend to switch for other startups?

Yeah, there's, there's a lot of thoughts around pricing, and if you Google GitLab handbook pricing, you'll find a really long webpage with a lot of ideas about it. My mistake pricing earlier on was to price too low, to not price according to the value, to make pricing too complex with having all these add-ons and things. I'm really glad that now we're down to kind of 3 tiers, kind of a good, better, best model. And I encourage people to check out the buyer-based open core. If you want to get more into it, I've done a talk at Heavybit that's linked from that pricing page that, that dives into that subject. I think it's a really powerful way to monetize open core.

Okay, uh, we are headed into our last question, um, more of a forward-looking question. GitLab runs on many private clouds. What do you see private versus hybrid versus mono clouds looking like 5 to 10 years from now?

Yeah, we see enormous growth in the hyperclouds. If you look at people self-managing GitLab, the majority of those installations are in the public cloud. They are at AWS, GCP, and Azure, and we can— we expect that will continue to grow. We also see enormous growth of GitLab.com. It's more than doubling in revenue year over year, and we see enormous customers adopting it. For example, T-Mobile is using GitLab.com, and by switching to GitLab, they've been able to increase their frequency of delivering value by 10x. They're shipping 10 times as fast due to switching to GitLab.

Alright, well, thank you so much. Looks like we are out of time.

Thanks for the great questions, everyone.

Awesome. Sid, thank you so much. This was lovely. Really appreciate you sharing some of your insights. Everyone, we have more SaaS to Scale content for you in store. So see you at the next sessions.