 All right, I think we can get started. Hello and welcome everyone. Thanks for joining us today. We're very excited to have you on. In this webcast, we'll be covering hot topic on why the DevOps platform for enterprises. My name is Agnes and I work on the marketing programs team here at GitLab. We'd love to hear where you are tuning in from. Please use the chat function to say hi and tell us where you are in the world. Before we get started, I'm going to cover a couple of housekeeping items. First, feel free to ask questions throughout the presentation. You can use the Q&A function at the bottom of your screen for that. We'll have dedicated time at the end of the webcast for questions, but you can go ahead and send in your questions as you think of them. And if we run out of time to answer your questions today, we'll follow up with you after the webcast. If you are experiencing any technical difficulties, you can use the chat function to get in touch with me, the moderator, for help. Lastly, we'll be recording today's presentation just so everyone in attendance is aware. The recording will be delivered to all registrants in the next few days. Our presenters today are Francis Potter, our GitLab's competitive intelligence specialist and Somya Vidapaya, GitLab's senior product marketing manager. We're going to launch a couple of polls at the beginning of the webcast so we'll learn more about you. That way, our presenters can tailor the presentation accordingly. With that, I'm going to launch the poll. Oops, looks like I accidentally launched the poll beforehand. So if you don't mind kindly participate again in the poll and we'll share the results in a couple of minutes. Okay, thank you again for participating in the poll. I am going to share the results here and pass it over to Somya. Okay, thank you Agnes. I can still see the poll on my screen. Oh, I'm just sharing the results right now. Okay. Yeah, it looks like quite a few people are actually not GitHub users at the moment and using GitLab mostly for social management. Okay, so let me get started. Hi everyone, my name is Somya Vidapaya. I'm a product marketing manager here at GitLab based out of Bangalore in India. And I'm going to first cover the section on why DevOps platform for enterprise. And we'll talk a little bit about the evolution of how organizations evolve in their DevOps journey. And then I'll hand it over to Francis where he's going to talk about our response to the GitHub universe, okay? So it's really true. That software is eating the world. And this has expedited in the last two years as a lot of organizations that we are talking to and we are seeing are trying to adapt to the new style of working. So as we went along this journey, digital transformation has been the top priority for a lot of organizations that we spoke to. It's really table stakes now. But this transformation has been extremely difficult to achieve for a lot of organizations. Again, as per McKinsey, as you can see on the screen. But it is not due to a lack of intent. Yes, all organizations have the right intent. They're doing the right things. They're hiring, they're training, buying a lot of tools to transform their journey. And then they're working with partners to enable this as well. But it's really not adding up to the return on investment that they were expecting when they started the entire process. They've spent thousands of hours and millions of dollars in trying to transform their organization and their system. And the means that they have been using to get through this transformation is DevOps. They want to build a culture of collaboration. They want to automate the end-to-end processes, but they haven't been able to get the success that they've been trying to get to. So what is this transformation actually looking like in many of these organizations? So in the rush to transform, a lot of these organizations are modernizing their infrastructure. So they're moving to cloud, they're moving to containers. As a result of which, they have to modernize their applications as well. So they need to move from monolithic architectures to a lot more microservice-based architectures. They also need to modernize their tool set. They need to bring in additional tools to cater to this new form of working, to this new form of collaboration that they're trying to achieve. And they also need to modernize the process. So they need to move from a waterfall to various different agile-based development models. By doing this, they hope that a lot of their teams can work in parallel, they can work independently, and they can move faster. But what it has actually resulted in is just a lot more things to manage, a lot more projects, a lot more tools that they actually need to manage. So as organizations started their modernization journey of their infrastructure application processes, they brought in various different tools to manage very specific problems. For example, if they have a repository problem, they bring in a central repository, like a source code management tool. If they have a code review problem, they bring in a tool to fix that. If they have a security problem, they bring in a tool to fix that. Imagine that you're trying to solve a security problem. So you need various different types of security tools to solve it, right? Let's say you need static application testing, dynamic application testing, container scanning. So you leave at least five to six different tools to solve or just to manage your security posture. Again, as teams adopted Agile and DevOps, this complexity has increased and continued to increase significantly. And the number of tasks they had to perform and integrations they had to manage between these various tools increased as well. So what is this journey look like? So as we've worked with a number of thousands of customers over the years, we've identified that most organizations, typically have four phases of DevOps adoption, right? Through which businesses have passed through, some of them go through all of these phases, some of them skip through some of the phases, right? So it's useful to understand where you actually fit in so that then you can work on improving your velocity as well as quality. Phase one is where what we call bring your own DevOps, right? So in this phase, each team has an OKR that they need to improve their own productivity. So they bring in their own tools to get more efficient with that specific tasks like testing, security, requirements, and so on. While the goal of DevOps is really to break team silos and make teams work together, by doing this, that is bringing your own DevOps, each team bringing their own tools, it reinforces these silos even further. So each team goes into further silos based on the tool that they have actually selected. So what really happens in this phase is although the goal is that you want to go the DevOps route, you want to increase collaboration, it has resulted in redundant purchases. Various different groups within an organization might be purchasing the same or similar tools for the same use case. There are a lot of incompatible tools. One tool is not talking to the other tool. So they again need to spend a lot of time and effort to manage these multiple tools or tool integrations. There's data and process silos. Overall, there is no alignment between development and business goals. There's no consistent application of security or compliance as well. So although bring your own DevOps helps teams to feel that they're being more productive, but really it has caused a lot of manageability issues and confusion across various teams that have brought in these various tools. So to address this, so once organizations realize that, hey, I have the same or similar set of tools being purchased by different parts of my organization, I need to standardize on the tools that I'm going to use and I need to reduce the license cost. That's when they move into the second phase, which is the best in class DevOps. So in this case, a single tool is standardized for a specific use case. For example, all teams having a repository requirement standardize on one single tool like GitLab or GitHub or whatever they choose to standardize on, as opposed to using three to four different repositories. Yes, using multiple tools for the same use case is commonplace in many, many organizations that we have already worked with. Now this phase is definitely better than the previous phase as it helps teams that you have the same use case to collaborate with each other. It also helped organizations to reduce their license cost significantly because now they're aggregating licenses. They can also negotiate for a better price because they're looking at more licenses with the same vendor. Training became a lot more easier, but since the tools that were chosen were not connected, the problem continued to remain. So for example, how would you tie, let's say a requirement that you had to a code change that was made to fix that requirement to a deployment that was made to actually solve that problem. So all of these could be different systems that are not talking to each other. So that problem still continued although there was a standardization of the tools that we wanted to use. So that brings in the third phase of DevOps. So once organizations standardize and realize that, hey, now I have a standardized tool but these tools are not talking to each other, they want to make them to start talking to each other. So in this phase, we call it the do-it-yourself approach. So you have N number of tools, you start stitching them together, you build integrations between these tools. But the challenge with this approach is it's not just a one-time thing that you build the integration, you need to maintain the integration. Imagine if you had to upgrade one of the tools. The integration that that particular tool has with all of the other tools needs to be fixed as well. Now this DIY DevOps, while it works to some extent, is very expensive as many organizations that have arrived at this phase are now realizing. So this phase as well did not solve the problem that the transformation was expected to solve. That is faster deployments, easier of manageability, better collaboration and lower cost. And that brings us to the last phase of DevOps, that is the DevOps platform. Let's talk a little bit about the Gartner Value Stream Delivery Platform Report. So in this report, Gartner identified the challenge that organizations are facing, especially with the first three phases that we already spoke about. They said that organizations are finding it extremely difficult to scale because of three key problems. So one, multiple point solutions. That's what we spoke about in the first three phases. Second is as a result of multiple point solutions, the teams are having difficulty in reducing the time to market. And thirdly, they're not able to collaborate and not able to set up secure access as they transition into remote working styles. To fix these, these were the three problems that we also saw in the first three phases that we spoke about. So to fix this, Gartner actually recommends that organizations need to adopt solutions that reduce complex tool changes. They have to adopt tool changes that provide end-to-end visibility, traceability across the pipeline, as well adopt a cloud-based value stream development platform, delivery platform. So many organizations are actually adopting this phase four or are moving towards this phase four as well, which is the DevOps platform. Such a platform, the benefit of such a platform is that it is pre-integrated with all phases of the DevOps lifecycle. It fundamentally changes the way organizations are approaching DevOps, right? So it replaces the overhead, confusion, integration challenges that we saw in the first three phases. And then it provides visibility and control through all parts of the DevOps lifecycle. While the four phases of DevOps is how we have seen GitLab customers evolve across thousands of customers that we have worked with industry experts like Gartner also agree, right? So they recognize the arrival of the DevOps platform era. So they actually in 2020, the report said that the platform approach was in its early stages. Only 10% of organizations that they have interviewed actually were using that. And they predicted that two years from then nearly half the companies are going to take this route and move towards a DevOps platform approach for better productivity and better security of the platform. And this not only helps them to align on the goals that they have for their transformation, but also it helps them to achieve a competitive edge. And this is precisely what GitLab has been doing for many years, even before the whole term DevOps platform came about, right? So GitLab is the only true first and only true DevOps platform. It's a single application. It has a single user interface. It has a single data store. There's a single permission model and it has security embedded within the DevOps lifecycle. This combination allows you to do things that you couldn't do with the previous three phases that we spoke about, right? And that is the power of actually using a DevOps platform because now you're able to do project planning, development, security, release management across all of the personas in your organization, right? Whether it's a developer, whether it's a security personal, whether it's a testing personal, whether it is a release engineer, all of these teams can actually work together on a single platform to achieve the single goal that you have as an organization. But don't just hear it from us, right? So the largest and most innovative organizations in the world have already shifted to a DevOps platform approach and they're already using it to activate their transformation or investments. And what is the benefit that they're actually seeing? So in 2020, we had Forester actually conducted the research to understand the total economic impact of using GitLab. So they interviewed a bunch of customers and they saw that customers were seeing 400 plus percent ROI in three years of deploying GitLab. So this is significant savings both in terms of cost as well as in terms of the ability to operate a lot more efficiently. So customers saw a number of benefits, right? So they saw a reduction in cycle time. So which means that their developers and other team members are able to be more productive and they're able to increase the number of releases. They saw a 12x increase in the number of release. They also saw an 80% reduction in the number of defects and that is because we are able to do all of the tests including security tests as a part of the pipeline itself. And in addition to all of these benefits, they were able to retire four or more tools every single year. So again, the developers don't need to spend time and effort in maintaining these expensive integrations that we spoke about in phases one, two, and three. So where do you start, right? So GitLab will meet you where you are. You can still use your existing toolset and integrate with GitLab for the rest. For example, if you're already a heavy Jira user, then you can continue to use Jira for your project planning and then use GitLab for the rest of the DevOps lifecycle including SCM, CICD, security and so on. Similarly, if you're an existing GitHub user, you can still use that and then continue to use GitLab for the rest of your DevOps lifecycle and so on. So we have out-of-the-box integrations with some of the tools that are mentioned over here and then we have APIs available that help you to integrate with other tools that you might be using in your organization. And to help you realize the full value of your investment, we have a very strong partner ecosystem, work with many partners, including a lot of local SIs and global SIs like Accenture. We also have partnerships with a lot of cloud providers like AWS and GCP, which helps you to, if you wanna go that route, it can help you to exhaust the budget that you have allocated towards those providers to purchase GitLab as well. So that was a quick overview of the DevOps platform. With that, I will hand it over to Francis who will walk us through our response to the announcements made at GitHub Universe. Over to you, Francis. Terrific, thank you so much, Tanya, for that excellent summary. So I'm Francis Potter. I head up competitive intelligence at GitLab. So I think about all of our competitors. And so we wanna specifically address some of the things that GitHub brought up at their Universe Conference, which was a virtual conference about a month ago, maybe six weeks ago, where they talked about a lot of the components of the GitHub sort of system world. And many of which map directly to things that we offer at GitLab. And so I wanna make sure that you're aware of all of those. And also that we address any specific questions that you have about GitHub functionality or capabilities and how sort of GitLab responds to those. So feel free to use the Q&A button at the bottom of your Zoom window to ask those questions. So one of the main things that GitHub talked about at Universe is code spaces. So code spaces is a virtual development environment hosted in Azure, of course. It's basically a virtual machine running visual studio code and a shell where you can not only edit your code, but also compile and run it within that code spaces environment. So the idea is that a developer working on a project doesn't have to install all of the compilers and interpreters and code libraries and everything for a specific project. They can just spin up a code space and work on a project there. And GitHub themselves are actually using code spaces to develop GitHub. So not all of the developers, but a lot of the developers are using it. GitLab has an equivalent. We've partnered with Gitpod, which offers a very similar kind of functionality to embed VS code in a virtual machine that you can actually spin up through Gitpod. So while GitHub is making a big deal out of code spaces, you can actually get the same functionality from GitLab and we're very proud and excited about that. The next thing they talked a lot about is what they call the new issues, which is a little confusing because GitHub has had issues for a long time. But what this really is is a new project view, what they call a project view, which is basically a collection of issues and merge requests from across a set of repos. So not just within one repo that can be managed together. And they have some pretty cool things there. There's like, this view here on the left is the table view, which is pretty cool. It allows you to like really quickly and easily add new issues and stuff. And also they have custom fields, which is great. But otherwise it's pretty much the same as what GitLab has had for a long time in our project and portfolio management feature set. In fact, we have things like the roadmap view, which is on the right here, which is a lot more kind of tuned to the needs of project managers and allowing large scale teams to really collaborate across a project and with Epic and Epic hierarchies. And so even though there are some neat little kind of whizbang features that GitHub has added ahead of us, we think that our project management functionality is still far superior to theirs at this point. But obviously we're gonna need to keep working on that. And this is from Gartner's Magic Quadrant from earlier this year, showing GitLab in the leader sector of enterprise agile planning tools. So don't just take it from us. The experts are saying the same thing that we're really among the leaders there. Then there was a lot of talk at Universe about GitHub Actions. GitHub Actions of course is GitHub's answer to GitLab CI CD. It's very similar in a lot of ways in that it uses a sort of a YAML syntax to configure, and it's built into their pull request model, dumps its output like this. So it's very similar in a lot of ways to GitLab CI CD. But it's also, we think about two years behind GitLab CI CD in terms of maturity and functionality. So for example, we offer a lot more runner configurations for running your jobs. You can run them within Docker, you can run them directly on VMs, you can run them on hardware, you can run them on mobile phones, you can run them on embedded systems and on and on. We also offer very advanced caching and artifact management built in with GitLab. There's of course our Kubernetes integration. It's a multi-cloud system out of the box with sort of native integrations with Amazon and Google Cloud. There are review apps out of the box. There's integrated release management, integrated security scanning. Of course our application security testing is among the best in the industry. And of course everything that we do is open source. So we have that ability for people from around the world to contribute to the code base. We also have auto DevOps. So Git Hub likes to talk about how they have 10,000 actions in their marketplace, which is neat. It's a pretty neat system to sort of basically have other people build your components of your actions. The problem is you don't know what you're getting. You don't know how secure it is. You don't know how good the quality is. The different actions could be inconsistent in terms of how they're implemented from one marketplace entry to another. What we offer is a set of standardized CICD components. We call it auto DevOps, but it's really a whole set of different components that you can use to run things like security scans, integration tests, deployments to Kubernetes, and on down the line. So we're kind of offering you our own marketplace as it were, which is sort of certified by GitLab and part of the product. So we think it's kind of a superior model in a lot of ways. One of the things that Git Hub actions does really well that I'm a little bit jealous of is it can be used to be, it can be triggered on all kinds of activity within GitHub, like creation of a new issue. And it can also perform all kinds of activity within GitHub, like creating an issue or creating a project. And so there are some pretty cool workflows that you can kind of put together with actions. But we've also heard that GitHub sales reps are basically saying to enterprise customers, don't rely on actions. It's not ready for your scale. It's going to be about two years before it's sort of up to par with your more sophisticated CICD systems. So as you probably also know, GitLab offers a wealth of application security testing tools. Git Hub loves to talk about their security, but it's not merely as mature as what we offer. We have our SAST and secret detection and dependency scanning, which are sort of equivalent to GitHub features. But then we have our code quality, our DAST and review apps, our Fuzz testing, our API testing, our license compliance, and a complete vulnerability management suite across a repo that allows you to, allows not only the developers, but also infosec teams to be able to track and manage the vulnerabilities that have been found in projects at a project level or at a higher level, at a portfolio level. So really for enterprises, especially GitLab's application security testing is really second to none. And once again, we've been sort of recognized for that by Gartner as a challenger in application security testing. GitLab has a fundamental difference from almost all of our competitors and certainly from GitHub, which is that it's an open source core. And this is really important because although it sounds like sort of a theoretical thing, in reality, it makes a big difference in terms of your long-term relationship with GitLab and your long-term usage of the product. So we are leveraging DevOps best practices of over a hundred thousand organizations around the world. We have a passionate vocal global community with thousands of merge requests and code contributors sort of pitching in every day to make GitLab a better product. And every single release has an average of 35 new contributors and 200 improvements. So our rate of development is accelerated by open source contributions. And a lot of those contributions come from customers who have decided they want to help develop certain kinds of functionality within GitLab and they developed that and contributed. So that's what we call co-creation. Thousands of feature proposals, customer-driven innovation and basically continuous innovation. So we deliver a new version on the 22nd of every month. This chart on the right is the number of contributions from outside of GitLab. So from external contributors that are merged each month and you could see it's in the hundreds. So we're really, really proud of that. And I think that makes, that's something that a lot of other companies like GitHub can't even possibly start to compete with. And oh, right. It's also built on powerful open source technologies like Kubernetes and Prometheus. We offer direct integration with Kubernetes. We have a new agent for Kubernetes. We have Prometheus for monitoring. And so we're really building on open source components from around the world. So those are the main key points I wanted to talk about with regard to things that GitHub introduced or talked about at Universe. In fact, very little of it was new. And so I wanna go now to questions. Somiya, do you have the questions there? Yeah. Thank you, Francis, for the insightful presentation. So there are a few questions from the audience that I'd like to take. I'll take the ones that are relevant to the GitHub discussion. So do we, GitHub have something similar to GitHub discussions? Is one of the questions that we received? Yeah, that's a great question. And actually the answer is not really. We do have the GitHub forum, which of course is a great place to ask your questions and discuss your issues. And also we have GitLab issues, which of course everything that we're working on in GitLab is tracked in our issue tracker and under GitLab issues and EPICS. And anyone anywhere can add comments and contribute to those around what GitLab is actually working on. So there are a number of different ways to participate in what GitLab is doing. But it's not like the discussions feature specifically the way GitHub has done it. We sort of think our way is better integrated with the product itself. Okay, so the other question is around generating static websites. Can we use MK docs on GitLab to generate static websites? I don't know about MK docs specifically. Obviously you could do that. You could write that within GitLab CI and probably like four lines of configuration to run MK docs on your site and publish it. We do have GitLab pages, which is very similar in a lot of ways to get pub pages. It uses markdown and actually there are a number of different site generators within pages. Maybe there is one for MK docs. I don't actually know, but I could be wrong on that. But our pages functionality is basically more powerful than GitHub's because GitHub's is really only using Jekyll. It's also more powerful in that GitLab, the self-managed version, you can actually scale up those pages servers in to whatever extent you need to. So we offer that horizontal scalability that none of our competitors really offer. And that allows you to scale those static websites up to a really large size if you want to. Awesome. So the other question was around, I think it's a fairly generic question and maybe you could point to a different resource. How does GitLab contrast to GitHub or what value does GitLab give in addition to what GitHub already gives? Yeah, great question. Obviously, if you put them side by side with regard to source code control features, you'll see a lot of similarities. I mean, we study the differences, but they tend to be at kind of the detail level. But when you take a step back and you look at your company's overall strategy for DevOps and that idea of the DevOps platform that you were talking about, Samia, you start to realize that GitLab positions you a lot better for the future than GitHub does. We're much more focused on the enterprise needs that end-to-end auditability and security that's so critical for large companies, the end-to-end user management and permissions management that makes it so easy to kind of add phases to your DevOps process. And also all the stuff on the right-hand side of the equation as it were. So deployment and management of deployments and releases with our integrations with Kubernetes, monitoring of those releases, active defense of production applications is all part of GitLab. And GitHub doesn't even come close. Also that application security component, which is I think several years more mature than anything GitHub offers. So I think if you look end-to-end at sort of everything you're doing and you're really looking for a platform partner that's gonna grow with you and continue to sort of be a good place to be invested, there's no question that GitLab is the better choice. Absolutely. And I think the next question should actually all, the response to the next question should probably cement that as well. So the question is about scale. So this person asks, we're considering GitHub but we have heard about some questions regarding the scale of GitHub. So how does GitLab compare in terms of GitHub scale in terms of scale? Yeah, that's a fantastic question. We hear this a lot, especially with large customers, like really large global companies where they've adopted GitHub Enterprise and now they can't use some of the features because the feature just freezes or dies or their polls and clones have just gotten super, super slow. GitHub Enterprise is basically shipped as an appliance. It's sort of a virtual black box. So you can scale it vertically. You can add processor power and memory and storage and things to the box that it's running on but you can't really scale it horizontally. You can't really add servers very easily to GitHub. GitLab is a completely open architecture. And so not only can you scale it horizontally so you can add database nodes, you can add Git nodes with our proprietary Git software called Gitaly. You can add web nodes. Like I said, you can have pages nodes depending on kind of the architecture that works for your organization. And we also help you do that if you're running it on one of the public clouds. So there's lots of documentation and how to scale GitLab on AWS or Google Cloud or even Azure if that's what you wanna do. And also because of that open sourceness and the kind of ongoing rapid development of GitLab, you know that you're always gonna get the high performance sort of improvements on an ongoing basis. If you find a performance problem, you could tell us about it and in an open way we'll work with you to solve it quickly. So I think there are a lot of advantages when it comes to scale. And there are companies that switch to GitLab specifically because of the horizontal scalability of the system, which is necessary if you're gonna have a DevOps platform for your entire company. Awesome. And we have one last question before we can end this webinar. So how do I justify the additional cost of GitLab to my management? It might be an additional cost. It might not. It depends on what deal you're getting from Microsoft on GitHub. A lot of times we've heard the rumors are that they tie their deals to large scale Azure deals. But the real justification is that this is a long-term strategy that covers the entire DevOps life cycle. So like I said, if you're just comparing source code control, nah, you know, oh, there are details that are different. But if you're comparing the cost of all your security scanners, your deployment tools, your Kubernetes tools, your monitoring tools and on down the line and your project planning tools at the front end, you'll realize that GitLab is actually not more expensive. It's actually far less expensive than the alternatives. Once you've sort of adopted the strategy and decided that the DevOps platform is for you. Right, and that also came out in the Forrester report that we discussed where organizations who adopted GitLab were actually able to get rid of at least four tools every single year that using the cost of the license cost and the maintenance cost of those tools as well. So over a period of time, it tends to get a lot cheaper to use GitLab as opposed to N number of other tools that you might be using currently. Yeah. Okay, great. That's all we have from the audience here. And thank you so much, Francis. Thank you, Agnes. And thanks everyone for joining. Thank you all. Yeah, thank you.