 And so the idea, even with Terrapro, absolutely, so just the idea of, it's all there for me. It's all there. If you were going into an area, an era of microservices, so we're going to have a lot more projects. And if every time you start a project, you have to set all of this up, it's tedious, it's boring, and you can customize it if you want, but we're just going to make sure that it's a great experience out of the box, so you're not going to waste time on that. You can spend your time with the application. So that's 10.0. That's where we've been. That's what you guys have been up to, but to the future now, you have some changes coming. Well, first of all, in a company, one of the most important things is to have great leaders. People don't quit the company. They quit their boss. So I want to make sure that we have great people at GitLab. It's good. And we have a few new hires I'm really excited to tell you about. Joe Sherman joined as our chief marketing officer. Barbie Graver joined as our chief culture officer, so she's running the people department, and she's the steward of the GitLab culture. And Eric Johnson joined as our VP of engineering. And we're fortunate enough to have Barbie here with us today. Barbie, thanks so much for joining us. Hi, guys. Thank you for having me. Welcome to this GitLab live event. Great to be here. You've got a history in a deep history, 20-plus years in HR culture development, companies like Cisco, Netflix, and now GitLab. Yeah. Why GitLab? Well, GitLab gave me the opportunity to actually feel like I can make a difference again. I think that after I worked at Netflix, I wasn't quite sure I'd want to go to another company again. But after I met Sid, I recognized that he understood the value of people. He understood the importance of culture and values at a company. And he also really showed in the way he's built a company, the importance and the belief in transparency. And I think transparency is really key to productive operations for any organization. I think in order to have an inclusive environment, you need to be able to be direct and honest with each other. I think in order to have a high functioning environment, you need that as well. And so I appreciate that all employees have all the information and that we're not trying to keep anything hidden. So in addition to that, I think that GitLab came onto my radar screen even before the recruiter called me. And my fiance actually owns a company and they had been using a competitor. And about two weeks before Sid and the recruiters reached out to me, he came home talking about how they were all switching to GitLab and how much happy his engineers were with that. And so I was kind of like, okay, what's this GitLab thing? I had heard about it. And they called you. Yeah, I had heard about it a little bit. And almost felt like fate that I had heard about how great it was. And then they were actually calling me. And I felt pretty lucky. So in the face of your job in culture, culture officer, chief culture officer, you've got a remote friendly first company. How hard is that challenge? What do you plan to do there? You know, I think in some ways it makes things less challenging and in some ways it makes things more challenging. I think that we should be able to have a lot of diverse perspectives because we have people from around the world either contributing or working directly for us. And that's a huge benefit to any company to get those diverse perspectives. In the same way, we have to make sure we're hearing those perspectives and we're getting those perspectives because with people being remote, we have to make sure we're providing a platform and an opportunity for those voices to be heard. And I think that we're doing a great job at GitLab so far, but I need to make sure we can scale it. And so I think together with the leadership team that we have, I have every faith that if it can be scaled, GitLab is the company to do it. And then I hope that we can then inform and help other companies how to do that as well because I think it's great for families, great for individuals, great for the environment and great for communities. Families first for sure. There's been a lot of problems in the industry with culture. I've never heard of a chief culture officer. Maybe that's a thing already. Probably it is, but you're the first one that I've met. This is like a whole new line of things that we know are so important that they get a top level title like that. Can you talk about the importance of that in light of the current culture in Silicon Valley and in the tech industry in general? Yeah, well I think Peter Drucker said it best when he said culture eats strategy for breakfast, right? It doesn't matter how great your strategy is if you don't have the right people to execute on it and inform it. And I think that culture plays a huge role in that. And everything that we do at the company needs to track back to strong values in some way. We shouldn't have any HR program or HR process that doesn't support the business and the strategy of the business and what we're trying to accomplish. And so many companies, you know, their people ops, their HR leaders may have a wonderful degree and had gone to some great schooling. It's almost having to forget what you've learned to reinvent what is best. And that's what innovative companies do in their products. They're not just trying to follow others. They're trying to do something new in the marketplace that is better than what has happened before. Well, people ops and HR teams should try to do the same thing. They shouldn't just follow other people. They should be thinking, what is this business? What do we want to try to accomplish? And how should we run our company? What should our values be? And everything we do and everyone we hire and everyone we promote should track back to those values in that culture. So coming in from the outside, a company that's existed now for a while, a culture begins with from top down or from the inside out, right? Who you are. What are some challenges that you face and how are you going to integrate yourself into GitLab in order to do your job well? Well, that's a great question that I might not have the entire answer to yet. I think that as I navigate these waters and this new opportunity, I will probably make some mistakes, and we all will, but hopefully we learn from them and we can keep iterating on what we're trying to do and keep making it better. And I don't want to be afraid to make a mistake such that I don't end up encouraging new bright ideas and new possibilities. So I think that, one, I will try to get to know everybody and I'm doing my best to do that now. We have some great things in place at GitLab and enable our employees to get to know each other and so participating in that and then also trying to iterate to make that better, I think will be a key opportunity for my team and I. And as well as the things like the summits that we do where we can get together with people there in order to get to know the employees. But then I'll be trying some new things and I'll be throwing some things against the wall and seeing what sticks and hoping that the great things do. So it'll be fun and interesting and I'm really looking forward to being able to put my mark on things and SID is a great partner for me in that. So to all the GitLabers out there watching this right now, they're meeting you potentially for the first time to some degree, right? What message do you want to send directly to them? If you were speaking directly to those folks. If I was speaking, well, I am. Hello everybody. I would say thank you so much for being at GitLab and I really hope that all our contributors and all our employees can make sure that they feel very comfortable reaching out to me and giving me their ideas and perspectives and sharing with me what their pains are and what their delights are so we can continue to build off what's great and improve what's not. And no company is perfect and no human is perfect, so we will all get through this together if we're all putting on us with each other. So I love to hear the hard stuff that people don't want to hear because hearing those hard things is what makes us better. Well, Barbara, thanks so much for joining us. We'd love to catch back up with you in six months or a year and just find out how it's gone as you kind of step forth to your job. Thank you very, very much. Great meeting you. Thank you. So there's some new executive members of the team. Yeah. What else you got? Well, we got one big announcement and that's that Google Ventures decided to lead a round in GitLab. So we're getting a 20 million dollar C round. Nice. And that's more than double the valuation of our previous round. So we're really excited for Google Ventures to lead that. And we found a great partner in Google Ventures and a great partner at Google Ventures. His name is Dave and he's on the forefront of cloud native computing. And I was really swayed by his vision of where the industry is going. From bare metal servers to virtual machines to cloud native Kubernetes container schedulers. So I'm really excited to have them lead the round. Well, congratulations on the round first. Yes, of course. And we're lucky enough to have Dave here. Dave. Talk to us about it. Good to have you, brother. Thanks for having me. It's good to be here. You've got a big background, right? Kiva Systems, your background at Google Ventures. You've built a million dollar company. It's like multi-million dollar companies. You've helped do that. And now you're here at GitLab and the easiest question would be just simply why GitLab? I couldn't be more pleased to be involved with CID and GitLab. I think it's a tremendous community. When we think about investing obviously we want to be involved like any other venture capital firm. We want to be involved in the fastest growing companies in the world. We think about that a little bit differently than most firms in that we are looking for dev-focused tools. We think software will disrupt the enterprises of the future. And so we think the best tools that create the best software teams and help enable and empower the best software teams will become enormous companies over time. And we're certainly seeing that with GitLab. We saw that in other investments like Slack, CoreOS, Cockroach Labs, three companies that I'm deeply involved in. And for us the enthusiasm around GitLab is two-fold. It's one, what we hear from CTOs and CIOs that we talk to and their enthusiasm about working with CID's team. And the other is the development community. I mean this community is tremendous. And when you talk to engineers across the valley and across the country and now around the world, they say tremendous things about GitLab. We've been we've been pleased so far. So tools, strategies, ideas, business plans, these are all important things. What I hear a lot of investors say is that they invest in people and teams. I assume that's also a huge factor in the investments that you all do. So act like he's not sitting over there. What is it about CID and the team at GitLab that attracted you as well to the market property? Yeah, so I think it's very difficult to decouple the product and the team in a company at this stage. I mean, essentially your culture is your product, is your team, is your identity. I mean, you're communicating out to the world with every change that you make in your product, right? And so we really we get a great feel for how fast the team works, how well coordinated they are and the breath of the contributions to the GitLab project just through the product itself. But CID's been fantastic to work with from the very beginning. I've been chasing it down for, what, a year and a half trying to invest in this company and we're pleased to finally be able to get involved. Wow. So you chased him down. Of course. Yeah. That's the best investment I've found. That's awesome. So this company is an open source company. You mentioned Corawez, Cockroach Labs. That's right. What was the other ones? Slack. Slack. Well, not Slack. Not open source. Cloud Air is an open source company. Okay. So what is it about open source companies for you in terms of investing? Why open source? Why this kind of company? Why is that a good mix? Yeah. I mean, we're seeing a few trends. Obviously the most secure and the best software in the world, I think, is open source. We're also seeing this trend towards clouds creating these, like, closed ecosystems. And that's a concern, right? So we think the best companies will sit across many clouds and be multi-cloud and hybrid, just like GitLab is, and be able to provide a solution across these large vendors who are essentially creating their own walled gardens. So whenever I give somebody my money, the first thing I usually think is, you know, what are they going to do with it? So if we had to ask, now that's up to the team. Yeah, that's right. Of course. If I could ask you, what would you like to see GitLab spending the money on? It's funny, I always joke around that you learn the most about a company in the first meeting that you have after investment. And so often, you'll invest in the company and show up in the first board meeting and sit there and either you walk away from that board meeting and say, wow, I made a great decision or you walk away like, ah, we have a lot of work to do. And in this case, you know, I had lunch with Sid on Friday, immediately after the round closed and we had a great conversation about where the company is today, all the changes that they've made just since we closed diligence, not too long ago and, you know, Friday. And I've been impressed just already in the trajectory of the things that are already in place. You know, Sid's got the plans down and he's already spending the time and attention that it takes to build for the next level. So as an investor, what's your role? Like, day to day. Yeah. So at GV, we get a little bit more involved in companies than you would expect. I'll meet often with Sid. We'll figure out the five or 10 different ways that GV can add a lot of value. Often that's connecting him to people that we know or generally one or two hops from people that could create a lot of value for Sid. It's helping him find great, great hires. You know, I couldn't have found a better culture officer than Barbish, who's fantastic on here. And I think, you know, finding other leaders across the organization who are at that level is really important. They already have a fantastic team. As that team continues to grow, we'll be helping them find best in class folks. Very good. Well, Dave, congrats on getting involved. Thanks so much. Time to catch it in. Yeah, seriously. And thanks so much for joining us today. We're super excited. Thank you, Dave. Take care. So, Sid, that's Dave, member of the board, not the only member of the board that you're having to announce today. What else you got? Yeah. We... a great team at the company is important, but it's also very important that there's great governance at the top of the company. So our board of directors, they set the tone of what we're allowed to spend our money on, what we do, how we approach the balance between open source and closed source, the features that we make money with. And I'm very excited to announce that Matt Mullenweck, the CEO of Automatic and founder of WordPress, decided to join our board. And I think he's... he's a leading figure about thinking about open source and how to build a business on that and a remote-only work culture. So, I'm stoked. Well, you don't have to tell us too much about Matt. We're fans from... We're huge fans. From way back, we've had Matt on the show and we're fortunate enough to also have Matt on the call. Hi, Matt. Matt, you're joining us virtually from New York, right? Yeah, New York City. Gotcha. Well, it's awesome to have you here today. Obviously, it must be a big thing for you to extend what you've done already in open source to now lend your expertise to this company. Why? We've asked everyone pretty much the same question, but why GitLab for you? Can you say that one more time? I heard him. I want to hear it again. GitLab is the future of development. You said that, right? I heard so. Okay. You've heard it here first, everybody. I mean, that's not first-first, but first from Matt. Matt has a lot of influence and having him say that said, I mean, that's a big deal. It's a big deal. You have certain heroes in the open source community and then you're excited. I get to video call once with Matt and he might not remember, but I remember very well and you feel like, wow, it's amazing that I'm now in a call, but to have him on the board and involved in the day-to-day of the company is awesome. Matt, there's obvious alignments between the core philosophies and the values of your company and GitLabs. What about the products, just thinking out loud? Is there anything down the line with GitLab and WordPress? Are there any potential there? I don't know. What do you think? That is a big conversation. Oh, we have all day. No, we don't. There's a lot of people that do work on development day-to-day, but I think something I don't mind is, you know, probably WordPress is still on track and self-proclaimed. So I think that it's not our top priority that should end in the future because we're focused on things like in-birth in the future, it definitely is on the radar for places to improve. You just put him on the hook. Look at me in the line. I'm doing sales now. Yeah. Okay. We're hiring for sales. Anytime. Back then do it. Maybe keying off that is there's obvious parallel between what you've done with WordPress over the years and what it's doing and trying to do, obviously, with your help and everyone else's help. What parallels do you see there between the companies, between WordPress and GitLab? You know, Sid talked about GitLab. It really was an inflection point because you got this kind of flying view of companies supported but community really, maybe a bigger part of that led to development, making the more usage region more developed and more usage. So I think GitLab has the potential to have this remote and exit velocity open source. You know, that kind of flywheel when the usage makes the product that much better. So the other aspect that you mentioned is the remote side. So what are some angles into the distributed remote team, not the software, that you've been able to learn from Sid and vice versa so far? Hmm. Well, one of the things I've definitely learned from GitHub's approach, sorry, GitLab's approach. That's certainly in the morning. The, is how transparent the company is. I actually submitted a pull request to one of Sid's pages. I just love that, whether it's a sales manual or sort of the internal onboarding documents or pretty much anything, is out there for anyone to see. And that sort of challenged me to think about how we can open up more of what we talk about and do internally and automatic because to be honest, there's no reason for much of it to be internal just to us that we're very thoughtful about trying to not have any proprietary software and open source as much as possible. And I'd love to do that for more of our culture. So as we move forward, you may have said it, but kind of give me a more clarified version of it. Like, what do you plan to do in terms of, as a board member, on a day to day, week to week basis, how do you plan to or how will you help Sid do what he needs to do to grow this company? Yeah, as a board member, you know, there's a number of ways that you're involved. There's the government tax best that Sid mentioned already. But more than anything, I want to be there to help with whatever he says he needs. Something I've always appreciated as growing automatic is not being, not sort of being like a helicopter board member where you're like hovering over the company all the time and bugging them, but being responsive and available whenever anything's needed. So the other thing I'm looking forward to doing is just learning a lot personally. This is a different side of open source that I haven't had as much experience in yet. And already in just that first board meeting, I was taking ton of notes and Googling a ton and everything. Imagine I probably have a few more months of that still. Well, Matt, we'll let you go. While we have you, we'd love to get you back on the show to talk about Gutenberg here. Sure. Absolutely. That would be a lot of fun. There's some really cool stuff coming around the corner. Yeah, sounds like it. Sounds like it. I'm always taking the time to get it in there. I have a sale. It's a tough sale sale. It'd be a good show. Always be a good show. Yes. Well, thank you, Matt, so much for your time today, man, and appreciate you being on the board. Absolutely. Bye-bye. It's good talking to you. See you in a minute. Wow. Okay. So we've got Dave, we've got Matt, we've got a whole new exec team, lots of people added. You told us where the product's gone in the last year. We've talked about 10.0 and all the releases. We've seen some of the team and the board members. Let's get back to the application. Let's see what your master plan is part two, what you got? Yeah. Well, master plan part two is going from death to complete DevOps. Okay. And I'm going to unpack that. We started with GitLab and it was version control and an issue tracker. Just that, just a limited part of the development lifecycle. Now, last year, we announced our first master plan and that was to make GitLab a complete development solution and all the missing pieces. And we did that. In December of that year, in half a year, we managed to ship a complete development solution. Hold on, hold on, hold on. So master plan in September announced, or was that October? It was in, yeah, in summer. Summer. Okay. August actually. Call it August then. Summer master plan announced December master plan achieved, that's either a very impressive where you didn't quite shoot for those guys. What's the situation here? I think, I think we, we had a lot of parts that were ready. Yeah. So we were, we were trending in that direction. Gotcha. We were on that trajectory, but also the team and the rest of the wider community put in a lot of hard work to make that happen. And it was a bit of a stretch and I can see, but I think back about 8.15, parts of the new things we introduced took a little bit of polishing after that to, to be up to snuff. But we, we managed to kind of set, complete it. And then we try to iterate and make it better, a little bit better every release. The important thing is you set some goals. Part of that master plan was actually telling the world what you're going to do. Right. Like these were in plans, in progress. Right. And then a few months later. Yeah. I think it's, it's very important to have a vision of where a product is going. If you don't have a vision, it's not very exciting for people to contribute to those important pieces. It's also not very exciting to work at the company or to, to join the company. If you, if you don't have a goal to work together towards as a company, what is the goal? If you're not working as a team together on that, people, people start, they need something to do. They'll optimize for something. They'll, they'll start a turf war. You got politics, etc. Right. I think it's very important to have a, have a goal to strive towards that that's ambitious and compelling. Yeah. All right. Tell us about your, your goal then, what's your vision here? So we want to go from just that death cycle to the complete cycle. Death ops. And we want to complete that in 2018. We're giving us ourselves two times as much time because we think, You're hedging. You're hedging. No, it's a lot more work. It's a lot more work. Where this is coming from is that it used to be that development and operations used to be separate parts in a company, separate groups, and they had their own tools. And those tools were different. You had, you needed different expertise to, to do, to operate them. Now, DevOps has said, look, you need to, those groups need to align. They need to become integrated. And what happened is, people took the tools from the two different departments and they tried to glue them together. They duct taped the tools together. And that's what you see in traditional DevOps. It's the glue between the old, the traditional developer tools and the traditional operating tools. And it's not a very good experience. You can see the duct tape and it keeps breaking the entire time. So we want to do something different. We want to extend the complete set of tooling we have for development and extend it all the way to operations. So it's not going to be gluing two sets of tools together. It's about creating a single application that does both. We like the definition of complete, having all the necessary and appropriate parts to make something whole or perfect. That's the ambition. And we think that has a lot of advantages. You get a single user interface. So you don't waste time switching between tools or concepts. All the phases are integrated together. So it's easy to go from one phase to the next. Developers and operators, if the roles are still separate, at least they have the same view on what's happening. They have a common way to work together. And we think there's a giant opportunity. There's over 100,000 organizations using GitLab and they encode their best practices in the tool, the way they work is encoded in the tool. So the GitLab application helps you to have a better DevOps process. Now, it's our job to make sure that it's a single install, that updates, that don't break, and there's no integration work. And I think one of the reasons GitLab CI is so popular is because with other tools you can install 2,000 plugins, but you upgrade it and those don't work together. With GitLab, we add over 1,000 tests every month. We in the wider community, because we want to make sure all those integrations work, and when we release a new version, all those tests are run. So we make sure that it works together. And that should be the case for the whole DevOps lifecycle. It shouldn't be a team at your company trying to invent these tools. And last but certainly not least, one permission model. If you're a developer, you should be able to carry forward some of those permissions all the way into the operations lifecycle. So you have visibility there and influence there about what happens. So maybe give a bit of perspective and talk about an example. We want in the end of 2018 a world where if you used to join a Fortune 500 company, it takes a week to set up like your complete environment. We want a Sally that joins a Fortune 500 company to get started on the first day, have a complete IDE in GitLab that leverages our CI CD infrastructure and it allows you to make a contribution, a merge request on the first day. Suppose Sally does that on a module. That module is automatically packaged, released, and because she changed the model, the module, the application that's dependent on it will also go through a release cycle. Now suppose there's a bug in the new code. GitLab should roll it out incrementally and at 5% of users, the error rate spikes. It's rolled back. Sally gets a notification, goes into the merge request, sees the relevant logs, sees the relevant graphs, is able to figure out what the bug was, fix it, and out goes the new change and this time it's perfect. And what the takeaway is is that instead of waiting a week to set up your development environment, on the first day you're contributing and you're learning that you can do so without hesitation. You can be confident that whatever you do, GitLab's got your back so you can keep iterating and you can have a much faster cycle time. You can go much faster. That is the advantage we want to bring to the users of GitLab. And we think it aligns this complete DevOps vision, the priorities of development teams. Forrester has done a survey and the four top priorities are to increase the automation, the automation, the automation, thank you, of the software development lifecycle tasks. To use more cloud-based development environments to improve the customer experience and to speed up the release cycle time. We think these are not like different things. We think these fit in a hierarchy. They support the same thing. The hierarchy is in order to improve the customer experience you need to speed up the cycle time. In order to do that, you need to automate more of it. In order to do that, you need a cloud-native application and environment. Let me unpack that a bit. Every company in the world needs to become great delivering a great customer experience. Every company is becoming a software company and if you're not fast enough transitioning to that, a startup will come and offer that better customer experience and disrupt you. And companies get that. We talk to a lot of Fortune 500 companies and they say, look, we need to get better at this and we need to get better fast. And to do that, we need to speed up our release cycle time. Because if you release every quarter, you think that the goal is there. It actually is there, but during the quarter, it moves there. So you're like 90 degrees off of where you want to be. If you release every week, you can iterate and you can figure it out along the way that you were offering your initial estimation and you can track it as it moves. So that's great, but in order to release every day or every week, you need to automate the whole software development life cycle so that you can't spend a lot of time releasing a new version if you have to do it so frequently. And in order to do that, you need to go cloud native. It used to be a world where we had bare metal servers or virtual machines that we changed in place, kind of like pets. But we need to go to a world where it's fungible. You no longer care about each particular machine. It should be a number and it should be fungible. As you have a new update, you throw the old ones away and you install new ones. So these four things fit together and GitLab can help with every single step. So to improve the customer experience, we're adding more monitoring to GitLab. To improve the cycle time, it's great that GitLab is an integrated solution. So you can go through the loop faster and you can get feedback about where to speed up. To automate the software development lifecycle, all these transitions in GitLab they come integrated out of the box. There's no automation for you to add. GitLab knows what you're doing. It has that automation already. And for GitLab going cloud native, we're really big on Kubernetes. And we're going to make sure our packaging release our configuration and our monitoring are great on Kubernetes. So that's what we want to do. Those all roll up together and combine. They make sure that GitLab with complete DevOps can help our users deliver the best customer experience. So the Unix hacker in me is thinking, one big monolithic integrated thing, I thought small individual tools that are composable and do one thing well is the way to go. I thought the same. You thought the same? I thought the same. And so did Dimitri, our CTO. Let me tell you how GitLab CI originated. We made the beginnings of GitLab CI and Dimitri made it because he never wanted to upgrade the Jenkins server again in his life because it was so painful to make all the plugins work together. So he said what he said when he made GitLab, I'll make it myself. And he created GitLab CI but we made a runner, the built agent on the slave servers that agent was written in Ruby and it was really hard to install and it was not concurrent. So someone, a guy from Poland contributed that and we figured out it was way better and we made that the official runner and we ended up hiring him. His name is Camille and he's now leading our CI team. Wow. And Camille came to Dimitri and said look, we're maintaining two projects. It's duplicate work. We should integrate them together. So he made a pitch and Dimitri said exactly what you're saying now. Dimitri said we need sharp tools and he couldn't, Camille kept saying it and Dimitri learned it and Dimitri went to me, I said the same thing and we ended up integrating it and it was so much better and it had advantages beyond what we thought there would be and we're really, really happy with how we saw these like emergent benefits where you integrate two products together. So it was that change of heart that helped you feel good and have confidence in what you're pitching today in terms of your new plan? Yeah, exactly. We figured out that it was greater than the sum of the parts. It wasn't just GitLab, it was GitLab CI's too. It was like five. It made the whole experience so much better. So we doubled down on that integrated vision and I called it our secret and it's like a Peter Teal secret. It's not that we keep it a secret, we're telling you, we're telling the audience, no need, a good secret is something you tell everyone in the industry and nobody believes you and that's what's happening. Nobody believes an integrated product is better, a complete product is better but we know it because we experience that with GitLab CI and with GitLab CD and with the integrated monitoring and with the integrated container registry and with the integrated review apps so we know we're on the right track. Another important point to make there is that it came from a contributor. Being so contributor based as a company, as a culture and I kind of go back to some of the points we talked about earlier but that came from, not Dimitri, he started it, sure but Camille was a contributor, contributed this, offered the idea and now he's an employee and managing CI. That's a story in itself. That's awesome. Yeah, that is indeed the case. And that's the best ideas. The best ideas is not something you can come up with. That's obvious but things that evolve. We never set out to be a remote only company. It evolved along the way. Is Camille an isolated incident or are you hired many people after a contributor? We hired a lot. I think the whole, I think now top 20 of contributors is all working at GitLab. Well that means there's still 1780 plus out there. We got a few more highest to make. But you're not hiring, right? We're hiring and not only developers to complete this vision but also in all other departments. Okay. So you showed us the vision. What's the actual product features? What's it going to look like to get that vision to come to life? Yeah, so I'm very excited to show you more of what we're doing and some of these features are already available in GitLab right now. They'll have the appropriate logos but most of them are still planned. It's still something we're going to do in the future. In the first phase of the DevOps life cycle, the planned phase, I'm really excited we're going to add real-time editing to the description of issues. So what that means is that we used to have like an issue and then we kind of had a life meeting about it. We went to a Google Doc and then we pasted the contents of the Google Doc back in or we left a link in it. It's messy. Sounds painful. It is painful. So why not make the issue the Google Doc? So we're going to make sure that a description is real-time so you can keep updating it. As comments are left, we want to make sure that the description describes what you're doing right now and it's a continuous evolving thing. So my only question on this one is how soon can this feature ship because folks are going to absolutely love it and I'm hoping it's like step one. Yep. Every feature has a link below it. There's the issue so you can chime in but you can also help contribute. If you contribute, it ships sooner but you can also follow along and subscribe to the issue and see what milestone it's planned for. And for those tuning in, these links down here Sid just mentioned we're going to PDF this presentation afterwards. You'll be able to click them so don't forget to read that your own. Hunt it down. We'll have links for you there on. Super excited. Super excited. 4.99. 4.99. That's right. All right, let's see what's next. I wanted to highlight. We already got issue boards in GitLab. It's a replacement for things like Trello and it's getting a lot of traction. People are really happy with it. Now one thing we're going to add is portfolio management. So we're going to have epics and epics can contain other epics and issues and it's a way kind of to build a hierarchy of what you're going to do. So you can plan at a higher level. And there's also going to come with Rope Maps so you can have a planning for your company. So these look like Gantt charts. Yeah, Gantt charts. I mean, that's kind of a bad word, right? To some degree. That's why we're calling them Rope Maps. And we sold it. But you know, I've been in a situation before where you had developers and you had the business, the business side of things. They wanted Gantt charts. They wanted to know where we were going, when we would get there. And our tools just didn't integrate. We couldn't provide them that. We wanted to because we wanted to keep them informed and now we're able to. Yeah, and what we've seen at a lot of enterprise companies, they need that top-down visibility to know where they're going. And they have different tools. So they have like Rally or Version 1 and then they have like JIRA and then they have like Trello boards. They have a lot of work to integrate between all of those. One place to another to another. Yeah, and then the project managers end up having an Excel spreadsheet where they keep another administration. So some people are using like four different tools, but it's the same planning. So you end up like repeating yourself. So this, you can opt not to use it. That's fine. We're not going to force you to have Gantt charts. But for the people that need it, it allows them to keep their planning process dry and to have it always up to date. Yeah, that's important. Now in the create stage, we have some really exciting things. We got a multi-file editor. It used to be that if you committed from the web interface, you could only modify one file and make a commit from that. We're going to ship with the editor from VS Code. It's called the Monaco editor. And it's going to allow you to open multiple files to have all the features you used to in an editor and then commit those together. And actually it's already in GitLab. There's such a bad quality right now that it's behind the cookie wall. So you cannot use it yet. We're going to try to get it to alpha and either 10.1, 10.2. And it's setting the stage for the next step. And the next step is a web IDE. So we want to make sure in GitLab, you have that editor. You already have a web terminal. We're going to add a preview screen. So no matter where you are, no matter whether you're on a Chromebook, you can open up an editor and start coding. So last year when we talked, it was about integrating into existing developer environments, whether it's Vim or Sublime Text or what have you, Adam VS Code, I could go on, and other actual IDEs. Those are more just editors. This seems like a change of pace where you're saying, okay, we're not going to go that route anymore. We're going to do a web IDE. What changed your mind about that decision? Yeah, the problem is it's really hard to support multiple platforms. So when we saw VS Code and the quality of it, we were convinced we had to jump on that. So we think this is a great first step. And we also, we don't have the illusion that everyone will use this all the time, but it's great if you're starting out with programming. It's great if you want to contribute to a project but just do a drive by commit, do a one-time thing. It's great when you don't have your regular laptop. You're logged in from somewhere else. So worth pointing out this is not a required usage type of a thing. Anybody who's still, you know, you can pry my terminal from my cold dead hands. Yep, we're not going to force you. Cloud IDEs are a bit of a startup graveyard. Like many people try to monetize that and have an enterprise force it on all their developers, and that doesn't work. So this is a feature we're really excited about, but we don't think we're going to monetize it by having people wallet out and force everyone to use it. It's going to be, it's a convenience thing. You mentioned VS Code. The core of that is going to be inside of here or you're going to reuse code there. VS Code is a cross-platform desktop app. You're talking about a Web IDE. So it looks like this is just missing the shell and maybe we can have our own little GitLab desktop. Yeah, maybe. Maybe someone will make it. We don't have any plans right now. We might do something else. This is what we're planning right now, but yeah, it's all Web technology. So it might end up. Another feature that if you're in love with your terminal, we're going to make sure that you can use your terminal and only your terminal to add a project to GitLab. So you push your code and GitLab automatically creates a project and it kicks off auto DevOps. So it's going to build the project, test it, quality, etc. I think it's going to be neat to have that effect. I really loved the first time I saw Heroku. It was awesome. Just push your code and it gets deployed and we want to have the same flow in GitLab. Worth noting for us nerds out there that we're making use of a flag for Git that I didn't know exists before I saw this slide, which is dash O. You can send options to the server and that's not like a special GitLab version of Git that's just in the Git client. And you're using that to set permissions on that repository. So that's kind of cool. Thanks. And the next phase is the verify phase. We already got GitLab CI that's well received. Now we added code quality in GitLab Enterprise Edition Starter, where you can see what got better about the code, what got worse. And we're going to add something else. It's a license check. So if your organization has certain licenses they can't use, GitLab's going to scan your dependencies and going to notify you if you added a dependency to your project that has a dependency that's not compatible with your licenses. Very cool. Two other things I'm really excited about is performance testing. So you made a code change and it increased or decreased performance. You're going to see that. But also security scanning. So this means automatically running vulnerability analysis against the code base and against the review app. So static application security scanning and dynamic application security scanning out of the box as part of other DevOps without you having to like run 15 tools and set them up some other way. Having them part of the DevOps lifecycle. Awesome. I think what you said before, Jerry, about this was that how everything comes back to the merge request. All of this, anything happening around the processes here we've just gone through, the merge request kind of gets updated every single time. So that's like one canonical source of knowledge of what's happened along the way. I think what we want to do in GitLab is bring it all back. So we want you to go from that epic to that issue, how that merge request, and then see how that merge request affected the code quality you're monitoring, your performance, whether it had to be reverted or not. That should be the central place so that it shouldn't be about a chat channel you hang out in to see whether your code deploys correctly. The automation should take care of that. Sure. Or even having to go to several different places to get this information to kind of goes back to the execs with the Gantt charts, like just having to go somewhere else or having several different tools. It's tedious. It needs to be in one place. The disparate tools would have the information here, information there. You end up grabbing it, put it in an Excel spreadsheet. It's very fatiguing. Copy-pasting things in one spot, which would be awesome. It might be into the weeds a little bit, but you guys have figured out things in terms of what databases you're going to use for security vulnerabilities and how the performance testing would work. Are we still kind of in the planned phase for that? There's an issue link and Dimitri, our CTO, is on this. He's already started. The first thing to implement is something that's very familiar to us. It's Breakman. It's a Ruby gem that detects vulnerabilities in all your other gems. We're going to add more. We're going to add ones for all the different languages there are. Then we're going to add other tools. We're looking at tools like Nessus for dynamic application security scanning. But like usual at GitLab, we're going to take it step by step and iterate. Cool. Now, one other feature we're going to add in the CI space is flaky test detection. We're adding that also because we need it. We're adding, with the wider community, over 1,000 tests every month to GitLab. If you're running 25,000 tests, even if a test fails one in 100 times, it's still going to have an impact on your project. But it's really hard to figure out which tests are failing because you need to see across 100 builds. GitLab's going to keep track of that. You can fix the tests that are the most flaky. Nobody likes flaky tests. I write flaky tests all the time. You can have ours. You can argue that I like them. If I didn't like them, why would I keep writing them? Again, this brings it back to making it easy to see an index of recent tests, their failure rate, if they've failed in the last 24 hours, how many times, or even the last time it failed. Having an index of that to be able to go and triage that and look into issues or just to make your tests better, your suite better, you can go and see the failing test and it's a point of investigation rather than not knowing where they're at. You've got it and saying in the channel, this test failed for me, did it fail for you, et cetera. What time zone are you in? That's the first question you have to ask everybody. As time is always the problem, right? I agree with that. Now, in the packaging stage, we already have a container registry and it's awesome and people use it and it's great. From CI, you can push your container up and then in the CD stage, you can pull it down all without sending a lot of credentials around because GitLab knows who you are and what your permissions are. It's being used a lot, but not everyone is doing containers. GitLab is going to have great support for cloud native, but we're not going to force you. If you're still using Java or other things in a non-cloud native way, we want to make sure you can store your jar files in GitLab. If you're now using sonar type nexus or artif, we want to offer a great alternative to that. Inside GitLab. We're going to start with Java and Maven and build from there, support more languages, JavaScript with NPM, et cetera, to make sure that's well supported in GitLab itself. You don't have to run your own private Ruby gems mirror, et cetera. You can do that in GitLab. In the release features, we already got great support for environments, all the different environments you deploy to. There's a deployment history there, so you can easily redeploy or roll back a change. We're going to extend that. The way to think about it is we already got deploy boards and canary deploys. You can see a change being rolled out on Kubernetes. You can see a canary deploy and a canary deploy is deploying to 1% or 5% of your user base to see if there's anything going wrong, so you're not affecting everyone at the same time. We're going to extend that with incremental rollouts. That means automatically going from a canary deploy to 1% to 5% to 25% to 50% on a timed sequence. You don't have to increase the numbers yourself. It's happening. The great thing is that if it rolls out and there's a problem, we're going to do a rollback. GitLab will detect if there's too many errors and we'll roll back to the previous version. In my experience, not all deploys are created equally. Sometimes it's a really small thing and sometimes it's a big change with sweeping database migrations or schema changes. Making rollbacks very, very difficult. How would it plan to handle those circumstances? If you're doing a canary deploy, then by definition, both versions are able to cope with the new database. So, for example, you're only adding indexes, only adding columns instead of renaming them. At GitLab, we now try to write our code. First we add a new column, we go to the new version, and then only a version later, we kind of drop the old one. Phasing out the chain. Phasing out, so you could do that. Maybe it's not time efficient for you to do that, and there's going to be changes that can be referred to, and there will be a way to tell GitLab that. Probably a way to say, hey, don't canary with this one at all, right? Yeah. This is a one. No canary, please. And we talked about that rollback. So this is, to your point, it's going to be brought back to the merge request. So in the merge request, Adam, you're going to be able to see, hey, the error rate exceeded a certain percentage, we rollback. You've got to have another look at this. I love how the merge request is like that central point, because it's constantly being appended to new information as things happen. It's like a ledger. Yeah, I think. Blockchain. If you put blockchain in there. We're going to do an ICO. You can raise another round. Yeah. Dave, what do you think about an ICO? Blockchain merge request. I think that the hard part is pressing that merge button. That's what's going wrong. Companies have so much code that is like a work in progress, and that's like inventory. You want to get the inventory down, and you get the inventory down, but make it easier to press the merge button. You can do that in two ways. Give more information before you press it, or make it cause less problems, make it less risky after you press it. Or do both. So we're going to, with auto DevOps, we're giving a lot of information up front. You get the review app, you get the co-quality, et cetera. And then this is, after you press it, make sure GitLab has your back. Because if we make it easier to, if we limit the blast radius, the number of users that are affected, for what time they're affected, you're going to have an easier time merging that and decreasing your cycle time. GitLab has your back. Good poll. Poll quote there. I like that. Okay. Let's keep going. GitLab has your back. Another thing we're adding is first class clusters. So we're going to make it very easy to add a Kubernetes cluster to your project or to your group. And you can run those anywhere. You can run them on prem, you can run them on AWS, but we are a big fan of Google Cloud Platform, and they offer a great container engine. So you can spin up a cluster there, and your project's going to be aware that it can run CI there and builds and tests and everything. It's probably worth emphasizing that you're trying to go completely different and recognizing that you're trying to go complete DevOps but not complete hosting as well. So you're not trying to become a host at this point. Yep. We're not going to host your code. We're going to allow you to use Kubernetes. We're not going to try to reinvent Kubernetes. We're not going to try to resell Kubernetes. There's also platforms like Heroku that kind of resell you AWS. We think that's not our business model. We think users want freedom and where they host their code. They want to have direct relationship, direct billing relationship. They want to have the discounts that are available, etc. We don't want to do that for you. You're going to have the freedom to host anywhere, any place. GitLab's just going to make it much easy to adopt Kubernetes. And this is how it looks. After you add a cluster, you're going to even get, like, monitoring on the cluster itself. So you can see from GitLab whether there's a problem there. Another feature that is a bit complex but I think really useful for the enterprise is release trains. What you're seeing at larger companies, they have a code base, and they need to release really frequently. And they want to make sure that whatever they release is tested exactly as it would be after the merge. So in GitLab by default, we test the feature branch. What you could also test is the merge and master. So you're 100% sure all the tests pass on that. The problem is, every time you change master, you'd have to retest everything. Well, that gets out of hand pretty quickly. So what you then do, what people now do is they have, like, a chat channel and they say, well, I've changed one and someone has changed two and changed two, merges in the changes from one and then runs the test. And the third person merges in master and one and two and three and they run the test. And that's now a lot of manual hoopla. And we want to automate that. You just say merge and GitLab and GitLab's going to know you prefer to test the end result and it's going to queue it and it's going to make sure that the right mergers are tested. So it's like a zero configuration queue for your pushes. Exactly. And then they get deployed out when it makes sense. You don't have to think about it. Sounds cool. Another feature is pipeline views. We want to give you more visibility and what's where. So you're going to see, like, this is basically your inventory. All the mergers, all the code changes you have and what environment they're at. So you can see how they progress from stage to stage. Now the penultimate stage is the configuration stage. And we already have in GitLab we have secret variables. So those allow you to set variables to pass on to your containers. And it's super useful. You have credentials on them. You can have them as a developer, as a master and they're used a lot. Now what we're going to add is better support for scaling. Right now, if you want to scale it on Kubernetes, you've got to set environmental variables. We're going to make that easier. Going to allow you to auto-scale with Kubernetes much easier. And then another thing will extend is chat ops. All the things you see here are part of GitLab. And what chat ops does chat ops allow you to kind of talk to GitLab from a chat channel and that allows everyone to stay on the same page about what is happening. And we want to extend that for example you see here a new command back end scale production to 10. So suppose you're not auto-scaling you can scale from that chat channel and we're going to add a lot more operation features to chat ops. So we've arrived at the last stage and that's the monitoring stage. And there's a lot of innovation happening there. We're already shipping GitLab with Prometheus out of the box. And Prometheus detects like your environment it detects your application it can show you how you're doing what's your latency what's your error rate. We're going to extend that with tracing. It's going to be based on the open tracing standard because we believe distributed microservices are the future. So if you offer an application to end users there's going to be lots of different microservices that work together to fulfill a request. But if there's a problem you got to see you want to see a trace amongst all of them. And we think open tracing is a great standard we're going to add support for that inside GitLab so you don't have to leave GitLab to do a trace. Another thing we'll add is auto-alert. So by default GitLab's going to have a sense of what metrics make sense to alert on. And you no longer have to like for every new project you start define the 10 common things you did for the other projects GitLab's going to come with sensible defaults and if they get exceeded you get a warning. Another thing is an ops view so getting more visibility on all your different environments and seeing where there is a problem in the right environment. Another really big thing is auto log. So I think if you have metrics in your application everyone does you also have you don't only have events you also have the log files generated by the application. And as you get more serious about your application you need to aggregate those and search those. And frequently now it's a different application an application that didn't know when you exactly deployed your flow. So we want to integrate that into GitLab so that GitLab tells you exactly what's happening and you can search through your log files. One thing that's already in GitLab is cycle analytics. So cycle analytics shows you exactly how long it takes you to every step of the DevOps lifecycle. And if you want to reduce your cycle time this is the metric you should look at. Where are we getting stuck what's not going fast enough and cycle analytics can tell that because GitLab is one data store we know how you went from the planning phase to the monitoring phase and GitLab can tell you more and it's very exciting we got the first community contribution on cycle analytics. It's a good example of the benefits of integration because you have all of that available. This is only possible in GitLab all the other companies are like if you use multiple products you have to like create your own data warehouse get the data from all those products and then do an analysis on it. With GitLab you get that out of the box. This really makes retrospectives that much more fun because you got a lot more information. Last guessing we're looking at... Hey come on how can we reduce our inventory how can we have less like code in progress. You look here where's it getting stuck. And last but certainly not least this is metrics. So out of the box you want to do a better job of monitoring how your app is doing what's your customer satisfaction what's your conversion rate you want to create a better customer experience you need to get these things right and want to add as much intelligence to GitLab so that out of the box when you have a new application it starts measuring all these things. So that's how we hope and we will make sure that GitLab becomes complete DevOps that's going to help our users deliver a better customer experience. That's a lot of stuff. That is a lot of stuff. I was counting the planned label as you go there and I just lost count. Yeah it's a lot. That's why we think we'll need a year this time. Well tell us more because even in the year I'm seeing all these things here and I'm thinking how the heck these are all businesses individual businesses that that you're essentially pulling into GitLab by itself. Yeah well one thing don't go out alone take this and take this is the wider community. We hope that although we announce the plan we won't be the only ones contributing to it. Right. So all the people viewing you know this is what we intend to do but we can't do it alone so please contribute and help us. One other way in which we're going to do it we're going to use some of the money we just raise to expand our teams we're going to create more teams to work on this where we're hiring and we're going to accelerate our hiring. And then the third thing is our secret weapon it's iteration. Not all of these things will be perfect out of the box. It's not going to hold a candle to Splunk in its first iteration but we're going to iterate on it we're going to leverage open source we're going to probably leverage elastic search and other things to improve it over time and then when it gets to a certain state we see more and more contributions from the wider community coming in. So that's the plan work really hard ourselves first iteration and then work with the wider community to get it there. I asked you about speed I was going to ask you about quality because like Adam said there's entire businesses devoted to many of these even just the security aspect alone is a lot of work and so the question was well can you get it done fast but also can you do as well or good enough to make a compelling offering against some of these companies that are dedicated to it it sounds like iteration is the answer to that. Iteration is the answer it's hard for us because we were kind of doubting ourselves like are we doing good by not only doing version control but also doing CI and we had the feeling we were on the right path but the Forrester survey we showed earlier where they said no not only do you have like a competitive CI offering it's actually best in class so you have all these competitors that have 10 times more paid people working on something only on that than our team GetLabs able to be better and that's because of the way we work and because of the wider community supporting it and that gives us the confidence that we can get to a best in class for each of these of these products. Another aspect to this too is this grand plan yet again to come back to this stage and share with the world what you're going to do for the next year that's enough but then also you know how did you get there, how did you know this is what you needed to build? It's a lot of people contributing to this we got great product people we got shout out to Mark Punsak our head of product who was really influential and like how we thought about this it's also talking with customers like we're doing we're seeing a lot of customer comments in the issue tracker we talk to them we go out we have lunch and learns etc it's our users like each one of these and some of the issue numbers I saw for the real-time editor I saw 4,000 in there we've been talking for a while there's people contributing ideas for example the real-time editor there's different frameworks that are suggested and I think we now found a framework which we're happy with it didn't come out out of nowhere it's about these are the best ideas we're discussing and there's over 10,000 feature proposals at our issue tracker we look at each and every one of them and people chime in and these are the best ideas that we think will help people improve their customer experience you mentioned frameworks there you talked about VS Code Monaco you talked about Prometheus what kind of role do you play not so much just as a user but as open-source projects that you'll now begin to build GitLab on yeah with GitLab we try not to one of our values is boring solutions so when we started in the DevTool space many investors were hesitant to say you can't make any money there because developers just open-source everything instead of having that be something that holds us back we try to leverage it so GitLab builds on other open-source technologies like Git, like Prometheus and by orchestrating that, by combining that by making that one integrated package that's our added value and we try to contribute back we mainly contribute back by releasing GitLab Community Edition but we have a person now Christian who is contributing to Git he's trying to integrate LFS as a core part of Git which should be a plugin it should be a part of Git proper so he's working on that we got a team of people working on Prometheus for GitLab but they also contribute back to Prometheus itself we were part of Ruby together we try to be a good citizen of the wider ecosystem but the core thing is just making sure we open-source as much as we can every month that's the beauty of it they get the recognition of being something that GitLab is using directly which would feel pretty good for me for my open-source project they get patches back on things that make sense and our improvements are bug fixes and then GitLab Community Edition gets better and better because of their tool that's the beauty of open-source all the goodness flows around this might be done a little bit but we have some questions from the Q&A part of this Christian Munich at CM UENCH on Twitter asked a similar kind of question but maybe a little bit deviation from it how will this new funding round impact your open-source activity so not exactly what we're talking about here but in that realm so we plan to keep doing exactly what we were doing so the majority of features will go into the open-source one our complete scope will be part of the open-source edition and you can read more about how we think about it on our stewardship page about gitlab.com slash stewardship and nothing changed there that will stay the same and I think with getting a mat to join our board we ensure that not only on a company level but also on a board level that the voice of open-source and that the added value of a community is well represented and thanks for asking the question it sounds like we're into the Q&A so let's do this let's just go right into the Q&A we've been collecting questions online and the first one is for Barbie so Barbie is going to come back out Barbie welcome back so we've got Carolina Bautista yes, on Plotzi asked to you directly what's the biggest challenge to you growing your team well, I'm going to assume we're talking about the gitlab team but I think the biggest challenge to growing the team is just making sure you get the right people but I'm reading this question as the biggest challenge to growing our team not with growing our team which is slightly different so I think that we need to make sure that we're getting a great diversity of hires a great diversity in our panel that we're interviewing with we're getting people from a wide variety of areas across the world and not staying focused in just one center of the world so I think that those are what I'll be very focused on in building the team as well as I think at Gitlab I can expand a little further my priorities in growing the team are to look at the way we do performance management and reviews the way we do compensation and again our inclusiveness and diversity at the company excellent we'll move down the list here maybe we should reiterate are we still taking questions? I believe we are you can still submit your questions on Platzi or with the hashtag come Facebook, on Twitter get them out there we have a lot of great questions here but we will continue to take them as they come in up next we have anonymous this is the hacking organization correct? is there an organization's existing extensive CI CD tools someone's got their cursor on it that might be somewhat disjointed yeah we're seeing that people are using GitLab CI to consolidate the tools they had in place so where they had multiple tools before with GitLab they can consolidate GitLab CI has the flexibility for developers to self-serve while still having the advanced features like cross-project pipelines that were previously only available to the build teams many times CI needs to do a lot of things it needs to auto-scale on the cloud to have enough capacity but you also need specific machine instances like OSX ARM architectures the same machine every time for the performance build GitLab CI allows for all of that so you should be able to consolidate on GitLab CI and many many organizations are doing so and they're saving a lot of time and money that they spent before on orchestrating all of this you want to take this next one? trying to choose which one might be best to go for next if we keep going down the route of maybe CI there was one down here for that let's take this one instead from Rebecca on the I was kind of curious about this as well your Gitter acquisition at the beginning of this year was big news could you tell us about what we could expect from GitLab plus Gitter in this next year yeah so we acquired Gitter and first of all the teams got a great job of like keeping that running they also have other responsibilities at GitLab which they're helping with the source code at the deadline we promised that was I think the summer and the next step is to have better GitLab support in Gitter I call dibs on this one because it's potentially controversial are you ready? not really you'll be just fine not anonymous David Peters don't say sorry David Peters we're an hour in a while to see says is this a tech event or an enterprise pat on the back event it's whatever you make of it I think a bit both look on one hand this is our strategy going forward on the other hand we also we have to do a better job explaining to enterprises why GitLab is a good option and I think we did a good job with the wider community creating a great product but if we're not able to articulate that we should switch we don't have a sustainable business model so we've made great inroads with the enterprise and if you're seeing a lot of enterprise content in this presentation and a lot of us articulating why GitLab is great for the enterprise that's intentional and we'll continue to do that but it won't come at the cost of keep us shipping great features every month on the 22nd Vincent on Facebook audio cut out do we still have Matt as Matt gone Matt is gone right we do have Matt so I guess your audio cut out earlier and Vincent on Facebook wants you to reshare why you decided to join GitLab's board oh earlier what I said I don't remember exactly what I said so maybe watch the video but just that as a company GitLab's very excited to me because I believe that distributed work is the future of work and GitLab's actually taking some of these things even further from automatic and I think automatic being a little bit ahead in terms of people and also GitLab being a bit ahead in terms of transparency and a few other approaches we have a lot to learn from each other and the second is I believe the integrated approach that GitLab takes to CI, deployment, everything is the future of development and so being both the combination intersection of future of work and future of development is pretty exciting and I'm excited to be involved thank you Matt no problem next up an anonymous user at the handle SF make of that which you will ask it's a super fan of GitLab of course will GitLab do something similar to what Facebook did with PHP hack and parentheses to make it faster and more reliable right now we don't have anything there Shopify is doing a great job they released a gem to reduce boot times and we implemented that so we're a consumer not a creator of those things with GitLab when we find performance sensitive things we tend to rewrite them and go so right now our major effort on the way is Gitly and it makes sure that our file servers are not just serving the files but they can actually they become Git servers they serve Git calls with the appropriate monitoring and that's mainly written in Go so that's the direction we're taking we appreciate all the efforts on the way Ruby 3 3 times faster we hope it will make GitLab 3 times faster but we don't we're not working on that as a company the next question is from Mason Chase on Facebook asking is there a plan for a web UI merge tool also says we could always use a more powerful merge tool built into GitLab so given the multi file editor your new web IDE what's the plan there for a merge tool yeah I think GitLab was the first one that had a merge conflict resolution tool in GitLab and I think that's being improved continuously we keep iterating on that I think by now it's pretty good sorry if there's anything more you'd like to see feature proposal if there isn't one already here's a good one from Rebecca because it has to do with the integration side and just when you integrate there's only one thing so she says isn't it risky to put all your eggs in one basket as in if GitLab was down and you use it for everything then you're stuck yeah I look we're doing a really good job of making sure that GitLab if you run your own installation with tens of thousands of users it's very stable coming out with GitLab Geo GitLab disaster recovery, GitLab HA so I think we can keep GitLab out I think one thing one point of confusion is when people say look GitLab offers all these things I don't want to give up my old tools so we want to make sure that GitLab has best in class support for Slack for JIRA for Jenkins you don't have to give up all these tools when you move to GitLab we want to support them and we're doing a really good job and we want our JIRA support to be better than in Atlassian's products themselves so we want to make sure that we have everything in GitLab doesn't mean we expect you to throw everything you have right now away we want to convince you to use GitLab we don't want to force you let's take this one from I believe it's Roliver 4 or Roliver 4 on Plattey on implementing user slash customer approvals for issues I also mentioned somebody moved it on me it's up there some public companies require approvals and sign-offs from users and managers so you got that? I think what we already have in GitLab Enterprise Edition is multiple approvers so if you have a merge request you can specify who should be an approver for that you can have fixed people you can have a group of people that has to get to the core so there's really advanced functionality in there already and you can add if customers have a GitLab account you can add them to it so I'd say check that out Matthias Wiesen M. Wiesen on Plattey asks will GitLab integrate with Kubernetes slash Docker security scanning slash compliance question mark such as twist lock yeah I think where we're going it's to add those things to GitLab itself GitLab has a container registry you're running your building GitLab we want to make the security scan part of other DevOps so it should run by default and we're looking at all the different tools that are available like Clare from CoreOS I want to take the best tools and make sure they run by default in GitLab so that's our strategy there knows knows big? maybe it is knows big I'm not sure it's NOS BIG which is pretty close to knows big on Plattey says will there be tighter awareness of integration with Antibole with GitLab perhaps in CI CD yeah I think there's already Ansible scripts to like deploy GitLab and with GitLab CI you're flexible so if you want to call on Ansible scripts to do the heavy lifting that works for deployment itself I think we're what we support by default in GitLab it's going to go more and more container to the container to go cloud native to use containers and environmental variables and technologies like console and Volt to do the configuration and I think that's where the configuration story of GitLab is going so we have another anonymous Plattey user this question was asked during the section about first class clusters and you might have to imply or infer some of the context so he says what about other cluster types so we're going to have great support for Kubernetes and it means that we also support OpenShift because that's mainly based on Kubernetes now there's also Docker there's Mesosphere there's a lot of other technologies out there we think Kubernetes is winning and we think that the other vendors will start adopting Kubernetes if they haven't already like Mesosphere announcing support for Kubernetes so we're all in Kubernetes and for now we don't have any plans to add a lot of support however it's open source if you contribute it and if it's good we'll merge it I'm Matthias Weissen again and Weissen on Plattey asks are there plans to have built-in monitoring via Prometheus to analyze APR requests and or underlying code to identify bottlenecks in code yeah for sure so we want to make sure that the built-in Prometheus is flexible and you can add your own metrics if your API server is a separate microservice it will automatically show you the request rate and things like that so that's definitely things that should be in good lab let me get that to you this next one sounds like a plant I don't know I might have came from the inside because it seemed like a softball so Heroshi question on Plattey how do I join the GitLab team well I'm glad you asked I think that the best thing to do is to run NotWalk to about gitlab.com and click on our jobs and see what they're interested in and then please do apply and our team will get back to you very quickly on next step once you do so any tangible steps well I would say that I would recommend and this is just a general recommendation in life before you apply take a look at our handbook online, take a look at our values online make sure this is actually the right fit for you I do believe that the value of transparency around our culture and our values is such that you can also self-select in or out if our values don't align with yours but I do hope that for the majority of the population they do align and educate yourself on what GitLab is doing and what it's like to work at GitLab and then if it's still interesting then certainly do apply but through the process you will get there but I think it's great to be proactive in doing that research Good answer Next up is Linus Lewandowski on YouTube asking have you considered going multi-platform for complete DevOps making the apps deployed on Kubernetes but also AWS EC2 cloud instances, OpenStack etc Yeah we looked into that we think that in order to automate the software development life cycle you need to go cloud native and we think cloud native means a container scheduler and we think Kubernetes is the winning container scheduler and then so we want to focus our efforts there lots of people use GitLab to deploy to virtual machines on AWS and all the other platforms and that's not going to go away that's going to be a great experience too but many of these advanced features like the incremental rollouts it's much much easier with a container scheduler you can tell Kubernetes like I want to do a canary for this and therefore we're using those platforms so we don't have to invent it we can just leverage what's already great and what people already are building and testing This question comes from D Stalder on Platzi, are there any hooks planned for other performance monitors that aren't Prometheus? We already have a corporate deploy of New Relic Yeah, the GitLab works fine if you just add your New Relic agent in there and you set your environmental variables with the New Relic credentials that will work fine so many people are using New Relic and things like that and all these things are things that happen automatically on top but if you want to use your existing tools that's totally possible and it works the same way as it would with any other tool So it's a perfect recipe like any framework but you can swap out whatever you want if you decide to use something different Yeah, I think it's I used to be a Rails developer and it comes with sensible defaults and if you follow the happy path with GitLab you should have to care only about your application and programming that and not about all your tools but if you want to customize you should be able to customize if you want to take all the DevOps scripts, you want to customize them it's right there it's just another helm chart everything is customizable we don't want to fix you in you have to do it the GitLab way no, we're going to make it super easy to start off the GitLab way but as you graduate beyond that we want to make sure you can get in GitLab and as a developer I've used the Roku but it was frustrating that when I graduated beyond I needed functionality that wasn't in there I needed to move away and want people to stay at GitLab and run the most complex apps on it Perhaps as a follow-up and to clarify for me so I don't understand that correctly say that GitLab builds tools on top of what Prometheus is monitoring and so they sit up here and then somebody wants to come and use New Relic instead of Prometheus or some other tool to run by those types of analytics or monitoring are they then opting out of all of the cool stuff that you're building over here or are they plugging into that and you will sit on top of it and continue to work just fine if that happens you're opt out of the building monitoring in GitLab if you want to use New Relic instead of Prometheus and GitLab look if someone contributes New Relic support great if it meets the definition of done we'll merge it but for now the monitoring part assumes Prometheus and Prometheus is great technology it's made for cloud native it's made for microservices and we're able to ship it as a part of GitLab so that's where it's really important that out of the box when you download the GitLab the omnibus package we can keep that experience and we can do that with proprietary tools next question is guest on Platzi asked how is GitLab and I'm not really sure I understand the full spectrum of this question but I think I get it but how is GitLab planning to use the wide source of tools is it going to be plugins which are available as a plugin and play model is that talking about model with architecture kind of thing I think so so many other well, our competitors so GitHub is building a marketplace where people can extend their SaaS offering Atlassian offers you to add plugins we believe that as an open source offering we have a unique opportunity to do neither of those but to have people contribute to GitLab itself so the reason that there's over a thousand tests being added to GitLab every month is because there's a lot of functionality being added to GitLab that otherwise would be in a plugin and a plugin sounds great until you have to upgrade with 10 different activated plugins because those plugins are not going to be tested so now you're the first one to have to upgrade this combination of plugins and you're going to run into problems we don't want you to run into problems we want you to upgrade your GitLab server every month not necessarily on the 22nd but at least that month it needs to be rock solid and we can only do that if we test and we can only do that if those tests are part of the core platform so with GitLab we encourage you to add code as a project service instead of as a plugin so this question might be for Matt and it might be more directly than I asked him earlier on from Bam Bam Boole what's up Bam Bam Boole when will WordPress just switch to GitLab with its source code just to get out there and straight ask it we should hire a dispersing of sales you'll see an application later it says Bam Bam Boole on it what do you think Matt to go geeking on WordPress for a second this year it's really all about Gutenberg and so we've explicitly put a stop on any other non Gutenberg, non REST API non CLI and non customization stuff so we said those are the four focuses for the year and what we're going to do now is including tooling is off the table so it's not something that will happen nothing at all will happen in 2017 but especially assuming Gutenberg goes well it's definitely an area we want to look at improving in the future we're seeing some other open source projects switching so GNOME is now in the process of switching to GitLab so we're really excited to work with them and add the features they need in the open source edition we have some major news coming out in probably next week about another major open source project which we're making changes to accommodate them next up is SS Robbins asked on Platzi is there a plan for Windows Mac iOS and Android build environments yes and the plan is it's available right now so if you need to record on any of those platforms that's possible thanks to Camille we mentioned him earlier so we had some Ruby installation that required a lot of things and he made a GoRunner and the GoRunner is really simple it compiles on all kinds of platforms I think there's now S390 support if you know what that is there's loads of platforms on which it runs so you don't need to run GitLab on that platform and it has support for every environment where Go builds which is a lot by these days so you can people are running it on Mac OS X to test their iPhone builds on ARM to create packages for the Raspberry Pi so it should run today on every platform that they're likely to need this next comment comes in from a GitLaber who's on Hacker News apparently there's a conversation going on there about the compensation calculator being below market in terms of working for GitLab so I have my opinion I'll let Barbie chime in too I think what we're doing as a company we're transparent about the salaries we offer and how they change where you are across the world so if you're in San Francisco you're going to get paid more than we think that's fair because your costs are going to be different as well there are people that say you need the same pay and we disagree with that we think if we do that we'll end up somewhere between the salary between San Francisco and Italy and we'll never be able to hire someone in San Francisco and we want a diverse company that includes people that are living in very expensive areas and need to be compensated for that what do you think Barbie? Well I think that compensation is one of the challenging things about being a distributed company and the reality is that when you look at compensation you are also looking at what the market rates are and the reality is that those markets are different across the world however I will say that I don't disagree that the compensation calculator deserves being looked at and we are currently putting a lot of effort into doing so that's one of the first projects and here at GitLab and Brittany on my team and Ernst on the team and myself are all very focused on this as I said and we will do our best to make sure what we have is correct and if it's not fix that but I don't think we'll ever get to a point where it should be a situation where someone in a very low cost standard of living area and a much more affordable area would have the exact same compensation as somewhere in San Francisco where a more high cost area to live so I think that it can look strange on paper but when you actually look at it in a practical way it makes sense that we are trying to do our best to serve people where they are instead of centering all around one location since that's not what our employees are doing How do you even determine market rates maybe I'm asking out some ignorance there but like what goes into it and how do you decide even for a specific market like say Houston what is the market rate there to use in those calculators It's very challenging we currently use RIT indexes to try to give us an idea of what the cost of living is in different areas looking at market there was a broader question and there's obviously comp surveys out there and people you can talk to but they vary widely and what one person considers the skill and market of a senior software engineer varies across companies so what I find the best way to do is to talk to companies about what they're seeing on the market and what they're experiencing we could have a long conversation about this around the way the tide is going in the U.S. at least in terms of actually talking openly about compensation and there's certainly some states you want to stop that open conversation but I think it's a valuable open conversation it's how you can gut check whether or not you're getting it right and so I think it's using some comp surveys it's using RIT indexes and it's talking to people in market to really try to make sure you're getting to the right comparisons and the right numbers this is a very complicated subject to dive into I'm sure and very close to the heart because that's where you sustain your family on so everybody's going to be very on edge about it moving in a completely different direction with a spicy onion as a matter of fact spicy onion on klotsey that's an awesome username I love that direct ask can we have a single project board that can be used across all repos so a project board of all probably spicy onion thanks for the question I'm interpreting it as an issue board that can be used across multiple projects and we release that with GitLab 10 and it's available but only in our enterprise edition and they're called group level issue boards and I hope that was your question here's a follow up that I often think about when we see open core situations there's a fine line to walk between what goes into core or community edition and what people need to pay for do you have a rule of thumb about how you decide this is going to be something that everybody gets for free or this is going to be a paywall one of the hardest things we do is determining which feature goes and what version and we don't always get it right for example last Christmas we decided to open source GitLab pages because we put it in the enterprise edition but it didn't belong there the rules we used are specified on our stewardship page and the idea is that a few things we always want to be in open source the open source will always have a current version of the user interface and we always have everything that's in our scope so all the phases of the complete DevOps life cycle now how we determine if something should be proprietary is that if we think you're more likely to use it if you work at an organization more than 100 people and the hard part about this is more likely because obviously every feature that someone that even using GitLab with one or two people wants as well so there's no features that nobody wants to see in the open source version but we try to find features that you're more likely to use the bigger your organization is and it's hard to get that exactly right and we we try every time we listen to the feedback on our blog and try to where necessary but we'll never get to a stage where everyone is happy and we'll never get to a stage where everything is open source we want to build a sustainable company at the same time but it's one of the hardest parts and we appreciate all the feedback we always get next question is one of the hardest to pronounce thanks for giving me this one Adam you Nuber I don't know for a whole app but I do more plugins is there some hint about how to do that with GitLab so developing plugins with GitLab I think I'm not sure exactly what kind of plugins for what thing you do that but I think if you develop just plugins it's probably attractive to get a container of the application specify that as your container image and then run the plugin together with the rest of the application to test your functionality and look into something like that next up is I believe Rufinus do you see it like that Rufinus Rufio Rufio this is a bit of a distorted question towards the end here there's a lot of some comments here afterwards but why are so many great features only in EEP and then it goes on to say as EES user it's really sad Geo is EEP okay but service does question mark cross fork MR so it's kind of hopefully your cat knows back to where you're talking about I get the question how do you decide which goes into where basically that's hard and thanks for asking so what he's asking about we have enterprise edition standard and enterprise edition premium and some people are on enterprise edition standard and we say that's a great offering if you're not at a super large organization that some of the features these user ones like service desk offering would also be interesting to them and now they can't use it they'll have to pay more for our enterprise edition premium version it comes back to like there's no feature that nobody wants if they're in a small organization and I can see how you want to use service desk service desk for people that don't know it means you can send an email and then in GitLab creates an issue think of it as like an open source send desk and that's a great feature we think the larger your organization the more likely you are to have like a support queue where multiple people work together to do it in which case issues is a great solution if there's only one person you tend to like route the issue emails just through their inbox but it doesn't mean that if you're in a small organization it's not useful it just means we think it's a feature that you're more likely to use if you are at a larger organization and that's why we decided to put it in enterprise edition premium very good, next up, P-Fetagon on Platzi are there any plans to integrate with service now? we're looking at that a lot of questions from people that want to integrate with other tools we talked today about our portfolio management strategy some of functionality is coming to GitLab but we realize if you're using service now today you're not going to throw that away when you implement GitLab so we're looking at a better integration I can't promise anything right here I encourage you to comment on the issue I'm sure there's an issue already for integrating with service now if you want to work around if you want to do it today I know there's a commercial vendor called Taskstop that has that integration but that's a paid product I think you made a good point there that there's an issue or likely an issue behind the scenes there's some sort of conversation happening around these things so find the issues, search issues or in a Q&A ask you directly and it's behind the scenes of this webcast what our product managers are thinking what our salespeople are thinking you can correct their thinking Anybody in GitLab is available through issues basically everybody has access to participate and communicate and share their knowledge Brett DH on plots he asked so if I want to use a third party code review tool such as review board or fabricator with GitLab is that supported today is it Sunday I also asked more generically is it GitLab's goal to allow customization of any part of the complete DevOps cycle while starting with batteries included Thanks for those questions review board added support for GitLab a while ago I think more than two years ago so you can totally use that fabricator I think it's more of an alternative for GitLab so I'm not sure how that will work it is very much our goal to allow customization so if you look at other DevOps today the secret is it's just an other GitLab CIDL demo script executing a bunch of Helm charts so you can take that script you can add it to your repository and you can make edits in it actually we put some stuff in that script that you might want to comment in we comment it out canary deploys because not everyone needs a canary deploy however if you take that script add it to your repo and take out the comments and make it from commented out to live code you now have that so yes we want to make it very easy for you to graduate and be in control of how that life cycle looks and for what you use GitLab and for what you use something else Very good, de-stalled or unplanned any plans for adding in the new features that come up into the GitLab.rb I might have to explain that for the rest of us currently we have to hunt down the new features and add them yep so now my knowledge is not perfect as well I think GitLab.rb is our file that we ship where you customize the omnibus installation it could also be that GitLab.yaml is the one where you customize the omnibus installation so I don't know how exactly to talk about it I think our goal is to have all the features that you can customize in GitLab in the omnibus installation I think if you're using GitLab from source it's harder to customize and you might have to contribute that we recommend switching to the omnibus installation but thanks for contributing the features so far and I'm sorry we don't help with that use case and we're dependent on you contributing those the next one tried to be a tongue twister welcome to 9633 that's their phone number I was thinking that two numbers off from a phone number regarding tracing are you planning to leverage existing projects for example Jager from Uber which is open trace compatible or build STH your own well thanks very much where Jager if you haven't seen it Jager is Uber's implementation of open tracing and it's looking really really nice we're not committing to it today if you look at that issue that was linked you'll see that I commented on the open tracing issue at the GitLab issue tracker saying that we should definitely look into Jager so thanks for mentioning that it's on our radar we'd love to have people comment on that issue that are actually using it this next question is an interesting one I know we joked earlier I'm not sure if it was on the live call or not about ICO anyway I think it probably was but it does make some sense in terms of allowing open investment, open company community, all that stuff so the question is are there plans to allow open investment into GitLab thanks well thanks for being I assume interested in investing in GitLab unless you're planning to short us in that case, no thanks we looked into that one of our values is boring solutions and one of our goals is to IPO in 2020 and of the companies that IPO very few of them have done crowdfunding that's also because crowdfunding is relatively recent but it's also because in my perspective crowdfunding can be a distraction we have fiduciary duty towards our investors we give them more information than is out there in public there's also financial metrics that are confidential and if you do a crowdfunding you're no longer you kind of have to find like halfway between that you've got to share a bit more than you do to the general public but probably a bit less than we now do to our investors because it's a much wider group we think that's a very difficult tradeoff to make so we don't have any plans to do crowdfunding and the ICO meant that as a we like ICOs but we don't think that GitLab is a blockchain native company that's a bummer I was going to invest this might be a good one to end on because this is our last question unless we get some more after this and I don't think so but this is going to be our last one PFET again this is a great one what CEOs do you look up to meaning who inspires you who do you seek knowledge from who's your mentor well one very easy one Matt that joined our board is someone I look up to Matt you're going to get on screen I think Matt's already helped us in our board meetings we're expanding internationally we're incorporating in Germany and he and his team helped us with that he also is able to articulate the value of open source and how you scale remote only to the other board members and that's very very important as we scale and this is something unfamiliar to some of the board members other CEOs I look up to are Elon Musk for when he had multiple companies and when they started failing if one he tried to save them all and put all his money all his network on the line for that I think that's really inspiring I like what Jeff Bezos is doing what Amazon did entering into new markets is amazing and he says about that we're willing to be misunderstood for a long time and we get lab into new markets but hopefully we're not going to be misunderstood for such a long time but that they do it for such a long time and they keep it up year over year building completely different businesses besides each other and then scaling the company and making sure that the fact that the organization is growing doesn't mean like that the complexity grows exponentially I think that's very very inspiring I guess we'll leave it there this has been a lot of fun is where to close this thing everybody thank you audience for tuning in to this I guess roughly almost two hours almost two hours so if you've been here all two two hours thank you so much if you shared questions thank you so much thank you to Matt thank you to Dave, thank you to Barbie, thank you to Sid and the rest of the team behind this Plotzy for making this all possible obviously my co-host Jared can't do without your brother and we're done thank you very much get the slides read the recap at about.gitlab.com and we'll see you next time next year