GitLab Inc. (GTLB) Earnings Call Transcript & Summary

Thanks for joining us. My name is Koji Ikeda. I'm one of the software analysts on the enterprise software team at Bank of America. We have Sid, CEO, founder, too, of GitLab. Super thrilled to have you here. Thanks for doing this. Really, really appreciate it.

Yes, thanks for having me. Appreciate it.

Yes. So I guess for -- from an introduction standpoint, let's just start at a very, very high level. And maybe a little bit of background on yourself. What does GitLab do? What is the opportunity that you guys are going after?

Yes, thanks. I studied applied physics and management science, did internships at IBM and Procter & Gamble. But after graduating, I took a bit of an adventurous turn, I started making submarines, recreational submarines. If you have a -- if this job really works out and you buy this huge yacht, then I hope you buy a submarine from the company that we started, U-Boat Worx. They sell the most submarines today.

You still sell submarines?

The company's still around. I worked there for 5 years. There's now 100 people working there. And they sell it all over the world. Some cruise liners now started adding submarines.

Very cool.

And in the fifth year, I saw a new programming language called Ruby. And I didn't know how to program, but for the first time, it looked fun instead of tedious. So learned that, became a software consultant. And at some point, I saw GitLab as a project on Hacker News. It was a year old. I thought it made so much sense that something that you collaborate with, there's also something you can contribute back to that it's open source, and I started a company around it. In 2015, we got into Y Combinator, moved to the West Coast and took on investment. And what GitLab does is we make it easier for companies to make software. So everything from planning, building, securing, deploying, monitoring software, it's all in a single application. And it really helps to speed up how fast you can make software, how secure you can be, how compliant you are, and we sell that as a product all over the world.

Got it. Got it. So I want to take a kind of a huge step back for the category. DevSecOps is -- definitely feels like it's the -- heating up in the market today. Also from an investor conversation standpoint, I'm fielding a lot more calls on DevOps. What is DevSecOps? What does it mean? But maybe a little bit of a history lesson would be helpful. I'm still learning about the category myself. You're one of the experts in the category. So what is DevSecOps today? But I guess a little bit more importantly, where did it come from? And why are we here with all these DevSecOp tools that we see in the marketplace today, but also GitLab. I mean you guys are growing incredibly fast. So what's going on with this whole world?

Yes, it used to be that you made software and you had like a quarterly release, almost like an earnings release, like you made a plan, then you build all that time and you give it to the other team to secure it, and then you handed it over to another team to actually deploy it. So you have the development team, the security team and operations team. And the big problem was like what you thought you needed wasn't quite what you needed. The security team found all kinds of problems and threw it back. The operations team has all kinds of improvements they needed for you, so it was delayed more. So all these delays. And people said that this -- it needs to go faster. And it was kind of a cultural change, not so much a technical change to say, "Look, we've got to collaborate closely. We've got to integrate development, security and operations. We're going to have a shorter cycle time. Instead of a quarter, we're going to take weeks to do that." And then when that philosophy changed, a whole lot of tools sprang up to help close that loop, make that cycle time faster. And that's the early area, the early -- the first stage of this category, it's bring your own tools. Teams started like bringing in their own tools. Then company said, "This is a mess. Like all the teams are on different tools, they can't collaborate. We're going to do best-in-class DevOps. As a company, we're going to select the 10, 15 best solutions for every single part of the DevOps process." It's the second stage. The third stage is DIY DevOps, where companies said, "Hey, we're going to build some integration because our biggest problem is not the individual tools, it's hands off between them. It's the overview of what's happening." And that's where most companies are today. According to Gartner, about 20% -- 80% of the market today is DIY DevOps, and only 20% is the next stage, which is a DevOps platform. DevOps platform is one application. A single application with one interface, one data store that does the entire process. It allows you to go much faster. There's a major bank that went from 2 weeks to 2 hours to improve their most important application and be way more productive. At T-Mobile, they were able to release 10x as fast by switching to GitLab as their one DevOps platform. But this shift is very early, this last shift, so you still have a lot of point solutions out there. But according to Gartner, the shift to DevOps platforms, the adoption is going to triple over the next 2 years.

