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 scale. We didn't have like techs because of being remote. We actually did better. The vast majority of the people on earth, if they want to work for getlab, 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 sasterscale and for this next session. Really excited to announce Sid SeaBrandy. 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 and A. This is a 50 minute session, so make sure you drop your questions in for Sid into the Q and 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 Zaporozh created GitLab in 2011 as an open source collaboration tool while living in the Ukraine. He used 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, 202012 when I discovered GitLab from my home in the Netherlands and I was really impressed by their code quality and the 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 as 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. 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. We're part of that larger community. We also try to avoid terms 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, 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 OpenCore 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 October of this year we 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 OpenCore strategy. OpenCore 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 code 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, over 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 four 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 OpenCore model also enables us to generate revenue from our proprietary features and as I mentioned earlier, customers also benefit from being able to contribute features to the product. And OpenCore also enables the dual 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 OpenCore. Next, I want to talk about some of the learnings from the past decade building trust, fostering community engagement and building a company around the GitLab project. Commercial models around open source such as OpenCore typically face challenges around three 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 or 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 the 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 and 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 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 14, 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 OpenCore. Our stewardship page demonstrates a strong commitment to the open source ethos 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 force 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 Opencore. 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 higher 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 one year like they didn't need to 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 OpenCore, we needed to decide what functionality to monetize. What would be the paid features. We first consider 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 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 try 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 charting 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. 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 program should we build. Some of the indicators that we use include the number of individuals from the wider community making contributions to GitLab also the total number of contributions from the wider community that we merge into our code base each month and we're also developing a new KPI MRAR 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 a 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 code base like GitLabs 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. Reward these GitLab Heroes by inviting them to special events, supporting their travel and providing GitLab Ultimate Licenses, SWAG and more. GitLab Heroes sometimes contribute code, but sometimes help write blog posts or do other things. 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 life cycle. 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 misses 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 writer 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 engaged 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 reliable steward. You also must pick a business model that balances the revenue with the needs of the wider community, such as GitLab's bio based OpenCore model and invest in programs to engage, support and grow your wider community. Thanks so much for your time and attention today. With this we'll move to Q and A.

Thank you, Sid. So, moving to Q and 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 200ish 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? That's a metric that we also look at 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 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, 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 get it and it's something they look forward to. It gives them more control. What GitLab does. GitLab replaces DLI 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 working on it and spending time on it. When they replace that with GitLab, they get to a single application, a single data store, a single interface 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 from 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 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 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 are, they're able to kind of reverse engineer it and kind of maybe learn from it. I think that is a small, kind of 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 building 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 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. 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 the 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 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. First testing, dependency scanning, 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 public about all the code is a two sided thing. On one hand you allow bad people to look for vulnerabilities, on the other hand you allow the good people to also look for those vulnerabilities. So far we've never seen a zero day in GitLab where the bad people found it before the good people. You think about it, it's much more pleasurable as a researcher to 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 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 that functionality. Those advanced security features in GitLab are the most common reason to buy our ultimate tier, which is grown from 17 to 29% of our revenue in the five quarters before our IPO. So that's on top of all our regular growth. So it's becoming very clear that 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 to 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. We're very focused on that as a company goes. 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 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 going to when it's got merged, you know when it's going to go out and that's create 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.

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, 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. 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 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 adopt a DevOps platform over time. According to a Forrester study, we had commissions. Our customers replace three point solutions in year one, year two and year three. 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 replaced JFrog, Artifactory and they replace their custom release scripts and they replace Synopsys and Vera Code and Black Duck. So it's a gradual process of adopting. And in our S1 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 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 OpenCore?

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 OpenCore 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 OpenCore 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 the core of your application 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 a lot of thoughts around pricing. And if you Google GitLab handbook pricing, you'll find a really long web page 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 without having all these add ons and things. I'm really glad that now we're down to kind of three tiers, kind of a good better best model and I encourage people to check out the bio based OpenCore if you want to get more into it. I've done a talk at Heavybit that's linked from that pricing page that dives into that subject and then gets a really powerful way to monetize OpenCore.

We are headed into our last question, more of a forward looking question. GitLab runs on many private clouds. What do you see private versus hybrid versus mono clouds looking like five to ten 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 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.

All right, 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 Saster scale content for you in store so see you at the next sessions.