In true GitLab style, this is not going to be a one-way street of conversation. I encourage you to type in any questions, comments, observations on the YouTube live chat, or you can go on Twitter and use the hashtag GitLab live. So yeah, feel free to engage, tell us what you think, ask us questions and at the end of this live stream, I'll be taking as many questions as I can, no promises that I'll cover you, but I'll do my best. So with that said, let's get started. As I mentioned, there's a great lineup of guests, and the first one that I would like to introduce is our co-founder and CEO, Sid Cigrandi. Thank you so much for joining us, Sid. Thank you. So Sid has been behind GitLab from the very early days pushing us every day, every year to greater heights, and this year is no exception and then some. So the day you started with GitLab, did you think you would be here today? I didn't think that was 2012, and I did a post on Hacker News, a show Hacker News, like do you want to use GitLab.com? Because I thought, it makes so much sense that the software, all the software I used as a developer was open source, except the collaboration software. If one thing should be open source, it should be the collaboration software. But at that time, the income stream was donations, which Dimitri called ice cream money because it was $7 a month and we managed to up that to $1,000 at our best months ever. But for the first three years, I paid for the entire company out of my own pocket with $100,000. Wow, and some latest updates which we will get into, have added a lot more zeros as most people on this live stream at least must have heard already. So from that time, tell us about the GitLab of today. When Dimitri started with the product, it was version control and it's really good version control. But Dimitri also never wanted to upgrade a Jenkins server ever again. So he created GitLab CI and in the beginning, it was like, it's not a public project, it's just to test GitLab. But over time, it grew public and people started using it. Someone that we didn't know from Poland, Camille contributed a better runner for it. We made that official. We made him an offer to join the company. He agreed and he said, you know what we should do? We should integrate GitLab CI with GitLab diversion control. Dimitri said, no, that's such a bad idea. That's not how things are done in this industry. You get one bloated application, we should have many sharp tools. Over time, he grew convinced because there were some benefits in maintaining everything. They pitched it to me and I said, obviously, you're wrong. It's against the Unix philosophy. How can you do that? That's not what the whole rest of the market is doing. One of our values is boring solutions. Don't do something crazy. But they managed to convince me after some months and we integrated it and not only did it become much easier for us to develop, it became much easier for the end user. If you ran a CI job, you didn't have to pass credentials to your source code, pass credentials to the container registry. Everything knew who you were and what your rights were. These emerging benefits were so obvious that we said, hey, this works great, let's do that. By now, GitLab has nine different product categories that are integrated into it. So we went from just source control to nine times as much. I think that's really exciting because people have the benefits of that single application approach for the entire DevOps lifecycle. It's interesting what you mentioned as the mental roadblocks to deciding to make it a single application. I think a lot of people today are also like, is that really going to work and I guess it's working. I understand their skepticism. I was set the same thing for three months. So the proof is in using the application and seeing how easy it is that you don't have to switch UIs, how easy it is if all the information is in the single data. So we can show you what's relevant at any point. You don't have to wait for another team to hand it over to you. Yeah, I think that makes a lot of sense. So product-wise, things are great. We're from one to nine. Tell us a little about the company update. Yeah, so it really started growing after Y Combinator in 2015. We have the hockey stick over here. Yeah, the revenue is doing great. Also, the team greatly expanded. We were living in the same house. We were nine people in 2015. Sometimes even driving in the one house. One car even. Oh my gosh. It was a big Ford expedition. Now, 350 people in over 40 countries. And that's really exciting. But also the contributions. When I first saw GitLab, there were 300 people that contributed code. Now there's over 2,000 people that contributed code. Yeah, and I think that all this progress, all this amazingness is being noticed beyond the immediate circles of the community. I mean, just lately, Inc. 5,000 were number 44 on that list of companies and fourth top software company. And like, let me say this, this is just the beginning. We're gonna keep climbing up those numbers. And while in itself, this may not seem directly connected to the product or the business, but it's validation. It's proof that people are seeing what we're doing and I'm really excited about that. I think there's been momentum also on the enterprise side awareness with analyst reports, sorry. Yeah, for sure. We're really proud that we're not just being recognized for version control, but now CI. The first thing that we integrated into GitLab is now also best in class. Forster says, hey, this is better than any other CI system out there. So you don't have to compromise if you use GitLab. It's not like you get a single application but they're all like, meh, wanna be best in class. And really proud that we've achieved that for version control. And we'll end for CI and we'll go with the rest. Yes, absolutely. So changing gears a little bit. We did a live stream like this about a year ago. So since that time, there's been some major new things that have happened. I mean, one of the biggest in my mind is that we have poured it into security and we've acquired a company there. So tell us about why bet on security and what's happened with that. Yeah, security, we saw a lot of our users and customers struggle to have that DevSecOps lifecycle. There's a lot of products out there to add security to your DevOps lifecycle, but the developers didn't like using them. It was hard to use them. It blocked their work stream. It broke the build. So we were looking and then we saw a gymnasium and gymnasium had the best dependency scanning in the world. What they can do is say, of all the libraries and dependencies you use, which ones haven't known vulnerability and tell you that as soon as you start using them. And that was really interesting. And so we managed to have the team join GitLab and they've been prolific. Within the first month, they had integrated their product into GitLab, which is amazing. And right now we have not only the dependency scanning, but container scanning. We got static code analysis and we got dynamic application security testing all as a part of our offering. And they even added license management recently. So I think that security and compliance being a core part of GitLab, I think that's very exciting. Yeah, I mean, I've worked with Philippe and his crew and they're so awesome. I'm not surprised they've spurred us on so much in this space. And I've even heard from some customers that they're just delighted that security is finally part of the developer workflow. So it's working. Another new thing, and that's part of the reason why I was hired, was the focus on cloud native. So in my job, it's so much fun. I get to work with a plethora of organizations from cloud providers to open source foundations to startups doing things like Surrealist. And so we've gone in big in cloud native and Kubernetes is a big focus for us. So I want to ask you, Sid, why bet on Kubernetes? Yeah, we saw kind of two, three years back that Kubernetes would become the new type of infrastructure. The world went from bare metal to virtual machines that are now containers and Kubernetes would drive all of the containers. And for us, at the same time, we were thinking about going from just development to operations recently. We said, look, Kubernetes is such a great abstraction. We can use all the primitive pawns, deployments and make them work really great in GitLab. So in GitLab, you can now add any Kubernetes cluster to your project or to your group. And GitLab will know what to do to other DevOps. You push your code and we build it for you. We make the container, we test it, we check the code quality, we do performance testing, give you a review app to review it, and you can deploy to production incrementally everything you want. And that's possible because there's this abstraction called Kubernetes. So we want everyone in the world to use Kubernetes and then GitLab on top for the DevOps. Yeah, I think that makes so much sense.  And not just the management, it's the developers themselves, they just want easier access. And traditionally, it's been more frictionful. What I hear from folks who are using it the GitLab way is that it's click, click, go. And frankly, it's not just what I'm hearing. I tried it myself and it's amazing. So I'm very thrilled for where we go next with this. And we get all this, as I've been mentioning, I've been talking to users, customers. And that's because we have a very vibrant community. And I find that this community is the foundational layer for everything we're doing and achieving. Yes, for sure. You don't get to build nine best-in-class products with the engineers we have, even though we have a lot of them and we're hiring. We are hiring. We can't do it by ourselves. So those over 2,000 people that contributed, that's how a product can become best-in-class. And we're really excited that we've been able to balance our need to make revenue as a company, to do a lot of things that open source contributors are less likely to do with being great for the open source community. And the recognition that we're seeing is awesome. We recently switched to a developer certificate of origin because the Debian people felt more comfortable with that. I think that's awesome. Now we can promise you, if you contribute to GitLab, we'll never change the license. We'll never switch the license on you. It's you contributed it. It's your code. You own it. And it's been great working with Debian and GNOME and Drupal. They've been listening to us. We've been listening to them and making changes in our licensing and open sourcing part of our proprietary software to make sure it works for them. And I'm really happy they switched to GitLab. Yeah, that was one of the big moments for me personally, seeing these really foundational projects in open source that a lot of our industry runs on. They're now running on GitLab. That's such a board of confidence. I was definitely very thrilled. And I think the community in general is taking note. And the whole moving to GitLab momentum has been going strong. I mean, when I joined the company, I was all about moving to GitLab, hashtag moving to GitLab. So that's been nice to see. And all that has led to the big announcement that came out yesterday, right? Yep, for sure. We announced that we raised $100 million at an evaluation of over a billion. And that's going to give us the money. Go GitLab. And that's going to give us the money to become best in class. Because we have a lot of incoming contributions. But we've got to make sure we get them over the finish line, make sure they're all tested and documented, make sure we keep doing all the performance fixes, and make some features that developers are less likely to contribute. Things aimed at the CZO offer company, like the chief information security officer, having those high level dashboards. So we now have the money to make all those features, to make sure we become best in class in every single product category. Yeah. So you may cringe at this a little bit, but I just got to ask, how does it feel being in the billion dollar club, being a unicorn? It's exciting. It's when we came to Silicon Valley, why, Combinator, you explained to us, if you're going to raise money from external investors, your aim should be to become a billion dollar company. Otherwise, you should not raise any money. And we were seriously considering that. But we opted to raise the money. And now our early shareholders, we can feel confident that we've gotten here. But we again raise money now. So the bar is higher, and we're going to try to keep going to the company. That makes a lot of sense. Thank you so much for sharing all this with me, with the audience. I bet people learned a lot of things that were new about GitLab, and maybe were reinforced in some of the values and beliefs. Thank you for joining us. Yeah, thanks for the presenting. Totally. And folks, as I mentioned before when we started, I'm sure these conversations are bringing up questions, thoughts, concerns. Go to YouTube and put them in the live chat, or go to Twitter and do hashtag GitLab Live. And I'll take them at the end of this session. And now, as Sid was saying, we just raised this huge round at a $1.1 billion valuation. That's super exciting, and we've heard his perspective on it. But to me, I really want to know from the investors, why did they pick GitLab? And so for that, I have invited here today Matthew Jacobson from Iconic Capital. He's a general partner there. Thank you for having me. Thank you for coming, and we really appreciate your time. So Matthew has been a general partner at Iconic Capital, and he invests in both consumer and enterprise. Before this, he has, at one point, held a CEO in New York position at Groupon, and has had venture roles in battery ventures and technology crossover ventures. Some of his investments that stood out to me were in the similar space, like Datadog, Fastly, also in Vision. I think Uber was somewhere in there. And now GitLab. Yes. So now GitLab. Now GitLab. So Matthew, tell us a little bit. So if I understand correctly, Iconic primarily focuses on growth stage investments. So when you're looking at that stage of a company, what are the criteria? What do you look for? So I think there's a number of criteria. I think two of the things that get us most excited that we've seen drive the most value creation at this stage, Brickley and software would be just, we call it kind of product maniacal focus and product velocity. So product, product, product. And companies that show strength in this area, both in terms of the core products that customers are using and you're getting feedback, but also in terms of the broad vision and how companies are executing with velocity in terms of continuously shipping new products and new features with strength and ambition. The second lens is really the strength and quality of the team. We've been fortunate to work with just exceptional individuals across a number of different companies. And when those two elements align in terms of the alchemy, we've seen really exciting software companies being built. Yeah, no, that makes a lot of sense. And so then that brings us to like, let's zoom in a little on GitLab specifically. So what stood out to you about GitLab? Well, I think we'd had dialogue with sitting GitLab for I think, I think I looked at it, 821 days prior to the investment. And so we've been able to build a relationship and dialogue over time. And I think the two factors. Two and a half years, right? Two and a half years. And I think the factors that talked about really clear in terms of just the focus on product, that kind of product maniacal strength and just the speed and success that the company was shipping new products and new features. And also just the breadth of the ambition was something that we're excited about and excited about going forward. Yeah, no, that makes sense. So I gotta say, in my admittedly very limited knowledge of how growth stage investments work, it's usually more about numbers and metrics and spreadsheets. And now, given you guys' finance background, I'm sure we checked off all those boxes, but then the product focus is what it's really made a difference, right? Yeah, so we have a traditional financial background and underwriting focus, but in addition to that, I think these elements in terms of quality of how the team and how the employees really think about the business and the journey ahead and how the customers think about the business as a proxy for some of these elements earlier in terms of product are just so definitional in terms of what makes a really great software company. Yeah, you know, so product vision wise, some people are intimidated by the good lab product vision with nine categories. It's very ambitious, so I think it's always a balance between that breadth of ambition and kind of focusing and winning different categories. One of the things that was very exciting to us was, hey, the company had started in repo and version control and had built kind of emerging leadership in that category and then you were seeing emerging leadership in terms of CI and CD as well. We had a number of portfolio companies that were using these products and features and so had an opportunity to hear the experience firsthand and felt like there was real leadership in these categories and then you match that with the very ambitious vision in terms of the full DevOps life cycle and it's a very exciting future. So to some degree, the proof is in the pudding. You can say that. I love saying that, right? Sorry. All right, so you mentioned, right, that you've known Sid and talked to him for over two and a half years, I think. That's probably what 800 something days are. So what's it like? It's been amazing. I think we've been fortunate. So I don't want to generalize, but I will for a second. We've been fortunate. We've worked with actually a number of central and northern European founders, a company, Audien, that just went public earlier this year and just loved the transparency and directness in terms of working with Sid and some of those traits that kind of showed up. Like it was probably the first time in my investing career we were discussing a point around the investment and Sid made a point. I made a counterpoint and he kind of stopped and said, you know what, I thought about this in the context of our values as a company and I agree with this based on the values of our company. I'd never seen a co-founder and CEO stop in the middle of a conversation and take a value-based approach to an issue. It was really a special moment for us. Oh, that's amazing. So course corrected in the middle of the conversation based on our values. Based on the values. That's amazing. You know, I joined GitLab partially for that reason beyond the product momentum. It was like, the people here are straightforward and they'll tell it like it is. And it's just so refreshing. I mean, I've always had my career in the valley and I love everybody here, but this is a special kind of candor and I encourage everyone to be like that. Cool, okay. So now that you've told us generally what you look for in companies, what GitLab did that stood out as well as what it's like working with our CEO, what are you looking forward to in the next few years? Yeah, so I think it really comes down to what I said earlier, which is product, product, product. And so I think the product vision and ambition is so massive, excited to support the company and see this vision become a reality across a number of different vectors and build leadership in other categories of the DevOps lifecycle at the same time. Excited about the fact we've seen with a few other companies that have kind of grown in a very organic bottoms up way be it Datadog or Invasion or others that you build real user love and adoption at that level and then there's always an opportunity to build awareness with the more senior executives within large enterprise accounts and when those two things come and meet in the middle and Mary can be an unbelievable engine to then fuel further product innovation and so we're excited about that on the commercial side as well. Yeah, I think that makes so much sense. The next, we already have that developer love, that momentum from bottoms up and we're gonna now marry it with a top level knowledge, brand recognition and excitement about GitLab. Awesome. Well, Matthews, thank you so much for coming here telling us why you invested in GitLab, all the cool reasons and just being so straightforward and candid in the GitLab there. We are thrilled to be your partners. Thank you so much for having me. We're excited about the journey ahead. Thanks. So this is so humbling, right? When you hear from people who've invested close to $100 million into the company and given us this vote of confidence, it gives me a thrill and an excitement and a commitment to go and push for the company and all of us are excited to be on that journey. But a lot of what we spoke about with Matthew around the product focus and what we've built so far, it's happened because of the culture that Sid and his exec team have created for us not employees, team members, that's what everybody is here at GitLab. And I think it's really important to delve a little bit deeper into our culture because it's also very unique and different from a lot of companies out there. So I think it makes sense at this point to invite Barbie Brewer, our Chief Culture Officer to come chat with us. Hello, it's great to be here, exciting day. Thank you for coming, Barbie. So Barbie has been our Chief Culture Officer for over a year and so you know, I joined this company when I got the offer that I was so excited and accepted pretty much right away. And there were a few reasons for that. One was of course, having known and followed Sid's progress as a leader and the achievements that he's had. The second being just the product momentum which we've been talking a lot about so far. And the third, which was just as if not a little bit more important was my conversations with other execs on the team, particularly you. So what I noticed was every exec I spoke to had their own individual take on things and a commitment to get lab on a macro level. And what I really loved that was that I wasn't listening to some kind of party line on repeat but rather people were really sharing their own opinions and they might disagree with one person or another but that didn't, that was not a negative in any way. It was more like where the difference makes us a greater sum, if that even is a phrase, whatever. But that was a big factor. And I wanna ask you about that today. So as the chief culture officer working with these high powered execs, how do you balance so that the culture and the people, say front and center at all times? Well, that really is the whole focus of what we do and why we're here. We're driving an amazing product and amazing business. We have an amazing community but that happens because of the people and we recognize that as a leadership team. So we focus on trying to work with the best people, to get the best contributors in the entire world and to build the best product. And so we do do some debating and some storming and norming and things like that and all that good stuff but we really do have GitLab's best interest at heart. And we also, like you heard with Matt, we have the values really core to everything we do and so we do give each other feedback, we do push each other to be better and I hope that that is happening. I hope we're all growing with the company. So when you're in these discussions where there's push and pull, how do you barbie win? Well, I think the first thing I do is I don't focus on winning and I don't think any of us should. So I think, yeah, I think it really gets down to us all having different perspectives and ideas as sharing those and then making sure GitLab wins and not caring who owns the idea but just knowing that the best idea was pushed forward. Yeah, that makes a lot of sense. So this moment here is giving me a bit of a deja vu to about a year ago when it was the Series C livestream and you were introduced here as a new employee, a new team member then. And at that point, there was this big opportunity and challenge in front of you to grow the company very rapidly and do that with our values at scale and distribute it. So today, we're GitLabers everywhere in the world. I could just put a slide up which shows where we all are. As you can see, lots of countries. How many is it? I think we're in about 45 countries now. 45 countries strong. It's about a third of the world right there. By country count, prior geography probably more. But so tell me about from that time to now, what worked well, what did you learn? And then as today with the Series D announcement, you're at another inflection point, right? Because you have to grow the company yet one more time, scale it, but 10 acts like before. So what are you gonna take forward? So long question, but... Yeah, I know it's great. I think that we have over doubled the company in the year that I've been here and that's been very exciting and it's been a huge team effort. I've got an amazing team that I work with, a majoring group of recruiters who are working with some great managers. And so I don't think we've really compromised on our values or compromised on our bar for talent as we've done this growth, which is usually where companies will have a little hiccup is they need to grow fast and so they don't grow smart. And one of the things great about GitLab is we're growing smart, we're not just growing fast. And if we do that, then we should find that the company, the product can grow by 10X, but that doesn't mean the workforce has to. We have an amazing community that's helping to contribute to this product. We have amazing team members who contribute to this product.  So my important, the important thing for me is that I'm thinking about what the future looks like, what we need to scale, and that's going to mean that we need to evolve as a company, we need to grow, and that's gonna mean there's change. And change can be uncomfortable. But I really like what we have. We do, what we have is great, but there will be some change as we grow, but evolution's required. The alternative is much worse. But I don't want to compromise. Yeah, I don't want to compromise on our value and I don't want to compromise on our bar for talent and all our values are all critical. And so it's really about making sure we foster a very healthy environment and to grow the company in a great way. So speaking of values, right? So as we just discussed, we're in 45 countries plus. We're all very different and the common thread holding us together is our commitment to GitLab. So as you think of this culture and then growing this culture with more people, how do you handle the heterogeneity and make sure we're all adhering to a set of values that make sense for everybody? So what I love about the diversity we have at our company with people being from 45 different countries is we have such a diversity in perspectives and backgrounds and that only makes us stronger. But it can also lead to some difficulties because we have different backgrounds and perspectives and different definitions about diversity and inclusion. So the important thing is that we share what our definition of here at GitLab and I'll be honest, it's very much of a San Francisco bias definition of inclusion and that we wanna respect everybody that we work with. So we need to make sure that we teach that to the organization but we also need to make sure we empower the organization to help each other. So let's not just invest in the product but let's invest in each other and we can do that by giving each other feedback, pointing out where we've taken missteps, always assuming good intent and also thinking to understand but not leaving it there, also taking it forward to educating and helping each other learn and grow and that's really critical and it can be uncomfortable and there's very different ways that we do things here at GitLab and I know you've had some experiences in that as well and without your team members helping to coach you along it'd be harder to learn and it'd be harder to grow quickly and to onboard well and things and so having the help of your teammates to do that for you is critical. Yeah, I 100% agree. Recently I was in a bit of a rush and that was an important thing. I needed to make sure a group of people I'm working with knew about and so in the channel with that group I did at here and wrote my message and then was on my way, I was actually preparing for this live stream. And then I get a message from Sid being like, hey, it's no big deal but just so you know we should use at here when it's important and urgent and I was like, oh, okay, I'm so sorry about that and then I knew and of course the nice thing was that it was just so straightforward and simple that like, oh, this is how it should be this is that slacker ticket.  Yeah, it's different. Some of the technologies we're using are technologies that people haven't used before or we could be using them in a way that you didn't use before and so that's why our handbook is so useful too. It's, I mean, you do a search and you search get lab something question whether it's expenses or stock or hiring or uses or slack you will find an answer in the handbook and if you ask a team member instead, that's okay too. They might link to the handbook for you or they might give you the answer but that's one of the really important things about remote work is we have to work asynchronously and so that means that we need to document and write things down more, record things more so that if it happens to be your time at night or your time to drop the kids off or your time to eat dinner it doesn't mean you're missing out on important context and information and decision making and that you can still participate. So we have a very big robust handbook but it really is. Like the Ulysses. Yeah, it's really, really, really is meant to be helpful and everyone can edit it and make it even better and so there's a wealth of information there and I love that we open source it and we're not afraid to let other companies learn from what we've learned and it might help accelerate their growth too. Totally. Just being exposed to some of the things that we've learned and it kind of feels good to work for a company that doesn't mind helping other companies. Oh, totally. It's such a gold mine. I actually had some friends reach out from startups. They're like, you know, can you talk through this with us? We read it in your handbook and we're trying to implement it because it makes so much sense and we'd like to discuss it. You know, I say, that's awesome. Well, it makes perfect sense, right? Our whole product is geared around helping companies innovate faster and develop faster. So their culture and their way of operating is core to their growth too and so not only is the product helping them grow but the way we run our company and sharing that is also helping them. So it feels good. It feels good to work here. It feels so good and you know, we're global. So like these startups that I mentioned, one was a U.S. company and one was from Brazil. Yes. Doesn't matter, you know? People are people and we can all build together. So Barbie, as you're talking to us today, there's team members watching, members of the community, people who are borderline interested to everybody. If there was a thing or two that you could say, what would you want to give as a message? I would say that I would love for people to keep contributing for people who never thought about it before. Have a look, see what it's like. You might not even think you're technical but you might see something in our hamburger on our site that you think you can make better and don't hesitate. Go ahead and submit that merger quest and help contribute to this great movement we kind of have here to improve development tools as well as improve the way people work and then certainly don't ever hesitate to apply but you can contribute to GitLab without being an official team member but it'd be great to have more official team members as well. We certainly do have a lot of openings out there right now. Yeah, 70 plus I heard. Yeah, I think we're over 80 right now. There we go. So it's great to get those filled with the right people but it's also great to get contributors from the community. Yeah, specifically I'm on alliances and we're hiring. We're hiring in people ops too. I think every group can say that. Yeah, fair enough. Awesome, well thank you so much Barbie for coming here and talking with us. Thank you very much. I love our conversations. Me too, always a pleasure. Thank you.  She just embodies our culture so well. She leads us like such an amazing generous kind leader that I'm so thrilled to be part of this company. So we've been talking about the culture and the people and before that the product was referenced quite often. So this culture moves forward and we focus on building an amazing product that solves problems for the world's businesses. So I think it makes sense to hear about what have we been doing in the last year on the product side. So for that I'd like to introduce you to William Chia, product marketer extraordinaire to tell us what's the latest and greatest. William over to you. Hey, thank you Priyanka. Here's a clicker. I would love just to talk about what we've thought about for the last year. So just to give a recap of what our vision was and how we were thinking about the challenges and the problems that businesses were solving and just how we address those, what we've delivered in the product in the last year and go into it. So as we've chatted about a little bit GitLab first started out as a Git version control solution with just a little bit of issue tracking. But we had this vision that we could be much more, we could do the entire software development lifecycle. And in December 2016, we accomplished that vision. GitLab was no longer just Git, now it was an application for the entire SDLC. So then we thought, we did all of dev, could we also do ops? Could we also do dev ops? And so we began to look at the dev ops landscape. And what we found was there was a lot of problems and challenges that businesses were experiencing. For example, this is a typical dev ops tool chain that an enterprise might implement in order to develop and deliver their software. What they end up doing is you see there's a lot of different tools here in a lot of different categories. And they end up cobbling things together, piece mailing them, trying to wire things up to make them all work together.   As you patch and piece all of these things together, well, it ends up looking like something it was never really designed to look like. So as we've talked to customers and businesses and users, they kind of describe this as the tool chain crisis. In a sense, you're taking all of these things that were not designed to work together and trying to integrate them all to achieve a solution. And it's causing a lot of problems. It's really not working. So as a metaphor for this, I think we can look at something like working with Microsoft Word and if you've ever had this kind of experience. You have a Word document and you save your changes and then you have to email it to somebody else. There's only one copy. So then they make their changes and you have to wait on them to send it back. You can have version conflicts. You're always waiting for feedback. It's a very sequential workflow. This is kind of like DevOps with a tool chain approach where it's very opaque. You can't see what's happening across the tool chain because all of your data lives in all of these different tools. It's inefficient because DevOps is designed to break down silos, but instead the tool chain is creating silos because all of these teams are working with different tools. And it's completely uncontrolled. You don't have any type of governance to secure your solution end to end because the permission and security model across all of these tools is all different. And then securing your software is even more complicated still. So we think what if DevOps could be a little bit more like say Google Docs where many people can all work together on the same thing at once where you have one copy and one single source of truth where instead of conflicts you can receive real-time feedback and all of that can be done instead of sequentially concurrently together at the same time. So we think of this, the word that we use is concurrent DevOps, a single application for the entire DevOps lifecycle so that you can have visibility, so that you can have efficiency and so that you can have governance because with GitLab when you have a single application everything that you want that matters you have visibility into. So you can see everything that matters. Everyone across the team is working off a single tool and a single data source. It's efficient and you can collaborate without waiting. Instead of handing things over the fence, you can work together in the same interface and of course it's secure and compliant. You have a governance model across the entire lifecycle so that permissions and access are managed in an appropriate way so that everybody that needs access has access and not only that but the software that you are delivering is secured and you can ship with confidence. So last year as we had our story as we gave our vision, we told the story of an enterprise software developer. And we will tell, I'd like to just recap a little bit of her story and let's say this is Maria and Maria is an enterprise software developer. So what are the challenges that Maria would face and how do we solve them? So imagine Maria is a new enterprise software developer and on her very first day she's maybe gonna get her laptop. And before she can contribute, well she's gonna need to set up her keys because of course she needs access to be able to get to what she needs to get to and then of course then she needs to set up all of her dependencies to have her local environment. Of course after setting up her dependencies she's then going to need to troubleshoot all of her dependencies. And then before she can contribute, it goes on and on and on and at the end here is where she ends up contributing. But we thought to ourselves what if she could get started right away? What would it look like instead of waiting across this entire life cycle if you could get started right away? So in order to do this we set out to design and ship a web development environment and we're excited to say that in the last year we have shipped it. The GitLab Web IDE is an amazing tool today and we're just getting started. Now we don't think this is going to eliminate a local development environment. We know developers will always use this but what this does do is it lets you collaborate without waiting. Right from the GitLab Merge Request you can click on open Web IDE. You can start editing and contributing code all within the same interface. In fact I personally use this all the time. The thing that I like about it is I'll be working on a branch and I'll have some amount of code. And I'll have all of my local environment, the number of files I have open, the number of dependencies on my command line, everything is set even like the version of Python or Ruby. And all of a sudden a colleague will say to me hey can you review this code over here? And instead of me having to do a Git checkout and blow away all of my local state in order to review their code I can go right to the Merge Request in GitLab, I can open up the Web IDE and I can commit and share code to their Merge Request to help them out. And so the Web IDE lets me collaborate with my colleagues in a way that I've never been able to do before and we're just getting started. So we're excited that we've shipped that and we've got more improvements to come.  So what ends up happening is Maria will probably send her code over to the security team to secure it. And what are they gonna do? They're gonna say well it's not quite up to snuff so they're gonna ship it back to her.  All the while Maria has written her code but it's not delivering business value for the organization. So this is a typical workflow for enterprises. And what it does is it puts the development team and the security and compliance team at odds with each other. Instead of collaborating they have different goals. The developer's goal is to get code across the line and it's almost like the security's team is to not let code get across the line. And we just don't think it should be that way. We think that there's a better way for teams to collaborate together. So as you've heard that's why we're very excited in the last year we've acquired gymnasium, they've come on board and shipped an amazing amount of functionality. And we've delivered the integrated into GitLab our security functionality. So what's very exciting is we have software static application security testing where we statically read your code and put security privilege on it or we do a static analysis of the code. Then that code gets deployed into an environment and we dynamically, we do a dynamic analysis of that code. We have dependency scanning, container scanning, license management. This is an amazing amount of functionality that's shipped in this year and we're just getting started. And what's amazing is that all of that functionality is accessible from one place, right within the merge request or from within the pipeline view. So that means instead of the development team and the security compliance team being at odds with each other they can collaborate together in the same interface. We're really proud of this work that's gone so far but it's not enough.  We want GitLab to be a tool for security teams. That's why coming soon that we're working on right now is our security dashboard. We're looking to deliver this on October 22nd in GitLab 11.4 and this is a security view into GitLab, a dashboard for security personnel so that it surfaces the information that's most relevant to them. And from this dashboard that they can go into access to other parts of GitLab. We're really proud of that and we're excited for what's coming next. Coming back to Maria and her role as an enterprise developer she's been able to write some code. She's been able to secure her code. So how does she get her code into production? Well, let's look at what would happen in a typical enterprise environment. Of course, first she would commit her code. Then she has to work with the QA team to actually test her code. This is probably some tickets back and forth as we described as a try to figure out what's wrong doing the code testing but then maybe finally the code is ready to move to the next step which is then she needs to get on a release calendar. Her code needs to be scheduled with someone else's code in order to make sure it can all go out in place. And once it's on the release schedule then of course you need to make sure that the correct environments are permissioned. So she needs the organization will need servers or will need VMs to account for the expected load. And then of course we also talked about security. So this is just a high level view of the many, many steps that a developer's code we need to go through by the time it's written before it's in production. And we think this is just not the right way. A developer's written some code but the whole time it's sitting there it's not delivering value for the business. So we said is there a way to get this done faster? And this is why we are really excited to say that we have shipped robust Kubernetes functionality into GitLab together with AutodevOps. So in the last year we've added the ability to create Kubernetes clusters right within GitLab with just a few clicks on GKE and we've added Kubernetes configuration which allows you to install applications like Helm and Prometheus directly into your Kubernetes cluster with just one click. We're really proud of this functionality. We've just gotten started. And in addition to this ops functionality AutodevOps completely configures your pipelines and your monitoring for you. So what this means is instead of having to go through all of that for Maria when she all she needs to do now is commit her code to GitLab and then GitLab does the rest. AutodevOps running on Kubernetes configures her pipeline for her. It builds, tests and deploys her code into production with just one step. So we're really proud of this functionality. We're really proud of what's going on. But that's not enough. We don't just want GitLab to be an ops tool. We want GitLab to be a tool for operations teams. So of course on October 22nd we're looking to deliver what we're working on right now the operations dashboard coming in GitLab 11.4 which will give a singular view to operations teams providing all of the information that they need that they can launch off into other parts of GitLab so they can collaborate together with their entire organization. We're really excited about that functionality. Again, this is just a flavor. If you look at GitLab right now over the last year we've shipped major functionality and over 14 product categories. We're really excited about what's been happening and about delivering this type of end to end DevOps solution for the entire DevOps lifecycle. But what are our customers actually saying about this kind of concept of using one tool for everything? Well, Marcelo Lebre is VP of engineering at Unbabel. And Unbabel is trying to solve translation for the world and they're doing it using GitLab. And this is what they have to say with GitLab we're able to continually improve our entire product development pipeline which increases productivity and synergy among our team. So for Marcelo and his team they're experiencing concurrent DevOps in practice. What it looks like to get these types of synergy and collaboration gains. What it looks like to get a 200% faster lifecycle with these types of efficiency gains. So we're very excited about that. Looking back at the lifetime of GitLab you can see the velocity of product development starting out just as a Git solution adding CI and integrating that in. All the way as you look at this amazing development we've had this evolution from Git to now a single application for the entire DevOps lifecycle. You might ask how did you accomplish it? How did you get there so quickly with so much robust functionality? Well, the answer is we did it together. We did it together with our customers and our users. And we call that customer co-creation. Now you might say that every company in some way gets depends on customer feedback. But I think GitLab does this at a completely different scale. For example, at another company or at many companies you might have a PM that sits down with a customer and gets feedback and we do that at GitLab too. But in addition to that we have an open public issue tracker not just for our open source software but also for our commercial software. That means that everyone in the world can contribute ideas and comments and we're getting that feedback at scale. And it's working. Not only that, not only can they contribute feedback but if both our open source and our commercial version allow code contributions. So we have over 2,000 contributors to GitLab. GitLab is used by over 100,000 organizations with millions of users. And when all of those people are all working to build something together it means as everyone contributes, everyone benefits. And that's why we're so excited about our mission which is everyone can contribute. And it's why we're excited about concurrent DevOps which is empowering organizations to see everything that matters, collaborate without waiting and ship with confidence. What do you think Priyanka? I 100% agree. That was amazing. Thank you, William. Oh, thank you Priyanka. So William is my go-to person whenever we are trying to unpack core technology concept and explain it across to a wider audience. He helps me do such a much better than I would do job of breaking it down and explaining to the audience. So it was great that he could come here and speak to everybody. Now, as he said, our product has been benefiting a lot of end users and customers achieve their goals on the DevOps side. So I feel like it was good that we heard from William but to me, I truly believe things once I've heard them from the horse's mouth, so to speak which would be a user or customer. So along those lines, I am going to welcome here today on video call Michael Saboda who is the director of product integration at Charter Communications. So Charter is a very big enterprise company. So I'm going to be reading off some numbers that are going to be really big. So Charter is an American telecom company that offers its services to consumers and businesses under the banding of spectrum. It provides services to 26 million customers and then some in 41 states. It is the second largest cable operator in the United States and the fifth largest telephone provider based on residential subscriber line count. And they have 94,000 employees worldwide. Wow, I told you that was going to be a lot of big numbers. So with that, welcome to this live stream, Michael. Hey Priyanka. Hi, how's it going? It's great, very excited to be here and talking with you guys today and congratulations on all the recent, exciting announcements that you guys have been making. Thank you so much, it's very nice of you to take the time. So to kick us off, why don't you tell us a little bit about yourself and your role at Charter? Yeah, sure thing, so thanks for the intro, quite a big operation going on here at Charter. Being the director of product integration, my primary focus is within our product experience development and it's my job to make sure our developers who are working on our clients and providing a digital experience to our subscribers under that spectrum brand have a great developer experience, helping them realize that vision of quick iterations, giving them feedback, shifting these concerns like security and testing and deployments and getting that feedback early in our value stream where it's cheaper to course correct. Yeah, that makes a lot of sense. So in this next year or two, what are your biggest goals as you break that down? Yeah, so like I said, our biggest goals are kind of realizing on that vision of quick iterative development, shifting concerns left, GitLab's been a cornerstone of our DevOps platform, using it for source control management for continuous integration, continuous deployment, a Docker registry, artifacts. So really, how can we expand on the features that you guys are providing and create that single place? GitLab has been a tool that checks so many boxes for us. We wanna continue checking those boxes and give developers a single place to get feedback, self-service and do it in a responsible manner that allows us to provide quick value to our subscribers. Yeah, I think that makes a lot of sense. So quick question though. So as you mentioned, Charter is trying to shift left, right? And bring operations more into the developer's workflow. Why exactly did you decide to do that? I bet that's a big move. Yeah, it's totally a big move. I think we've seen signals in the market that consumers and subscribers are looking for different ways to interact with companies. They're looking for different ways to interact with us in a more digital way. Looking for different ways to consume content. Shifting these concerns left makes us be able to be competitive in creating these new digital ways for consumers to interact with us. Whether it's paying their bill or understanding how their account is set up, ordering new service, consuming live streaming video or video on demand, adding to our already valuable product just different ways for consumers to do this and doing it in a quick way that I think the rest of the industry and all these other businesses have created, the customers want that quick feedback. And to do that, we need to shift things left. Yeah, I think it's become table sticks, so to speak, with the growing impact of technology. And I think what you said is really relevant because so many large enterprises are shifting left or trying to shift left. And I think those folks will find a lot of value in our discussion today. So going back to the plan then, what are the areas where GitLab has provided you guys acceleration in this shift left philosophy? Yeah, so like I mentioned before, GitLab kind of checking all the boxes, being that cornerstone. The single application, you mean, right? Yes, absolutely. A single place to get all that feedback and be able to understand did my code merge in, did it build, did it pass the tests? Did it pass the security scan? These things in a single place within the merge request within that UI and seeing that, it's helped us come down and make feedback that was typically around our sprint cycle of two weeks-ish down to minutes. So now for front-end client development and prototyping, we're doing thousands of deployments a week, leveraging the GitLab runner system, a huge piece that we leveraged, as I mentioned earlier, it's been a great use case for us to be able to put the power in developers' hands, define their build context, garner the days of managing different build machines. It's all in the power of the developers. And now from the first line of code on every single branch, we can deploy a mutually exclusive environment and get feedback in minutes down from that cycle. Wait, how long was the cycle before? You know, on average, two weeks, within a sprint, merging the code at the end of a sprint, now every single branch of code goes up, picks up a global shared runner that we have, you define your own build context with the Docker functionality. Every single branch of code can have a deployment and you can have feedback as a developer, feedback as a product donor, as a designer, right away. Wow, so from two weeks to seconds. Yeah, exactly. I'm gonna call that meaningful. That's amazing, that's so cool. So tell me, it's very nice to hear that we have been able to help your organization make this move towards the DevOps way of doing things. And the proof, like as I said before, proof is in the pudding, favorite phrase. So I wanna ask, how did you guys find us in the first place? Yeah, so one of our engineers, Stefan Leighly, who's still with our team today, he found you guys early when you were out there. Could have possibly been from that show Hacker News Post that Sid was talking about, but he was out there, saw what you guys were doing, sort of started evangelizing it, and we've grown from about three years ago when Stefan introduced it into product to now about a thousand active contributors on the GitHub. Wow, that's amazing. So it seems like Hacker News is really important to us. Yeah. Okay. What you guys have been doing and a good evangelism of your product from the ground up as engineers in product. Yeah, it's like a true story of, the bottoms up developer love story. And I think that's so exciting, not just because of the way it happened, but that large companies like Charter are listening to the feedback from their team. They are listening to the feedback from their developers and then leaders like yourself are responding to it and creating strategies that are affecting the whole company's bottom line and brand. So that's really, really cool. So tell me, so you have so many people using GitLab and working with it every day. What does the GitLab team at Charter look like? Yeah, so right now, for what we're doing in product experience development, we have Stefan who I mentioned and another engineer, Tyler Horvath. And they're the two that run our GitLab deployment and the surrounding tools, which again, aren't very many since GitLab takes care of a lot. But they're kind of responsible for the deployment and the self-service developer platform that we have within product. And it's just two of them. And I think it's a huge testament to the ease of operations of your tool and taking a lot of sharp tools but putting it into one really sharp tool, it reduces that footprint of operations, right? So it's one, yeah, exactly. Sorry, just had to say it. We have a small team, which if we had eight, nine, 10 tools pieced together rather than just a handful with GitLab being that centerpiece, we probably need more than 10 people but we're able to accomplish a team of two right now. And so these two folks are able to serve a thousand plus users of GitLab at Charter. Yeah, I'm going to start calling them contributors now. Oh, we've got a thousand contributors. Love it, love it. We are co-creating here. Awesome, very cool. So tell me, I'm really glad to hear you've seen such a positive response so far. Where are you planning to integrate in the future with GitLab? Like what additional areas? Yeah, so right now we have a lot of things planned for the remainder of this year. You know, a lot of that's probably going to continue to change as you guys announce new functionality. I think we've seen signals in the community around moving to containerization, right? Especially for modern architectures, it has a lot of benefits. We've seen the signals in the community as well that orchestrating these containerized workloads with Kubernetes is the way to go. So that's the path we're on. We will continue to integrate with more functionality that you guys have there. And we're looking to run GitLab itself on Kubernetes before the end of the day. Oh, so you'll use the Helm charts deployment that we have. Yeah, yeah, you guys just went GA on that. So I think for us it's going to be even easier to operate and scale the individual components and move it on to Kubernetes. I love that. I was referencing this in the beginning of the livestream, but I personally have tried using GitLab to deploy to a Kubernetes cluster and it makes it so much easier. I'm sure your developers will be thrilled by this. So great plan. So thank you, Michael. This has been such a useful session for me. I'm so stoked just hearing all the great impact that GitLab has made in your company. And I just hope we can continue to serve you better and better as we go into the future. Thank you for taking the time to speak with us. Yeah, thank you very much, Priyanka. Looking forward to seeing what you guys have next. Sure thing. All right. Well, that was Michael Savoda. He was amazing. And I personally learned so much from that conversation. It's so thrilling when you hear from an end user telling you exactly how their company is changing. I mean, the feedback cycle going from two weeks to seconds, I'm still reeling on that number. But that was all about the product to date. So now that we've seen how GitLab has been able to help people with what we have today, I think it makes sense to look a little bit into the future. Now, every time that we announce our product vision, the internet is up in arms, they're like too ambitious, hold it, hold it. So I am really excited to learn about what it is and see just how ambitious it is going to be. So for that, I would like to invite Mark Fonsack, our head of product and one of the main architects of our DevOps strategy to come here and tell us about what should we look forward to. Great, thanks, Priyanka. Here's a clicker. Great. So yeah, we've heard some great news about the company and an update on where the product is currently at. So let's look towards the future and talk a bit about where we're going. We already have an amazing product for concurrent DevOps that covers the entire DevOps lifecycle in a single application. And customers are loving the new scope and where the product is going. And we're going to double down on what's working. So we're not talking about radical changes here. Our strategy going forward can be summed up with three things. Depth, breadth, and roles. And I'll talk a little bit about each. GitHub already covers the entire DevOps lifecycle, but not all categories are at the same level of development. People love our source code management, of course, and I always hear people raving about our continuous integration or CI. But some of the new areas are still early. Some are even just first iterations or what we call minimum viable changes or MVCs. So one big focus for us is to increase the depth of these features. We need to go from viable to actually used regularly to, dare I say, lovable. Now the idea of a minimum lovable product is a strong one. Of course, in our case, we have one product. So what we really need is minimum lovable features. Now it is great to experiment with minimal changes so you can learn from real usage and actually ship better iterations faster. And that's a core value at GitHub than many other companies. It's a key to delivering value to customers quickly, but we don't stop at a viable. We keep improving and listening to customers and better yet collaborate directly with customers to co-develop what they need together. And in this way, we can get to where people truly love using all parts of GitLab across the entire DevOps lifecycle. Now, source code management and CI are good examples where we're already leaders in the market. In 2019, we plan to become leaders in four new areas. First off, there's project management, and that's things like issue tracking and issue boards, really competing with Jira and Trello. Then there's continuous delivery and release automation where we're gonna continue to invest in deploying to Kubernetes, but really helping everyone automate their delivery and release processes. Then there's application security testing where we've already added so much in the past year with static and dynamic application security testing, dependency scanning, et cetera. So we're gonna really continue to invest in those areas and more. And a new capability for us we call value stream management, which might be new to a lot of you too, so I'll actually spend on that a bit later. Now increasing the depth of the product is great, but we wouldn't be true to our ambition if we stopped there. So we're also going to spend a lot of time increasing our breadth within each stage of the DevOps lifecycle. And the best way to show the breadth we're gonna cover is by showing you the new capabilities we're going to enable. In 2017, we had 22 capabilities inside the nine categories. We've delivered 14 new capabilities so far in 2018, and we have another 26 planned. Yes, 26 entirely new product capabilities. Every capability on the slide will be new in the rest of 2018 and into 2019. There's so much there that I really can't go into detail for each one, so I'm just gonna talk about three flows that give you a taste of where we're going. But before I do, I just need to throw out a disclaimer. These are mockups of how we see the future, but the actual features might look very different or may not ship at all. The first flow is from the executive perspective. It makes use of a new capability we're calling value stream management. Okay, we didn't invent the term. It's actually been around for a long time as part of the original lean manufacturing movement, but it's only relatively recently that value stream management has come to software development. For some of you, this might be immediately interesting, but I know a lot of modern developer teams out there are probably skeptical. So let me tell you why I'm really excited about value stream management. At its heart, it's about understanding your team's work and their workflow on their way to delivering value to customers. That can't be bad, right? But what's great about how we're approaching it is that we're really extending something development teams are already using to track their work, namely issue boards, and saying, well, instead of just tracking your slice of work, how about if we had a board that covered the entire workflow necessary to get ideas into production? But since GitLab covers that entire scope, we can actually automate all of this. We know when a feature is scheduled. We know when you push your first commit. We know when code review starts and we know when you deploy your code to production so we can move the cards to the right spots automatically. So not only can you track your progress and communicate it to your team, you can track it all automatically and more accurately. And then because these things are tracked across the entire organization automatically, executives can not only follow along, but they can look at some aggregate information and analytics on it. Here I'm showing a situation where someone was able to dive into the time spent on various areas and see that the time spent waiting for someone just to start QA was really high and they managed to shave off a few days just by rearranging some internal processes and the same thing for code review. The net result is right up in the top here. It says that the total cycle time dropped by 15% just within one month, which means you're delivering value to customers faster. The second flow is an operations one with a new product capability called incident management. We already monitor your production apps and detect anomaly and then alert you. Now we'll open an incident and then in one place you can see what triggered the alert, who's involved in responding, quick links to the Slack conversation, Zoom call, et cetera, and of course a record of all activity on the timeline. Now it's not just operations people using this tool, but it's part of the same application that developers are using. So when you're working together on problems, you're looking at the same data. GLab knows not only what metrics are alerting, but what code was recently deployed that might have caused it and who is behind that code. And one really interesting link on here is to the Runbook, which we recommend for you automatically. Here, we envision an interactive Runbook based on Jupyter notebooks that helps responders deal with incidents by not only providing instructions for things to investigate, but providing the actual commands to run that you can run right within the page and see and share the results. And we didn't invent the Runbook, but we're gonna make them so powerful and easy that every team will use them. And when the incident is resolved, follow up with your users with a post-mortem, pulling in all the relevant data and timeline of events. And of course, with all that data comes great power for analytics. So let's help the team learn from the incidents and improve. The last flow is about security, which we know is really important to a lot of our customers. So one of the common security tasks is watching for new vulnerabilities in your project's dependencies. If a module you depend on has a vulnerability, there's usually a patch update to go along with it. When that patch is released, you then need to test your software again with that patch to make sure everything still works before you deploy it. That's a pain. Some teams get the most junior developer to do it. But instead of making anyone do all that repetitive, but necessary security work, we want to automate it all the way. Here, a bot detects that a dependency has a new version and instead of alerting someone, automatically creates a merge request that bumps the version number for you and runs the test suite to make sure that everything still works. The CI pipeline passes and confirms that the security vulnerability is gone, so the bot automatically merges the changes. Now, if all goes well, your security and development teams just get an email in the morning saying that all the projects with that dependency were automatically fixed. But to bring a full circle, after merging, the CI-CD pipeline started incrementally deploying automatically to production. I mean, why leave a known security vulnerability to live any longer than it needs to, right? In this case, even though all tests pass, we actually saw the production error rate jump by 5% when it was deployed to just a few pods. So we automatically stopped the incremental rollout and went ahead and rolled back to the last known good version immediately. Then the bot detects this and automatically reverts the merge request so we can leave master in a good state. This we can finally alert the teams about. Instead of having to manually test 20 projects, they can focus on the few that can't be automated. So that's a lot of depth and breadth to cover. The last prong of our product strategy is to expand the roles or the people we design for. We already went from focusing on developers as recently as a couple of years ago to talking about DevOps, which of course is developers and operations. But for us, DevOps isn't just about developers and operations. Security's playing a critical role these days and of course there's the business side with project management and even executive visibility and reporting. But rather than call that biz dev sec ops or something like that, it's just DevOps. And of course we cover all these roles within a single application so everyone can work concurrently. We call this concurrent DevOps. But are those the only roles involved in software development and delivery? Of course not. There's designers and product managers, maybe even legal gets involved in license review. Remember our mission is everyone can contribute. We're building on strengths and going through an ever expanding DevOps lifecycle from designers to operations, everyone working concurrently in a single product with nine best in class product categories. Back to you, Priyanka. Awesome. May I have the clicker? There you go. Thank you so much for that Mark. I am so thrilled for the future. I love minimal lovable feature. That is, that's the sweetest thing really. Cool. Now that we've heard the product vision that is coming up, let's do what I promised you in the beginning, which was take questions from the live audience. So if you want to put in questions now, if you can enter in the YouTube live chat or you can go on Twitter and hashtag Get Lab Live. So enter it there, go on YouTube, whatever's comfortable for you. Keep them pouring in and I'll take as many as I can along with Sid here who is our CEO as we know and is back to help with the questions. Thank you for joining against it. Thank you. Awesome. Cool. So I'm going to start looking at the questions now. Let's see what we got. All right, so at Johnson from YouTube asked, I assume the revenue comes from the enterprise edition and the answer is yes. I would like to say that the enterprise edition contains everything that CE has, so it's best practice to download that. And then if you want, you can upgrade at any time without any downtime. So I encourage downloading EE. A question Sid from Aaron Walker, is Get Lab making a profit? Yes, great question. We're not making a profit in the accounting sense. We are making a great gross profit on every time we sell a product, it's software. Sorry, I don't understand and I think many people won't. So are unit economics really positive? So we make money every time by doing business. However, we're growing really fast. We're growing, we're almost tripling every year. And you need to pay upfront, you need to like hire sales people and train them to become effective.  If a customer buys Get Lab, we don't get the money immediately. And we put a lot of R and D in the product. So all those costs causes to, there's our investment, but you can't put them on your balance sheet. So those count as a loss. However, the company is extremely healthy and we can get to profitability at any time we want, but for now we choose to grow and to invest to become best in class in all these product categories. That's such a strong position to be in. We can be profitable any time we want. I really like that. Cool, so let's see here. Okay, Laurie Van Buell, sorry if I butchered your name, on Twitter asks, are we going to get deployment tool integration like Ansible, Puppet, Chef, et cetera? Deployment tool, tool integrations, I think. I would love to leverage Get Lab as a deploy platform for more complex setups. Yep, so do we. So we're going to add a lot more release automation features. They're going to be focused to a huge extent on Kubernetes, but we're very open to supporting also the legacy applications that people have to deploy. And there's people deploying with Get Lab to legacy environments, non-Kubernetes environments that works, but we want to make that better as well. And we also welcome contributions there. Yes, contribute, everyone can contribute. So, okay, then I see a question here. Matt Hagueman, again, I don't know if I got it right, asks on YouTube, could task management become a focus at some point? I'd really wish to centralize all my tasks in Get Lab boards, but Trello is still more elegant to work with. Yeah, we get Get Lab issue boards, and we want it to be as elegant as Trello. So if you have specific requirements, then please tell us. We spend a lot of time improving the UX, but there's still some way to go. So tell us what you like to see, what you're missing. And so people can tell us by creating an issue, tweeting. Exactly. The best thing is to create an issue on our issue tracker with a concrete proposal of how to improve something. Even better is actually sending us the code, but if you're not a JavaScript programmer, please tell us what to make. Many times the hardest thing is figuring out what to make, not how to make it. That makes sense. And I want to add a follow-up there. So often companies will say, oh, open an issue, and we'll consider it as part of our roadmap. How often do people's issues get looked at? Is it frequently? Just so they know. It's a lot. Right now we're on Hacker News with people that propose adding more curial integration to Get Lab. That issue has comments from Jakob Volschmaer, from Jorik Peterser, from Dimitri, like the author of Get Lab, Michael Founder. Like the specialists in Get Lab that are looking at that, and we're doing that, but we have over thousands of feature proposals. So we try to do a good job. We don't have some secondary issue tracker where we have our own stuff. We live in the same issue tracker, and we work there every day. So your issue will be seen. For sure. Cool, cool. All right, let me see for more questions. So Jason Friswold, my Vs and Ws are real, so I'll try it again. Jason Friswold, hopefully I got that right, asks, assuming most people work at home, is a lot of the day taken up with video calls or mostly slack, matter most, whatever? So I'll take a stab at this from my perspective. Yes, I do work from home, though sometimes I'll be at a co-working space, and I live on Zoom. That is like a real world to me at this point, and then GitLab itself, because that's where all our issues are, and that's how we project manage our whole life, and slack for async communication. So that's my personal experience. And then sometimes I get to be in-person with my colleagues at events like this, and that's always such a treat. What about you, Sid? What's your life like? A lot of video calls, and we encourage people all across the company, not just the management, but everyone to jump on a video call as soon as possible. There's something to be said for that like face-to-face interaction, where you can read each other's emotions, where you can interrupt each other, where you can quickly ask a question. That's much better than going back and forth for an hour on a chat client. So we encourage everyone to use video calls instead of sending messages back and forth. Yeah, and one of the latest things Sid suggested as we do is have a low level of shame, which is so that we can always have our video on, just because that way we can actually see each other's faces and react to each other as opposed to a perfect headshot. Yeah, so I want people to feel comfortable on a video call, like it's okay. I joined the earliest call. Sometimes I'm still in my T-shirt, like that's okay, your hair can be messy. And the low level of shame, I didn't think of that. Nat did the CEO of GitHub when describing our culture. He said, basically you're living with a low level of shame because of the features you ship all the time because we iterate. So the first iteration is always, it's not quite what we want it to be when it grows up. So that's an interesting part of iterating. That makes sense. And it's seeping through various parts of our culture, right? I really like that. There was a bit of an adjustment to just wake up and get on the video call, but I'm there now. Cool, so let's look at more questions. I see a question from Luciano Schermer again. For a Kubernetes CI workflow, do you recommend migrating to GCP? I think that all the cloud platforms will have a good Kubernetes as a service offering in the future. I think right now Google is there as the first one. We, one of our reasons to move to GCP is to use GKE, Google Kubernetes Engine. It's really solid, the upgrades are painless and it's really performing, so it's a great product. By itself, GitLab is cloud-agnostic though, right? Yes, you can deploy GitLab to any cloud and you don't have to run it on Kubernetes. Many of our customers run it in a VMware environment or somewhere else, so you can deploy GitLab from a Raspberry Pi to a cloud. We'll run anywhere and we'll deploy to anywhere. Nice, awesome. Aaron Walker asks, does GitLab provide transitioning support? Just curious, my team has 300 plus repositories. Yeah, we do. We got an entire implementation services team, so we can help with that. We can get your code out of old systems, whether it's SVN or Clearcase or Purforce, or maybe another Git provider. GitLab's got great imports. We support, we automate a lot, but we also have service teams that help our customers make the transition successful. Awesome, all right, so I guess that means call us maybe. Cool, so someone is asking, not someone, sorry. Eric Nantzow is asking, does GitLab incorporate data science within their operations? Are they actively hiring data scientists? Yeah, it's a great question. We think data is essential to running a great company. And we have a vacancy in, like data is incorporated in many parts of our business. It's so important to us that we started a new project called Meltano, that does anything from data source to dashboards and analytics. And we're hiring for a general manager there and for a product manager there. Nice, yeah, Meltano, just the name is so exciting. It's like, great things to come, Meltano. All right, let's look at another question. Raghu Kiran Reddy asks, is GitLab suitable for manually triggered jobs? Yes, very much. So if you use, for example, GitLab CI, you can manually trigger those jobs. You can set them on the timer so that they go every once in a while. And in the future we'll be adding serverless to GitLab so that it's easy, these one-off jobs, you can easily configure those. I'm very excited about serverless. I'm working on it, it's great. Cool things to come. All right, so TechKarala asks, will the CE version continue or when you go, if I understand correctly, or when you go public, will the licenses change? Yeah, so that license will not change. We will always have a version of GitLab that's open source and that contains many of our features across all the different stages. That's not gonna change and I'm very proud of how we've been able to keep the living great value in open source as we've grown and that will not change that's what makes us successful and what keeps making us successful. And that's one of the reasons we touched on earlier that we switched to the developer certificate of origin, that causes us to never be able to change the license. We don't own the copyright. It's now hundreds of people, soon thousands of people that own the copyright and we cannot change the license without asking them. So that will always be there. Nice. I feel like if the people get one thing out of this live stream it is that we will always stay true to our values. There have been so many proof points from different people that I personally feel very rest assured that I rest assured. Let's see. All right. L-O-L-M-A-O-R-O-F-L-HA-HA is asking, what are the challenges for GitLab moving forward? Open-ended, you can take it whichever you want. Look, we got a deliver on this great vision like Mark outlined an amazing vision. I'm really excited and that's just three examples but there's a lot of work to do and we've got to make sure all the teams stay effective and they keep shipping. Every time a team hasn't delivered in a while we worry and we try to fix it. So we've got to keep up that pace. We've got to be a great destination for if people contribute code we've got to follow up. Right now there's 240 merge requests that people contributed that we haven't brought to the finish line yet. And that's where we should focus on that. And we should not make mistakes and one of the mistakes could be doing something that alienates the community but it can also be for example a security breach of GitLab.com. Right. And we should keep up the good work. The team have done a great job of making sure GitLab.com is performant and available and we need to continue that as well. A great 100%. So I'll take one more question from the list here and then I have a question. So the question is, are the Q5 S.Y.S asks on Twitter, are there any plans to support alternate open source operating system technologies like using jails on free BSD? I think we're, our installation is already available on a lot of platforms. So we have installed for many operating systems, many UNIX operating systems. If the question is more about where do we deploy to, you want to deploy into jails, that's fine. So GitLab CI is very versatile. You can script it any way you like. So we already do. And if you want to contribute something that makes the experience better, we're open to that. Awesome. So the last question, bitch, I'm going to take it because I'm the host. So I want to ask you, I heard, you know, just a bird told me that with all this innovation on the DevOps side, we have a big goal of what we want to do for our users and customers there. Like, can you tell us what that is? I heard we want to make a big improvement. I think we talked about a lot today, but what did the bird tell you because I don't know. Well, the bird told me that we are going to improve the, reduce the DevOps lifecycle by 200%. Yeah, I think that's what we're seeing at customers. We're already seeing it. We're already seeing that. 200% improvement. They get three times faster just by having GitLab. And it's because they don't have to wait until a team hands it over. We've seen some customers where the number of steps to get something from idea into production, it was like 29 steps. Some of the steps consisted of opening seven different tickets. That is easy to solve. Some of our customers have started shipping 15 times faster with GitLab. And that's what we want to do because if you do that quick and not only is it better time to value, like it's good for the business, it's also super motivating. Like, if you make something, you want to see the results. You want to see how people experience it. You want to get compliments for your work. You want to monitor it. And you don't want to have it deployed a month later when you totally forgot about it. So that's why GitLab is helping people to go. And I think that's exciting. And the more of the DevOps lifecycle is in GitLab, the faster we enable people to go. Yeah, it's like what Michael was saying from Charter. They've gone from two weeks to get feedback to seconds. It's like we're way overachieving on the 200% already. We should up it a bit. We can guarantee that people will get that 200%. Yeah, no, that is so exciting. Well, thank you, Sid, for taking the time to answer these questions. I know I couldn't get through all of them. And I took the last one. I don't feel so bad about it. But thank you so much to the community and everybody here who joined us. I really appreciate you listening, engaging, talking. And I hope you learned a little bit more about GitLab and found it exciting. Please keep the dialogue open and stay in touch with us. Let's co-create a better world for our industry together. Thank you so much.