Wow. What is it about this shift? Why are we seeing this maybe catalyst for this shift? We've done a ton of work in the DevOps category. We've spoken with developers, single developers, full stack developers doing projects on their own. But we've also talked to CTOs out there. And it seems like there maybe is a disconnect in the way that the two think. Maybe I'm wrong, please correct me if I'm wrong. But when I talk with developers, they tell me, "I kind of choose whatever I want because my boss is telling me, 'I need this application tomorrow.'" And when we speak with the higher level, they're talking about, "We have all these developers, 10,000 developers, whatever it may be, and it's -- everything's all over the place. And I'm afraid of what this future is going to look like with all of our applications, whether it be off-the-shelf integrations or even custom apps." I mean what's happening right now with the -- with small companies all the way up to the biggest companies in the world?

Yes, there's like bottoms up, people are selecting their tools. There's a lot of like bottoms-up adoption of GitLab. And top-down, the CIOs, the CTOs, they want to consolidate because it's getting messy. And all the time, they have like more compliance requirements and more things they got to secure, and it's really hard to do that if everyone is on different tools and you're -- they have to kind of integrate all of that. And what's also happening in the middle of the company, the middle management just spent the last few years building their own DIY DevOps, making that digital duct tape between all the applications, making their own compliance frameworks and things like that, they're reluctant to give that up. What we said in our earnings on Monday, for the first time, we're now seeing the C-level execs coming in and saying, "Look, we need to switch to a platform. We need to consolidate." That's not everyone yet, but for the first time, the market is starting to significantly shift. And the beginning, hopefully, of this is tripling of DevOps platforms in the next 2 years.

Got it. Got it. Got it. So you mentioned your results. First -- fiscal first quarter on Monday, great results, accelerating growth. I mean, I guess from your view, what are the kind of the big 1, 2, 3 takeaways from the earnings report this past Monday?

Yes, so we saw 75% revenue growth, which is an acceleration. So increasing this shift to the DevOps platform. We saw great new customer adds, 65% new base customers year-over-year. So customers are coming in. We also saw margin improvement, 1,700 basis points year-over-year, 700 points quarter-over-quarter. So as we scale, we become more efficient.

Is -- was the pandemic a catalyst for DevOps? Was it a headwind for DevOps? As we head out of the pandemic, how do you think about kind of this post-COVID world application development, the speed of demands for digital transformation?

I think it's an imperative. What we saw in the beginning of the pandemic, like airlines that were almost shut down, 90% revenue drop for airlines. In that time, we signed 3 global airlines because they said, "Revenue might be down, but we still have to make this digital shift. We still have to get more efficient in our customer interactions. We still have to transition from data centers to the cloud. So although there's very little money coming in, we know we have to invest in a DevOps platform."

It's just -- you just got to do it, right? It's digital transformation, it's just not stopping anytime soon and you got to step on the pedal. Is that what you're hearing out there?

Every company has to become a software company. And either they get really good at that or they'll be beaten by one.

Okay, okay. I want to ask you some big picture questions, kind of a first question maybe on the macro front, demand environment, et cetera? And then second, kind of on the hiring environment, what you're seeing out there from the GitLab perspective. So first question, macro, a lot of things going on in the world. A lot of bad things, a lot of things we wish we could put behind us, but they're ongoing right now. So I guess from an impact perspective for GitLab, what are you seeing out there? Are there any impacts at all? And are you positioning the business maybe a little bit differently today versus a year or 2 ago, thinking about maybe a potential slowdown in the future?

Yes, so what we said in our earnings call on Monday is we've not seen any key business metrics change. In fact, our pipeline in Europe is the strongest it's ever been. We're not doing anything different. What we are doing is like changing the messaging, saying how GitLab is appropriate in a macro down environment. Because with GitLab, people can consolidate tools spend. Instead of spending with 12 vendors, you save because you spend it with a single one. Those 50 people that were maintaining your DIY DevOps platform, they can move on and do something that actually differentiates the business. On top of that, your people become more productive. Lots of companies have hiring stops now. They need to do more innovation with the same amount of people. So by going through a platform where you have fewer contact switches, you can do that. You can make those existing people more productive. And what GitLab delivers is a faster cycle time, faster shifting from your data centers to the cloud, faster improvement, faster execution on cost-saving initiatives. So that's the story we're now telling.

