>> Announcer: 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 Sijbrandij. Thanks so much for joining us. >> Yeah, thanks for having me. >> All right, so Sid, 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 'why' of the company and the skillset that that early team brought. >> Sure, the 'why' is, Demitri started GitLab in 2011. He was living in the Ukraine, 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 with 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 something you can collaborate on at its open source. >> Yeah, it's interesting, 'cause 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, I 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 Demitri 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 Demitri made Version Control, but he also made GitLabCI. That's two separate applications. And at a certain point, someone outside the company contributed a better version of GitLabCI, his name is Kamil, 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 Demitri explained how he was wrong. These two are perfectly integrated, couldn't be any better. Custom-made PIs, same single sign-on, same idea of what a user can do. He also explained how he was wrong because everything in a DevOps tuning space was a point solution, 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're 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 hand-offs 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's 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 to, well, I sort 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 want to use they can, how do you balance that? >> Yeah, you got to make sure that you don't lock people in. The last thing someone wants is that they have to use everything. So open APIs, many integrations, some of which we maintain ourselves with a Jenkins and a Jura and a GitHub. But also, you make sure that sometimes people care very much about the certain piece of frictionality. 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. Love you to comment on just the explosive growth that you've been seeing, you're now over 1100 employees, you talked about how much outside 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 the product, and make sure that the company doesn't lose focus? >> Yeah. I think that 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. They don't have to go to five other teams to get sign-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's the product manager, who's 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. >> Yeah, 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, the 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, so 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 dollars 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 300 million dollars 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, 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 1000 employees, and you're completely remote, as far as we know, the largest company that is 100% remote. Talk a little bit about kind of 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 communications. 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. We have a public handbook of over 3000 pages with all our internal processes. You can check what we really do to make this work. And I think it's going to be the future. In the future, companies who make digital products are going to be much more all remote. And we want to enable that trend. We think it's great for team members, we think it helps you reduce your commute time, it helps you to be able to intersperse what you do at the company with what you do in your private life, you're able to go the gym or the supermarket when it's not busy, and also it helps be more flexible. So its 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 a 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 that I talk to they'll have their developing groups, will be highly distributed. We've seen global development work forces for decades now, but marketing roles or product teams often have been in regional offices, obviously if you've got sales forces, groups that 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 all this work's 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 version controlling, they're copying, 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, that you 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 they 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, why don't you give the final word, you've 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? >> Yeah, 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 the door to two hours to get that out the door. That's the value we can bring, because you don't have to go to 15 point solutions to get your work done. 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. You can reduce people's, their licensing cost, their costs of integrating things, but most importantly we can help them go faster and get to revenue faster. >> Sid Sijbrandij, 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.