 Hey, everyone, this is Alan Schimmel of DevOps.com. And welcome to another DevOps.com webinar. Just a little audio problem here. OK, hopefully we've got that rectified. I apologize. OK, everyone, today's webinar is sponsored by GitLab. And it's top five takeaways from their 2018 Developer Survey. Before we get started, though, let me just quickly go over a couple of ground rules here on how we're going to run today's webinar. We really would like to see questions from our audience. I know many of you are just logging on. And we have a special section of our Go to Webinar Control panel set aside for questions. If you look, for many of you, it'll be in the top right-hand corner of your screen. You'll see a section of our questions if you click the arrow, so it's down pointing. You can put your question right in there. You can type it in. We see someone's already typed in ready. The nice thing about putting your question in here, folks, is it's automatically queued, so we have a record of it. We'll be able to get to it. You don't have to worry about forgetting it. And if you have multiple questions to ask, you can put them all in here rather than trying to remember three or four questions. So question section is for questions. If you're having any technical difficulties, perhaps the audio isn't working well or the slides aren't progressing. We do have engineers standing by to help you. We ask that you use the chat section, which is at the bottom of your Go to Webinar Control panel. Again, click the arrow downward facing, it expands. And you see you can type in your message there. And as I said, if you're having any technical difficulties, that's the place to go. If our organizers, our engineers see it, we'll try to help you out to make sure you get the full webinar experience. OK, that being said, though, let us get going with what I hope is going to be a great webinar today. Our first, as I mentioned, it's sponsored by GitLab. And this is based on a 2018 Developer Survey they did. And I am happy to be joined by my friend Ashish Kuthialla, a director of product marketing at GitLab. Ashish, welcome. Thank you very much, Alan. Excited to be here. Absolutely. So Ashish, before we get dive into this survey, a little background, if you can. When was the? So GitLab has been doing an annual survey every year with developers. And the objective of this survey is to find out what's really keeping developers motivated, what's working for them, what's not working for them, are the perceptions and the findings similar to and compared with their management, are there disconnects, or which organizations are functioning well and not functioning well to get to the root cause of this. And then to share this with everybody. We have a lot of developers using our products that love reading what comes out. And for this particular survey, now we ran about a month's worth of data collection and more than 5,000 people contributed. So it's a well-read survey and therefore everybody wants to participate in this. And the good thing is that we were able to attract not just the typical male coders, but actually good diverse section. Yeah, 25% female is outstanding in an audience that's probably only 15% women, unfortunately. Absolutely, we were very happy with that. But we're getting there and that's good, good for you guys. And so if you wanna look at where did everybody reply from, it's from all over the globe, right? So of course there's a majority in Europe and the North American continent, but pretty good representation from other parts of the globe. And the demographics, if you look at the different services, they were also well distributed, like people doing IT and education and business services, telecommunications, retail, you see a good mix. And so we can start to talk about it. This is the next slide, but yeah. So I love that it is so diverse, frankly, as she should. Interesting though, eating your own dog food, right? We find that the tech SaaS industry really consumes so much when we're talking, because we see it at devops.com too. Our demographics are not that different from that world map that you put up there. We probably have a little bit more in India than you do, but otherwise it's similar. And we also see that technology companies are one of the biggest demographics followed by financial industries, healthcare, stuff like that. So we're looking here at a perception gap, right? The transformational promise of devops. And again, this is something we've done surveys with too, Ashish, because for too long, I started devops.com four and a half years ago. I remember. And for too long, it was more of a gut feeling that this devops thing has to work well. It's got to save us money. It's got to be a good thing, but we really didn't have metrics to show that until relatively recently. So I'd love to hear what your interpretation of this is here. So I think if you look at it, companies tend to look at devops as the next, transformational methodology that's gonna solve all software delivery problems. And of course, there's a lot of truth in that when done really well. What we're finding out is, when you actually go and start with these organizations, managers and management layer seem to have a more optimistic view of where they are with the progress with it and what they can do with it. And developers, though they are very, they find the promise in it, they tend to agree less with the optimism of the management. And from our perspective, that makes a lot of sense because it's the developers who are in the trenches tooling, retooling, trying to configure, making that CD pipeline work, always kind of running into different roadblocks and trying to solve that all the time. So, though they're excited, I think they're not necessarily like, all rosy about it as management thinks it. So let me just take a contrarian view on that. Tell me what you think, Ashish. Could it be, and I'm not saying it is, but could it be that the developers are kind of lost in the trees and not seeing the forest in that they are so consumed with their day-to-day tasks, their piece of the pie, their piece of the puzzle, but that's all they see and they see those problems with their little piece of the puzzle. And so they don't take that larger view that sometimes a manager might have, right, of the entire project, of the entire thing. And so perhaps that explains why they're, let's say, a little less optimistic, not pessimistic, but a little less optimistic. A little less optimistic. Then the managers are, because the managers maybe have that larger, bigger view. And I think it's, I would agree with that. I would also say that the developers are dealing with massively incremental changes that they have to fix and make. It's their universe. They may not see the overall progress, like you say. But even at the management layer, I think, they do seem to see the progress is being made. If something used to take six months, you're maybe down to five and a half months. But the developers, I think, being the innovators they are, they want their code to do magic. Better faster, cheaper. They want to get there faster, right? I mean, this is our observation again, but the stitching together of the tools, getting them to work right, different technologies, they spend a lot of time doing that. They love doing it, but it takes them away from their core of developing the software that'll deliver value to the business or deliver more revenue. Absolutely. I think there's some frustration there. There is. And again, let me just have full guy. 65% of developers agree that DevOps saves time in the development process. That's a super majority. That's almost two thirds. That's pretty good. Which is still high. Yeah, it's not 81%, but it's still a pretty high thing. So by anyone's measurement, we would have to say DevOps is saving times in the development process here. Makes sense? Yes. Okay. So then we next found out the big learning was, everybody acknowledges that there are bottlenecks and delays in this development pipeline or by using DevOps, it still gets stuck. But where do they actually encounter these delays? The bottlenecks varied from team to team. The majority of this was in testing. The next one was planning. And even here, we found out that while the development and the operations and practitioner teams actually found most of the bottlenecks and the delays in their actual phases of work, whether this was testing, applying to production, et cetera. And it came to management again, bringing it because we just talked about it. Management found this, they were most frustrated and concerned about the planning phase of actually getting this kick started. And that's not very surprising, right? Because they spent a lot more time there planning and wanting to generate ideas and push them out. And that's where they want to get started really quickly. When the developers and the testers, they still work in silo teams today, even though they're practicing DevOps, they look at their local universe. The testing phase might have gone on from three months to two weeks, but they still think I can go faster. Yeah. Well, again, 52% or majority of people say that testing is where they encounter the most delays. I don't think that's not a number to be taken lightly, right? That's a significant finding. But I also, to me, it just feels true in speaking to DevOps practitioners around the world, because this is why continuous testing, automated testing is such a big piece of that DevOps software development lifecycle, right? Because if that's the single biggest cause for delay and we can automate more of that testing, it's got to come down, right? It's got to, you would think anyway. It does. And you can't start testing. We'll see a couple of slides down if you're not trying to continuously integrate right away. Yes. You can't do the automated testing without a CDCI pipeline. Without a CI mechanism. Yeah, you absolutely need that. And this is part of, whether you want to call it the software factory or the software development lifecycle, the continuous integration pipeline, you need that infrastructure, if you will. You need that assembly line. And we'll see a couple of slides down. Like I said, the idea here is that you want to take code change or your configuration change, whatever that might be, and put it into production readiness right away. And the only way to do that is continuously integrate into the main trunk. Yeah. And test it. That includes security testing, right? I was going to ask you about that because I don't see security up here. So I think testing there includes the security pieces of it. Okay. And you find that, you know, it's not just unit functional performance testing, but security testing is a huge concern. And often, you know, believe it or not, even today, security is still an afterthought for a lot of companies. They want to shift lift. They get it, but it's not an easy process today to do. So they'll often find code is ready for production, except it hasn't been security tested. You find, you know, the bugs and it goes back to the drawing board. So testing does become, you know, we call it verification or testing. It is still like the most critical thing and people, you know, don't want to go to production without making sure everything works. Absolutely. Ashish, before we go further, I wanted to just mention someone already asked in the question section. This webinar is being recorded. The slides will be available. We'll have them up on devops.com and devops.tv, usually within 24 hours. So hopefully that answered your question and we can move on. Absolutely. And so if you look at these findings, they were pretty interesting too. So, you know, we tried to ask teams to self-assess themselves as whether they were high performing teams or low performing teams. And then correlated them to other questions that we asked them. And there's a stark difference in the thinking and the performance of these teams, right? And whether this is because of the tooling they have, because of the culture that they have transformed, but the teams that can go faster, work on smaller pieces of code, get them out of production quickly, i.e. do devops well, we're finding out that they assess themselves as higher performing teams. And if you look at the characteristics underneath it, they validate a lot of that, right? So, you can see the project expectations, requirements, what you're going to do, how are you going to do it, how are you going to deliver are much better understood by these teams than those who struggle to take the ideas and transform them into production, right? Or production readiness. You see that, you know, if you look at, I'm given realistic deadlines, no deadline is unrealistic if the team performs well, they know what they can deliver at what point and, you know, what is realistic or not. The whole thing is the work is broken up in smaller chunks. The work is, you know, getting to the end really fast. And if it doesn't work, you can roll forward. They actually even end up taking higher risk, higher risk, higher reward, because there is no risk actually, like you can roll forward. You know, when I looked at this slide earlier, she, I'll be honest, I was surprised that the difference between lower performing and high performing was as close as it was, right? And I'll tell you in one area is I thought that. Product expectations and requirements set up front. Of course, you're gonna see disparity, I think, between low and high. But I was surprised that even in the lower performing organizations, 83% are responded, still said their ideas and opinions were valued. 83%. Now, 88% in the high performing set, so. But 5%, it's not a big delta there. It's not that big a delta. It goes to show you that whether high performing or low performing, engineers, ideas and opinions, these people feel valued in terms of that their ideas and opinions are. Even felt set up to succeed. I mean, I've been working with engineering teams for 20 plus years. In the lower performing ones, in the grumbles, you usually say, oh, I'm set up to fail, right? I have too many deadlines, too many deadlines, too much code, we have to push it to bigger features that too ambitious, a release schedule. Right, and again, numbers were fairly close, you know, with the kind of thing. But now we get to the last two, and I think the old patterns rear the heads, right? Right. I'm given realistic deadlines, right? I was impressed that 57% of even the low performing guys or folks was 25% of women. 57% of those people, you know, agreed with that. 70% in high performing, and that's a big number right there. I think it's, you know, they're correlating back to the deadlines that they get and how successfully they deliver them because project deadlines always get pushed out. And so there's this, you tend to forget that, you know, this was due to one scenario. We really blew it right. Phoenix Projects. Exactly. Two years ago, but we're still on track. We're on track. The deadlines have moved. But, and then the last question to me is the money shot, right? I rarely need to sacrifice quality to meet a deadline. Said no developer ever, right? Because they all sacrifice security testing or something. But again here, in the under performers or lower performing, 40% disagreed with that, meaning that they do sacrifice quality to meet a deadline. They do, but I think even like maybe, you know, the 40% and I'm, you know, we didn't double click in here, but you're trading something off. Yes. So maybe you're not sacrificing quality, but your deadlines are. Maybe you pushed your deadline out. Or the resources of the budget have gone out. Or maybe you cut scope. That could be too. You're right. Interesting. Interesting slide. Interesting results. And then we kind of double clicked into, where is it that it makes a difference for these teams who do well, right? And we found that removing roadblocks, removing like it says here, you know, the blockers in the development process, it starts with continuous integration as we had started talking about, right? And if you were doing continuous integration well, and you were automating that portion of the life cycle in the process, as well as, you know, other pieces in the process, in the life cycle, we saw that there made a huge impact in removing bottlenecks and kind of automating the process. I think it goes back to what we were talking about. You got to ship or get the code or, you know, the configuration change, whatever you do, production ready right away. The more you wait, the more you pile it up, the harder it becomes. It's sort of like accumulating debt. It is like accumulating debt and then having to sort of sort all of that out at some other point in the, in the life cycle. Yeah, yeah. I, before we move on, I'm sorry, just quickly. So, you know, I think our folks online here looking at this, look at it and say, yeah, that's pretty self-evident. Of course, doing continuous integration alleviates blockers in the process down the road, automating more is a top priority. Now, it says it's a priority, doesn't mean that they've gotten there. How successful, that's what I was saying. It's a top priority, but how successful are we at it? You know, you're talking to someone who comes from the security field and I haven't read a security report in 20 years where security was not a top priority. And yet we still have more breaches than ever. So, you know, there's an interesting disconnect there sometimes. So, we also asked, you know, just what we were talking about just now. Yes, you know that it's a good thing to do. How well do you think you did it? Are you doing it today? And it's interesting, you know, it's only about 15 to 20%, you know, saying we do it between very good to excellent. So, there's a lot of scope to actually increase and get better, you know, at continuous integration. So, we also asked a question about how does your tools here look like? You know, where are you struggling with this? How many tools do you typically use to, you know, do DevOps or even deliver software? And we found these interesting, right? These interesting findings. One was that they use a number of different tools that they put together. They would choose, you know, use open source, proprietary software, whatever they use, inbuilt at home. But they spent a lot of their time actually integrating these tools, right? That third box in there. And that was interesting because would you rather, would the organization rather have you work on delivering the next feature that can bring in more revenues or actually save costs? Or would you rather have them integrating? I know it's cool to integrate tools. You know, it's cool to kind of like bring these together. But the value of these developers, a highly expensive resourceful, you know, resources is better spent actually building the software. The other thing which we're all familiar with today is context switching. If you're using different user interfaces, you're using different tools. Yes, you know them well. Every time you take your attention off of one task and one tool and switch to another one, think about between your email and your Slack and your phone and, you know, like... I live it, I mean, this is my life. So it's really a productivity hamper. So let me ask the obvious question, right? And what's the answer here? How do we reduce that complexity? How do we reclaim that time, right? How do we become more efficient here? So let's dig a little bit deeper into this and maybe, you know, we get into that. What we're finding out is people are starting to choose tools that best help them, right? And though, you know, we're an open source company, we keep asking the question and we're finding that open source tools are becoming a very critical component to how developers choose to solve their problems. And the difference is one, the pace of, you know, innovation, the velocity of innovation and using the right tools or contributing to things that they want, they're not in there is a lot more with open source tools, right? So people are starting to look at tools that they can integrate with their stack that makes their life easier, that they can modify or contribute back to, they wanna be recognized as well. And so they're starting to turn into, you know, tools that are malleable, tools that they can use, that they can understand what's underneath the hood. And, you know, the hidden part of this is that there's a good community around it because as they face their problems, they can ask their peers or they can help their peers. So, you know, that's one of the things we found out. Yeah. We're also finding out that there is more and more propensity to try to use fewer tools if I can. Yes, I want the choice of my tools, but I don't necessarily wanna integrate six different, you know, tools because it's not just learning six tools or it's not just these context switching. Now I got an upgrade in one tool. I gotta make sure everything works. I got a patch coming in. I gotta make sure everything works. I mean, Ashisha, we recently did a sort of a snapshot of the DevOps tools market here at DevOps.gov. And most of our eBooks are eight pages, six to eight pages. This one came in at 72 pages for exactly this reason. And just about every category of the stack, there is such a wide choice of tools that, you know, I imagine being the person on the other side of that book trying to pick tools saying, what do I pick and do I really want more than three or four? Do I need 12 different tools in my software factory? And I have no control on the roadmap, so please, right? No, and they don't necessarily talk to each other. No, I mean, you know, you have companies that are acquiring other products and trying to make them work with each other. I've spent 10 plus years in companies like that. You can't even get the UIs to kind of look between one functionality. It's a hard job. It is, and again, put yourself in the shoes of the people who filled out your survey, right? And it's a daunting challenge. It is, and though this was focused at the developers and their managers, I mean, I'll ask you, but you know, my experience with even the highest level decision makers and IT organizations, they identify with this. They want the right technology we to use. They don't want to waste resources integrating these different tools all the time. They don't want things to break down, right? They want the ability to modify the tools for their own use, their own usage. From that perspective, you know, throughout the organization, these challenges remain the same from a tooling perspective. I agree, I agree hard. So here's our summary. So we talked about all of these things from the findings. What do you think? So, I mean, let's take each one of these and then sort of give our finishing touch to each of these points. So number one, there's obviously, I think a difference of perspective between managers and developers, but you know, digging in one layer deeper, is it that one is more optimistic than the other? Is it that they have different views of what the world is, right? It's sort of when I walk my dog, I constantly try to remember that she's only seeing things that are three feet off the ground, she doesn't see up. Not to equate developers to dogs or anything, but they have a very, you know, their worldview is what's in front of them and managers depending on organization and have another worldview. So I think it's important that we try to rectify those and equalize those views, right? There shouldn't be such a big disparity. I think that's when communication becomes important, right? You make sure we're all on the same page here. What do we think is this working, that working? And I think they need to find a way, I mean, people still struggle, you talked about it at the beginning to understand those metrics that are common between these two roles, right? So I might have tested faster today, but didn't make an impact overall to the cycle time across the organization. That's maybe a metric what the manager is interested in. Right, right. So it is important for them to start looking at the same data and trying to understand where they agree and disagree. Agreed. So then, you know, bottlenecks and pain points in the software lifecycle. You know, I think testing was probably the biggest one we saw here and that included some security. You know, I think we could all rally around that, right? And that's, you know, I think that, I mean, one of we says, what does DevOps mean? What is the definition? And what are we trying to do with all of this agile and lean and all of that? I think at the end of the day, that right there is a key piece of it. How do we reduce these bottleneck pain points? How do we make us go faster with better quality, more security? A lot of that is also, you know, coming from the fact that even though we talk about DevOps bringing the teams together, the reality is in large organizations, especially, there are organizations based still on functions. Yeah. And you can't just toss them up in the air and say, we now suddenly have smaller DevOps teams working together. Some people do it better than others, but they're again, you know, smaller organizations within these huge organizations. So as you still work side load, work with different tools, work with different processes, work with different cultures, and they have handoffs between, you know, these pain points get exaggerated, right? They get amplified. Agreed, agreed. A quick word on high performing team versus lower performing teams. To a certain extent, it's relative. What is high performing to you may not be high performing to me. And, you know, not everyone is going to be high performing and that's okay, right? Not everyone goes to college. That's okay. But I think we have to ensure is that even the low performing teams have access to what they need to succeed. And at least know of a pathway to become higher performing if they so choose to do pursue that. Let me give you an example here that might actually bring this point home. So first, these were self-selections, right? Mm-hmm. But if you really look at it, I've been with customers to whom when you paint the vision of what DevOps can really do, which is at the push of a button, you know, you can deploy code within minutes. They say, not really looking for that. I'm happy with bringing down my deployment cycle time from nine months to six months to three months. And that's huge. And that's huge for us. And we are good with that. And therefore, you know, I wouldn't equate them as higher or lower performing teams. But think about a company that's satisfied by deploying every three months. That's the business requirement. What if there's actually security patch? What if there's actually something that goes down that you need to fix? Your cycle time should support an hour, right? So you want to enable all of them to be able to perform at a high level and then choose the cadence that they want to go at. Got it. I don't disagree at all. Toolchain complexity is absolutely can be a drag on innovation. I'd like to throw another drag on there in a similar vein though, Ashish. And that is, we have such a plethora of tools. We also have a plethora of languages and infrastructure. In a lot of ways, today's IT world is a tower of babble with all people talking different languages at different speeds and so forth. And that is something we probably, you know, I always thought of IT as a universal language. It's ones and zeros, it's bits and bytes. But it's not, you know, in real world, that's something we need to work on. Absolutely, that complexity you mentioned is something that really frustrates people, right? It's the choice of platform, it's the languages. It's bringing all those tools together, those languages together, those platforms together. It really, you know. Absolutely, absolutely. You know what, we've got some time though. Let's do a company overview maybe people who aren't familiar with GitLab. Thank you for that opportunity. I mean, I'll take a couple of minutes, but you know, all the problems we talked about, I think, you know, GitLab has had a unique approach in solving this. We started out as a Git repository, quickly built a CI engine, and then quickly realized like, you know what, why do we need these different tools to do these things? So we built one application that integrates all of these workflow functions in there. And if you think back about this, right, it's a single application for the complete application or the life cycle. With one installation, actually, you're looking at what one user interface, one data store, you're not integrating tools and allows people to start collaborating together on the project. So the extreme left shift that you need, that's what we allow really better. And it's an open architecture. It's an open source architecture. You can integrate other tools that you're completely using. The interesting part about this is, we have more than 1,900 contributors on the open source community. And every month on the 22nd, sorry, every 22nd day of the month, we release and we actually deliver functions and features that our customers are asking for. And we have sometimes our own customers contributing to this. So it's a really like fast-paced innovation. Before you get into the obligatory customer slide, I wanted to mention something with this. So number one, can you go back one more slide? I'm sorry. So when we look at this, the single application for a complete DevOps life cycle, what I think is a real plus for GitLab is because this entire assembly line, if you will, this entire factory is open source through Git, through GitLab, you can adopt any one or all of these pieces, relatively low cost initially, right? Look, there's a- It's free, in fact. Our community- It's free. There's a total cost of ownership in open source as well, right? You don't pay for the software, but there's other costs. But it's a rapid adoption, right? It's much easier to just download it. And that's what developers love about open source. We could download, adopt this, download, put it in, and I'm doing it this afternoon. Actually, you can go to our SaaS-posted version, create an account and get it out of there as well. And do it there as well. Drop your code. What I didn't talk about here is the feature we have that's coming out, it's called AutoDevox. So you drop your code, we'll recognize the language. We'll actually build a pipeline, we'll do the tests, tasks, tasks, everything, start monitoring it, and it's done with the next. That's a beautiful thing. Now, in real life, unfortunately, we don't have green fields, we get brown fields. And people may have already made an investment in one of these waystations along the factory floor, if you will, along the assembly line, the pipeline. What's nice about an open project like this is if you are already using something, you can still use the rest of the GitLab because of the ability to integrate. Absolutely. And that's what we have taken an approach, is we don't expect you to rip into place. Right. We don't expect you to start using all the functionality right away. So we've had customers who were using competitor products in each one of these areas, but they found this approach very, very, kind of useful, very good. They started on, either maybe they started on the CI part of this, or they started on the repository part of this. Some of us, some of the customers are adopting us because they like the testing and that's built in, container security testing, all of it is built in. And as they get more of their practitioners onto this, they're realizing, okay, the more functions you adopt along the line, the faster your cycle time drops. And so, each organization's own pace and the needs that they can adopt this. Agreed. And that, I've told you this as she's talking privately. To me, that's the real attraction of GitLab, right? When we look at the breadth of the offering, the breadth of what you guys can help with, right? But the ability to pick and choose what you want to. So it's not an all or nothing, but yet there's plenty to the offer. Yeah, absolutely. And if you wanna do fresh projects, greenfield projects like you talked about, there's not much you have to do to get started and deliver. Absolutely, I agree, 100%. All right. We talked about this, I mean, the adoption in the market places is tremendous, right? I mean, all of these organizations are using this. So I wanna leave some time for questions and answers that you might have about it. All right, I don't see any questions in this second in the queue, but let me, I always have questions. So if you don't mind, is she? So let me ask you this, what's next? You mentioned, what do we call automatic DevOps? Auto DevOps. You know. We're using it next month, we're going GA next month. It's already available, we're going GA next month. So let me just get it straight. I drop code in, you recognize the language based upon that code, you build my CI pipeline. CI CD pipeline, all the way through. We run the tests, include static tests, dynamic tests, you know, the normal function unit testing and anything you've integrated with this. It configures it and deploys it. Wow. And it starts to monitor it. So we have a Prometheus integration built in. Really? Yes. How long have you guys been working? This had to be something you're working on for some time. So I think it's been a few months we're working on this and one of the reasons that amazes me and surprises me even after I joined the company and this was amazing to me before I joined the company was talk about a vision and what we want to do and it's there in a few months, three months, six months like this whole complete end to end DevOps lifecycle. I think it was an vision last year. Wow. And by the end of this year we would have completed that vision. And the reason is very simple I think, you know like we get input from our users. We get contributions from them. We get contribution from them. We can't do it all alone. And then we have our own in-house team, right? That builds this tremendous velocity. Yeah. But again, I think you can't have that velocity. The velocity goes hand in hand with the model here. Yeah. Of having that distributed thing. So is that the ultimate, not solution but the ultimate goal to do this automatic or DevOps automatic kind of thing like that you think? I think it was beyond that but right now we're kind of focused on delivering this. This was our vision for 2018. The good thing about a platform or a project like this is as the market needs change, what we hear, what our customers want we gravitate towards that and solve that problem really quick. And so a lot of our customers when they're scared of vendor lock and we're not really a vendor, right? We're a partner and it's a project that you share with us. So it gravitates towards solving the problems that you need to solve. Got it. Excellent. And then, so beyond this project, is there anything else you can tell us you guys are working on? That's coming. But I think in the short term I can share that look we've built the breadth of this product really, really fast, really well. And we continue to build the depth in each one of these functionalities, right? And we are at a point now for example with the acquisition of gymnasium and other open source projects contributing. We're looking at further security you know kind of integrations from open source projects. Now I'm having conversations with industry experts and they're saying this is by far already starting to change the face of DevSecOps while we're approaching this. And so looking at particular use cases like that and building the depth is you know also something on our radar. Absolutely. So you mentioned DevSecOps near and dear to my heart. Talk to us a little bit about what you know what are you guys specifically doing around the DevSecOps piece of this? So look we have, I mean other than you know built in SAS, DAS, container security all of that. The approach. That's not a small value. It's not. It's not. We did that before we went to bed tonight. But that's a big job. It's a huge thing, right? But I think the fundamental approach here is everybody realizes that security testing needs to shift left. Anything that you catch in security after the fact much more expensive, much more harder to fix. And though everybody theoretically understands that you need to start at the same time you're developing a planning code or writing code it is hard to do. So with our approach what we've really done has made that vision a reality. Because as soon as you open an issue as soon as there's a merge request you see everything on that same UI that's related to security. And it starts to build with security in mind and goes through the testing. And everybody has the same UI to look at. Everybody has the same, I mean all the pairs of eyes are looking on that merge request as it goes through. That's more of a cultural and organizational change that is hard to drive in an organization. And that's what we actually enable to do. I know I trivialize the functionality of what we do but that's the easy part to solve, right? How do you like fundamentally shift teams to work together from a cultural organizational perspective? I think this tool allows it. You may not have this info but in this survey of 5,000 some art people would be responded. Do you know what percentage of them considered themselves security people? I do not have that at the top of my head but there's a link at the end of the deck that points back to the survey. And it's an open survey, right? It's not good, you don't have to register. You can go and read through all the findings on that. You know, we'll put that link in when we post the recordings and slides. So we'll make sure we have that. So if we don't have any questions then, we can wrap up this webinar. Thank you very much for giving us a great look at this results of the survey. A good update on where GitLab is. Bunch of links here for our listeners and people may be watching this on YouTube after the fact, these links work fine and you can click on that. And we hope to have you soon on another webinar. Thank you for inviting me and this was- It's our pleasure. This was great. This was good fun. Yep, Ashish Kuthiala, Director Product Marketing at GitLabs. And this is Alan Schimmel for devops.com. Thanks for joining us on another devops.com webinar today and we hope you all have a great day and we'll see you soon.