So no slowdown in demand environment, in fact, accelerating in Europe, and that's fantastic in this environment. The hiring front. So you rewind 12 months, 6 months ago, kind of the message out there from all the enterprises is we can't hire, we can't find people, things have changed. What are you guys seeing out there from a hiring standpoint for your employees? And really kind of thinking about your operating structure. You guys are remote always, right? So how does that play into maybe a positive or negative? Or how do you guys think about that from a hiring standpoint?

Yes, we've seen that even in the very competitive environment of last quarter, we were still able to hire really well. We hired more people last quarter than we did in any of the 8 quarters that came before it. At the same time, what we're seeing now is that we'll be able to hire even better. Like there's lots of companies now, hiring stops, letting people go, and this is a great time to like build a big company.

Okay. So I have one of the premier experts in DevOps on stage with me. So I got to ask you the question, and I want to figure it out. I ask a lot of developers this question, and I kind of get the similar answer. And the question that I ask them is, in the DevOps community, all -- you see all these tools. I mean we printed white papers before and you kind of lay out the landscape and you kind of see a lot of tools. And I ask these developers when I speak with them, what is the differentiation between these tools? And the most common answer I get is there isn't a lot. But I beg to differ with that answer. Maybe there isn't a lot of awareness of what the differentiation is. So you guys are, I think, a clear leader in source code management, you are a leader in CI/CD, too, so in your view, what are kind of the core differentiators of a DevOps tool?

Yes, I think the difference is we're undergoing this transition in the market from the DIY DevOps with best-in-class tools to DevOps platforms. We're by far ahead in the comprehensiveness of the solution. And we're innovating in a much faster clip, and that's because GitLab is open core. Our customers help us improve the platform. Hundreds of improvements every quarter are driven by our customers. And because they can consolidate tools and save on the integration efforts, save on the digital duct tape to integrate them, you get a great return. According to Forrester, with -- by switching to GitLab, they get a 407% return over 3 years.

Wow. Wow. It's quite an ROI. So I wanted to ask you a question, kind of getting in the weeds a little bit. I've kind of done my spreadsheets on pricing models and different tools out there from source code management vendors and other vendors out there. And one thing that maybe you could help me understand is CI/CD and minutes involved with it. I see different numbers out there, whether it's 5,000 minutes a month to 20, I don't really know what that means. Could you help explain what does it mean from -- what does a CI/CD mean?

Yes, so if you make software, you want to test your code. And to do that, you need compute power. And so over time, for us, consumption is a very small part of our revenue, but we do sell it. We don't want to artificially constrain our customers, so you can buy the compute from us increasingly by storage and network traffic. And you price that per minute. So every minute of tests, you buy it in bulk, 5,000 minutes and then the counter goes down, you've got to purchase more. Kind of like how Snowflake, for example, sells consumption.

Does it also matter with the CI/CD minutes of maybe how many end devices you're pushing an application version to? I mean does that all come into play with the minutes involved?

No, it's more about the testing of the code. The deployment, the physical -- or the action of the deployment might run on the same things. It might use some minutes, but you're not paying for like the end devices and the code that's running there.

Got it. Got it. Got it. Okay. So GitLab, very, very well-known brand in source code management. Kind of our long-term thesis on the business is you kind of got this core system of record of an application. So I guess tell me maybe why I start with source code management? What is the kind of history there? Do you believe that source code management is the key to maybe winning the rest of the tool chain?

Yes, it's great to be a system of record. And it gives you the opportunity to go downstream. Every time you go -- you first write the code, then you test it, then you deploy it, then you secure it, et cetera. So every time we can raise our hands and "Hey, do you know you can do this in GitLab now, too?" If you're a realtor, you can suggest an escrow agent. If you're an escrow agent, you can't suggest a realtor, but they already bought the place. Like it doesn't work. It's super hard to go upstream. And that's why probably the only 2 viable DevOps platforms are going to be us and GitHub.

