 From San Francisco, it's theCUBE. Covering GitLab Commit 2020. Brought to you by GitLab. Hi, I'm Stu Miniman, and this is theCUBE's coverage of GitLab Commit 2020 here in San Francisco. Happy to welcome to the program a first-time guest off the keynote stage this morning, the co-founder and CEO of GitLab, Sid C. Brandy. Thanks so much for joining us. Yeah, thanks for having me. All right, so Sid, you know, first of all, congratulations. Good energy here at the show. GitLab definitely a company. I hear lots about in my travels, so we were super excited to bring theCUBE here. So many different things on the momentum of the company, where you're going, but I love when I have a founder on, let's rewind a little bit as to kind of the core, you know, why of the company and the skills that that early team brought. Sure, the why is Dimitri started GitLab in 2011. He was living in the Ukraine and he had two things he wanted to improve in life. He would like running water, he would like better collaboration software at work, and he started what he perceived as the most important problem to solve. So he built GitLab to have that better collaboration software. I only saw it a year later, and I thought this makes so much sense that the thing you collaborate with is also some of you can collaborate on that it's open source. Yeah, it's interesting because you say collaboration and we saw through the Enterprise 2.0 Wave and various communication technologies, I interviewed one of your partners Mattermost, which is kind of related there. You get there to GitLab, which in the early days, we heard a lot about, oh, is this a GitHub alternative? So how did the SCM piece end up there? Yeah, so we started with the SCM piece, that's what Dmitri made first because he had a need for it. And it evolved, it's now a complete DevOps platform all the way from planning what you want to do on a high level to monitoring, releasing, securing what you've built. And that wasn't intuitive to us. And it came about because Dmitri made version control, but he also made GitLab CI as two separate applications. And at a certain point, someone outside the company contributed a better version of GitLab CI. His name is Camille and we said, that's amazing. We'll make that official and do you want to join? And he joined and after a few months, he said, I think we should combine the two in a single application. And my co-founder Dmitri explained how he was wrong. These two were perfectly integrated, couldn't be any better. Custom API, same single sign-on, same idea of what a user can do. And I also explained how he was wrong because everything in the DevOps tooling space was a point solution and people wanted to mix and match. And he kept pushing for it. And at a certain point, he said, look, you might not believe that everything I say, but one thing is for sure, we'll be able to kind of ship at a faster rate if we combine it. And that was important to us. We were all about efficiency. But it turns out he was also right about the benefits for the user. People reported like, it's so much easier having everything in a single interface, being on the same page with my other departments. And that's how we stumbled across this secret, like, hey, this whole DevOps space, it started from just a few applications, but now people are using 15, 20 different applications and the handles between the applications were the problem and that we could solve by bringing them together. So we doubled down on that strategy. So that's how that came about. Yeah, I mean, there is no doubt that tool sprawl is a huge issue in the marketplace. Yet when you talk to developers, when they learn a tool, they tend to really love it and they all go to bat as well. I sorted it out and I found the best one for whatever piece of it. So how do you balance really building out a platform? But if there's a piece of it that they still wanna use, they can, how do you balance that? Yeah, you gotta make sure that you don't lock people in. Like the last thing someone wants is that they have to use everything. So open APIs, many integrations, some of which we maintain ourselves with Jenkins and a GRI and a GitHub. But also you make sure that sometimes people care very much about a certain piece of functionality. So with GitLab, if they don't like a certain piece, they can improve it, they can contribute back and every month, 200 improvements come from our users. They had something in their old application that they really liked and now they get to add that to GitLab and that's how you kind of take away all the objections over time. Yeah, I'd love you to comment on just the explosive growth that you've been seeing. You're now over 1,100 employees. You talked about how much outside a contribution you're getting there. But the amount of features that you're adding and you're releasing every month, how do you manage the growth of the company, the growth of product and make sure that the company doesn't lose focus? Yeah, I think we've done a really good job of splitting up the tasks, of making sure every team has a part of the product that they're responsible for and you don't have to go to five other teams to get signed off. And if you Google GitLab categories, you can find out exactly which team is responsible for the back end, for the front end, who is the product manager, who is the product marketing manager for a specific piece of functionality. So I think that's really helped us making sure the teams can still ship and they're not bogged down because other people don't have time. The mission is that everyone can contribute and you're looking to really help companies solve one of the key problems of being a software company which is reducing cycle time. How does that translate into growth and revenue for your business? Yeah, so that cycle time between planning to do something and getting it out to users, that's what companies need to become software companies. And they're seeing that they're able to do that faster with GitLab and we've seen amazing growth. We just announced we're over 100 million ARR. We're seeing amazing growth in revenue as well. We're more than doubling revenue every year. We've almost tripled the amount of people working at GitLab last year to keep up with that growth. Yeah, very interesting dynamic. You had a sizable round of funding towards the end of 2019. Congratulations on the milestone you said. In February 2020, you hit $100 million ARR. I guess the question, it's publicly stated that you're looking to IPO later this year. We've seen many unicorns out there delaying what they're doing. They wait until they have $200, $300 million in revenue. Is there a reason why you're charging towards an IPO? We want to become a public company sooner rather than later because first of all, we think it fits us. We're a very transparent company. We don't mind sharing what we're about and what our financials are. The second thing is, I think one of the big things holding GitLab back is that we're not as well known and becoming a public company will help spread awareness about what we can do. And that's one of the most important things we can do. So that's why we're going forward. We'll go public when we're ready, when the market is ready. We think that's this year and we might be wrong. We'll see how it ends up this year. But we're looking forward to that and we're looking forward to being even more transparent and also sharing our financials. Sid, one of the things you said, you're over a thousand employees and you're completely remote. As far as we know, the largest company that is 100% remote. Talk a little bit about the challenges from building a culture in that type of environment, but it's also something that I think GitLab's helping to enable other companies along that same journey. Yeah, we're figuring out a lot of things you have to do to be all remote and we're trying to share those lessons. And that's anything from working handbook first to communication styles and being intentional about informal communication. So if you Google GitLab all remote, you'll find tons of tips. And those are based not just on what we say but what we do. You have a public handbook of over 3,000 pages with all our internal processes. You can check what we really do to make this work. And I think it's gonna be the future. And the future companies who make digital products are gonna be much more all remote. And we wanna enable that trend. We think it's great for team members. We think it helps you reduce your commute time. It helps you be able to intersperse what you do at the company. With what you do in your private life, you're able to go to the gym or the supermarket when it's not busy. And also it helps to be more flexible. So it's great for team members. It's also great for companies. You get to attract people wherever they are, get much more access to talent. And the talent that people can stay with you year over year. We have an 85% retention of people who stay with GitLab every year. Is that something you think that spans across whatever roles they are? Lots of companies I talk to, they'll have their development groups will be highly distributed. We've seen global development workforces for decades now but marketing roles or product teams often have been in regional offices. Obviously, if you've got salesforces groups, often they will have regional offices. So is this specific for the digital and development type organizations or is this something you think will span across other roles? When we graduated at Y Combinator, they told us, well, this works for engineering. It maybe works for sales because they're close to the customer. It doesn't work for finance. It doesn't work for marketing. And I think we've proven that it does work. Our marketing team is all in on GitLab but also we've seen other marketing teams. There was a presentation today by someone who runs a marketing team and they're using GitLab, not just for the issues but they're even like version controlling, they're copy, they're messaging in GitLab. So I think the time has come to accept that the tools have gotten so good and people have gotten so knowledgeable that it works across all departments. Yeah, Sid, I'd like you to comment on your partner ecosystem. She said everything's open so therefore there's no lock-in. How do you build more community from your peers from the vendor ecosystem? Yeah, you see here today we have different vendors out that get customers here that integrate with us. There's vendors here. We have an alternative in GitLab but they have something that they think adds unique value and we want to give them a podium. We want people to know that we're not locking them in so we're very helpful. We're trying to be helpful, get them on our blog, get them media because nobody wants to be locked into one solution. So that's a really important message that we're sending. All right, Sid, I want to give the final word. As you said, people, GitLab is not yet a household name. What do you want to make sure that people understand who GitLab is and why they're important for the future of software development? So we're a complete DevOps platform delivered as a single application and we help people go much faster. At Goldman Sachs they went for the most important application they went from two weeks to get that out to door to two hours to get that out to door. That's the value we can bring because you don't have to go to 15 point solutions to get your work done. You have much better visibility. People can switch teams. You have a good overview of your security posture, your productivity. That's the value we're bringing. We can reduce people's their licensing cost, their cost of integrating things but most importantly we can help them go faster and get to revenue faster. Sid C. Brandy, thank you so much for joining us on the program. Really appreciate theCUBE coming to GitLab Commit. Awesome, thanks for coming. All right. I'm Stu Miniman, check out thecube.net for all the shows we will be at in 2020. Thank you for watching theCUBE.