Got it. Got it. Okay, okay. You mentioned something interesting there in that comment of, "Hey, did you know we also do that, too." And it maybe speaks to the brand awareness or end community awareness of the full end-to-end platform that you guys have. What does it take to kind of raise that awareness within the community that you do have an end-to-end platform.

Yes, it's super important. We started off on just version control. So we try to tell that story every chance we get, but more importantly, getting that story of like why switch from DIY DevOps to a platform, getting that across. And that's a combination of all the way from our earnings call to the field events, the marketing, the website, the advertisements and also telling the customer stories, like customers who implement GitLab, they see incredible productivity increases at their companies and they're the real heroes of the story and we should do a better and better job of highlighting them.

Got it. Got it. Got it. Okay. So you've been public now for, I think, 8 months or so, right around that time?

This was our third quarter.

Yes, yes. So what has that done maybe from a brand awareness perspective going IPO? I mean I've -- when I initially started doing work on the DevOps category, I mean, you guys came up right away. But maybe from an overall brand awareness, did it help? Or what did the IPO do for you?

It was incredible. I think it helped a lot in awareness. It also helped a lot in kind of how we viewed our own company. But for example, we had a live stream on the day of going public for hours, and we had thousands of people watching. And those are not just potential customers, but also potential future team members. So it's been great for the talent brand. It's been great for the product brand, and we're really happy that we're out here now where it's not so easy to go out at the current time.

Yes, yes. No, no, that makes a lot of sense. I want to ask you one more question, and then I also want to open it up to the field for the investors out there to see if they have any questions for you. So my next question is kind of about the community of DevOps. One thing when we're doing our conversations out there with developers, they always stress the community is important. The ability to go on the stack exchanges and the stack overflows and build together applications with other developers out there. How do you view the community? And what are you guys doing to kind of support the GitLab community out there?

Yes, for us, a really important part is all those people contributing back to the product. And we want to make sure that we hold up our end of the bargain. Those -- GitLab is not like a single company, it's a whole community of organizations together building a better product. For example, we have stewardship promises, where we say, "Look, as being a good steward of the open core product, these are the things we hold -- we'll hold ourselves accountable to." And over time, we've been able to increase the absolute number of improvements that come from the wider community, where it's very common if the company becomes more successful, you kind of drown out the wider community, we've been able to increase it. And that's something we're proud of, and we'll try to continue to grow.

Sid, maybe you could help me understand kind of from an outside looking in on understanding the community involvement. Is there a way that investors can look at the community or judge kind of the activity of a community? I mean maybe help us understand how we can see community involvement for GitLab?

Yes, you can see like every line of code and every line of documentation that the wider community added, but that might be a bit in the weeds. You can also go to our release posts. If you Google GitLab 15, they got released on the 22nd. You'll find that we have an MVP, a most valuable player, the top person from the community. This person added CRM functionality to GitLab, something I never thought would be in our product, but they needed it because they work very closely with customers and their customers and how they manage their projects is intertwined. And they independently, outside of us, like made that functionality and contributed to GitLab. And now we can see whether there will be uptake and whether this part of it will grow. But very significant changes and improvements driven by people who've never been on our payroll.

Help me understand a little bit to that point of the community involvement and features that are being built. I guess I come from a more traditional application environment. I think about Salesforce. I think about their Salesforce App -- their AppExchange, and it creates a natural community and even slash M&A kind of target for new types of features that could be added. I mean does this create new features? Are you able to take that code or that CRM functionality and offer it to the wider community? Or how does that work with something like this?

Exactly, hundreds of improvements. Every quarter, they become part of the core code base that are available for everyone to use. And sometimes our customers like contributed the paid code base, so to paid features. So there's a paid feature. We're charging money for it, they help improvement -- improve it, and there's more value for everyone to go about. Think of it as the Salesforce marketplace, except everyone gets everything. Like it's a tremendous amount of value that you're creating. The marketplace is because it's not open source. I can't contribute to Salesforce even if I wanted to. So the only outlet is that marketplace, but it's an artificial constraint because we're source available, even our proprietary code, you can see, you can modify. We don't need the marketplace. You get a great experience. And it's not disjointed, whether it's a core app and then all kinds of other apps that are hard to keep compatible with each other. It all gets tested. Over 100,000 tests get run every time we update something, so it's very coherent.

That makes a lot of sense. Any questions from the audience? [Operator Instructions] Any questions from the audience?

You talked a little bit about -- or you were asked about differentiation among the different Git repositories, GitHub, Bitbucket, there are others. Can you -- and you cited a pretty heady ROI, I guess it was Forrester, which is very impressive. Can you talk about differentiation in ROI or robustness in security in the repository? Any other differentiation between you and GitHub with their increased scale? That would be the first question. And then secondly, can you just describe the role in the marketplace for the -- kind of the binary artifactories like JFrog of the world, how they fit with what you do? Is there interoperability there? Should there be? And kind of where does the landscape evolve over time?

Yes, thanks. Great questions. So if you look between us and GitHub, we're way ahead in the comprehensiveness of the platform. It's a real DevSecOps solution. And both like -- for example, our CI/CD functionality is more extensive. We have many more security solutions. Our ops is focus of the company and way ahead. So much more comprehensive, improving at a much faster rate, also due to the wider community being able to contribute. That being said, if you look at us and GitHub together, we're less than 5% of the DevOps tooling market. So we're very, very early in this transition to a platform. If you think about point solutions like JFrog Artifactory, you want great integrations. So we've got hundreds of integrations. We partner. We don't want to artificially constrain customers. They're very sensitive for that and rightfully so. They want the option to use something else. Our job is to make sure that the default, the GitLab, is so good that they don't have to do that. And increasingly, we're able to replace JFrog Artifactory, [ other ] customers. And some customers even said, "Look, the only thing preventing me from switching is this, so I contributed it to GitLab. So I can switch." And now suddenly, all of these other customers can also benefit from that. So it feeds on itself.

Other questions from the audience?

Just maybe a quick clarifier. In terms of that ROI -- but you mentioned like development cycle time benefits for customers. I think you cited T-Mobile. Would there be a similar cycle time benefit if they were using the GitHub libraries instead? Is it faster? Slower? So I guess I'm really trying to pin you down on differentiation, if I choose your tool set versus a tool chain from someone else.

Yes. It's really about how many point solutions can you replace, right? If you just replace source code, like it's not a point solution. You don't have a plan for it. So is it -- how many point solutions can you replace? And that really depends on like how comprehensive is it. Can I match JFrog Artifactory? And can I replace that? Can I mention all the other point solutions? The Forrester study found that customers with GitLab are able to replace 4-point solutions in year 1, 4-point solutions in year 2 and 4-point solutions in year 3. I suspect that the reason that it's a constant number is that it's the capacity to change. I think we're way ahead. But if you look at GitLab, we think only like 20% of the platform today is like best-in-class. So we still have some ways to go. That being said, we think we're way ahead of anybody else in there. And we're innovating at a very rapid clip. If you look to our monthly release post, you'll see pages and pages of new features getting out every month.

Sid, I wanted to ask you a question about the DevOps tool chain and specifically on CI/CD. So from our view, it seems like, and please correct me if I'm wrong, but it seems like this might be the next area of potential disruption or it seems like there's other -- there's players coming up in this, and it's becoming more topical. So I guess explain -- I still struggle to understand what exactly is CI/CD. And in your view, is this kind of rise of CI/CD or the competition there right? And where do you think CI/CD is going in the next 3 years?

Yes, thanks for that. CI stands for continuous integration, and it's become a normal for testing your code, making sure that everything still works. CD stands for continuous delivery, and it stands for getting your code out there on your servers or whatever else and making sure your customers can use it. The CI market started with point solutions, Travis CI, CircleCI, et cetera. Then we added CI to the platform, the birth of the platform, actually. We didn't really -- we weren't intentional about that because we started with SEM, then we built a separate app to do CI because point solutions, right? And at some point, Kamil, who I talked to a couple of hours ago, one of the great engineers of GitLab, said, "We should integrate the two." And we talked about it at length. We did it. And that's the birth of the first DevOps platform. And then over time, customers saw the benefit. And recently -- like GitHub was forced to also act, like GitHub Actions, their own CI. So that's now considered part of the platform. CD with GitLab, it's early. We got a Kubernetes agent. We got environments you can manage in GitLab, but it's the next step there to deploy the software. A lot of customers are still in the DIY DevOps mindset where they look for a specific solution for just the CD component. We believe that over time, it will just become something in the platform that you do with the same interface, with the same data store.

Okay, okay, okay. And so I guess this kind of blends into the next topic, which is security and the supply chain of software. I think of coding the application, changing it into a file that a computer could read, eventually getting it to an end device somewhere that executes that application. So you guys talk a lot about security. You've been talking about it a lot even since the IPO time. So what are you guys really focusing on security? And more so, what is the supply chain of software? What does that mean? And what does that mean for GitLab?

Yes, security is paramount to our customers. We have the most comprehensive security offering, we believe, that's on the market today. And it's everything from static to dynamic analysis, dependency and container scanning, fuzzing. The software supply chain is all the dependencies you bundle in. So if you make software, you don't write all the code yourself, you have tons of external dependencies. But because there's so much of them, there's no way to check all that code. The only way is to automate that. And they're like, "Hey, this part of things got -- is vulnerable now. There's something found and you shouldn't use it anymore." So we maintain a vulnerability database, and we tell you, "Hey, this is now a problem." You've -- I think it was months ago, it might be a bit longer, but there was a log lock for Shell, big vulnerability and companies spent like days and weeks updating everything. In the future, much more of that should be automated, but it goes through the entire DevOps process, so there's a vulnerability found. Now you want to know of which applications that I have in production, which one contains this? Of those, please update them and update the dependency, deploy that. See if that deployment is successful. It's causing problems, roll it back, open an incident. Like there is this whole coordinated organization that has to happen. And it's very, very hard to do that with an automated fashion with DIY DevOps. And GitLab will get better and better over time of doing that automated so that, that cycle time is shorter. So that from, hey, it's announced to hey, I'm safe that, that time goes from weeks to days to as short as possible.

That cycle time, it's weeks right now? Is that...

Some companies were still patching Log4j application weeks later.

What could it get to in the future? In your vision, we fast forward in the future, what could the cycle time be? Are we talking minutes? Hours? I mean you...

Hopefully, they automated, it should be minutes.

Okay. Wow, wow. Okay, okay. So I wanted to ask you -- kind of digging in a little bit more on security. I know this is one of the core drivers that creates this upsell into the ultimate tier. So maybe help me understand, is there a feature or 2 within the security offering that really drives that upsell. It's I need to have that, we need to upgrade. I mean you guys have a lot of security features. Is there maybe 1 or 2 or 3 of those security features that are the core upsell drivers to ultimate?

It's almost the opposite. It's because we have so many security features that they can finally consolidate. They have like 3, 4 security vendors now. They use Checkmarx and Synopsys and Veracode and Black Duck. And what they can do with GitLab is consolidate that spend. They can -- they no longer have to integrate everything. But more importantly, they can shift security left, do it as the developers create the code. And when you do it earlier, it's easy to address them. It's quicker to address the concerns so they become more productive. And they can enforce that every project and every change is done. Typically, when we come into customers, we scan 10% of their projects, 10% of the time. So at GitLab, they can gain 2 orders of magnitude, and they can prove it with compliance. You can say the auditor points to the production environment, we can prove we did all the security tests for that code. Every piece of code was reviewed by 2 people. Getting that accessible is not something they have to code up by themselves, and that takes sometimes 50 people. And it's -- every significant company in the world has to do this, so we might as well do it together.

You said something interesting there about the ability to shift left with the security. Could you maybe help me visualize the off-the-shelf security tools that we have today, how far left it goes? And then if you use GitLab, how much further left could it go within the DevOps process?

There are some security tools, you pay per gigabyte of code scanned. So you can only -- you write up all your code. And when you're completely done, you run the scan and you get back an Excel sheet of what's missing. That is super bad. Think of it as like you're repairing your car, you made a mess, you clean everything up, you polish it, and then it tells you, you forgot to tighten the bolt and you got to open everything up again. It is super frustrating for developers. With GitLab, you don't pay per gigabyte or something like that. As you create the code, it's scanned. It doesn't wait for you to finish up your work. So you get the feedback much easier. When the car is still opening, you can still make that change.

Is this kind of the evolution of agile software development, just bringing the security aspect for it, iterate as fast as possible, understand those failures as fast as -- I mean, is this just a continuous evolution of this whole philosophy?

Exactly. With Waterfall, it took a quarter to do something. With Agile, we said, "Hey, release every week or every 2 weeks." But we didn't say release, we say demo, like you make the code. But then we realized that if we don't close the loop to the user, we have a problem. So the next evolution after Agile was DevOps. We don't just write the code and demo it to your stakeholders, you deploy it to users. So you get real user feedback as in like, I don't like this or like it's broken or you see usage numbers go down. And that can -- that feedback can inform what you do the next week.

Switching gears a little bit. AI and ML, big topics in the software world all over the place. What does AI and ML mean to you? How do you guys think about incorporating MI -- AI and ML within your platform?

Yes, it's really important to us, and there's 2 aspects of it. One of it is like using ML and AI to make our product better. For example, we now have a feature where you can -- it's -- GitLab suggests to you who should review your code. And with a better suggestion, you're going to find someone who's a better expert who can give better feedback about your code. The other thing is integrating the DevOps process with the MLOps process. Every significant application is going to have both code and models. And those models kind of go through a life cycle themselves. You train them, you deploy them, you test them for discrimination, everything else. But it's a single application [ they -- to get it created ]. We think it makes a ton of sense to have it in one platform. We're now investing in MLOps functionality inside of GitLab so that we can bring those engineers into the platform as well.

Do you think incorporating MLOps further separates you from the competition? Or is this something that is a must-have out there, everyone's going to do it anyway? How do we think about MLOps as a differentiator in the future?

Yes, I think it's a differentiator. And we're very early in investing in this. But we know that over time, our community is going to support us, contribute back and we have high expectations.

Okay, okay. Another technology I want to talk with you about, maybe to try and understand the demand environment for infrastructure software, DevOps, et cetera, is serverless. Kind of a new theme out there or maybe not that new but new to me, more so. How do we think about serverless? And what does it mean for DevOps, DevSecOp tools and GitLab?

Yes, so serverless is you no longer kind of run -- or responsible for the server that runs it. It basically means using managed services of the hybrid clouds. Those managed services, you still have to configure, you still have to kind of control, you still have compliance concerns. So with GitLab, we have different functionality in how we can do that better. For example, we have functionality to deploy with TerraForm and really integrate TerraForm with the DevOps process. We also have a new beta in partnership with GCP called Cloud Seed, where it's much easier to kind of request those services and start from scratch, but also in a way that's maintainable day 2, day 3. So it's super important. It's a great development. It's not -- it's more of an addition than replacing anything, you have to be able to do both. And we have more and more functionality in GitLab for it.

Got it. Sid, I got one more question for you. We got in the weeds of DevOps a little bit, so I want to take it back a little bit, take it very, very high level. What gets you most excited in the DevSecOp category for GitLab over the next 12 to 24 months?

Yes, I think there's such a giant market opportunity, like a $40 billion market where we're 5% in. Gartner's saying we're going to triple DevOps platform adoption over the next 3 years, that gets me really excited. I think first, we were the first ones with a platform. We saw our competition starting to get it. We saw analysts starting to get it. I think we're now in a phase where customers are starting to get it, and that's getting me really excited.

Fantastic. Sid, we're out of time. Thank you so much.

Thank you. This is amazing.

This has been awesome. Thank you so much for joining us today.

Thank you.