 So, good morning everyone. I'm Amita Roy. I lead the solution architects team here at Red Hat. We have several of our colleagues here from Red Hat that are part of the developer business unit. I think they have a great job because, you know, their primary objective is how to make the lives easier for developers and how to really contribute to developer productivity. And I'm sure you'll be meeting them through the day, through the various sessions, and on the sidelines of the event. Last week, I had a chance to attend the Gartner IT Symposium in Cochin. And one of the sessions was, they were talking about what are the key trends that they're seeing in software engineering. And what was interesting is that one key trend among those was developer experience, you know? So, we are very happy that, you know, whatever we are doing is in line with whatever, you know, Gartner's research is demonstrating. And I think it's in some ways, if you really look at it, it's not a surprise, right? Today, if businesses have to transform, you know, they have to really look at what services are they providing to their clients. And if they have to look at what services they're providing to their clients, they depend on applications. If they depend on applications, they depend upon people who develop those applications, maintain those applications, right? So, this is a very key area of focus then for Red Hat. And that's the reason why everything that we're going to talk about in the next 30 minutes is about what Red Hat is doing to really help drive, you know, developer productivity. And if you really look at a comparison between past and the present, right? When I started off my career, we had to write all the code from scratch, you know? So, while, you know, when I started off the C++ and very, very soon Java had entered the scene, but we wrote everything, you know? So, it was all about, you know, compilers, debuggers, etc. And that's what programming languages were about. By the time my son went to college, you know, there were templates that were available. And you could, you know, fill in the blanks kind of a thing where you write the business logic and, you know, put in some of the rest of the coding, right? Today, we're talking about a lot of code assistance that is available via tools. But at the same time, you know, while one may think the lives of developers have become easier, I, would you agree, I think it's become a little more complex because, you know, today when we're talking about companies driving digital transformation, are they writing applications from scratch? No, right? There are legacy applications. There are applications you're building which are in a cloud native manner. Then, you know, you have a whole bunch of deployment environments, right? You may be deploying on bare metal, private clouds, public clouds. You know, today we're talking about Edge as well, right? So, and then we're talking about this whole hybrid mix of applications. And to add to that, we're now talking about AIML workloads as well, right? So, it's not exactly become easier. So, how then, you know, can we continue to drive developer productivity while ensuring that, you know, security and everything else is not, you know, compromised with? So, in that context, when organizations focus on developer productivity, there is research that says that the revenue, you know, can go up to 4X, 400% increase, you know. That's the kind of focus that, you know, developers then, you know, and the organization they work with are trying to bring in. And when you talk about productivity, it's not just about speed at which you develop, right? There are so many other factors that need to come into it. And in that context, when we look at an ideal developer experience, there is some research that has come from, you know, the University of Victoria and Microsoft Research, where they have brilliantly captured about 25 factors that impact developer productivity. And that has come into a framework of three, which is what I'm going to talk about. One is cognitive load, other is flow state, and the third is feedback loop. And everything that we're going to talk about is in relation to this, right? So, when we talk about cognitive load, just the other day, you know, as is typical in day in my life, you know, I'm in a hotel room, I enter the room, and you find that the TV is already on, you know, trying to give me some promo about, you know, whichever brand of hotel I'm staying in. And I'm looking for the remote to turn it off, not turning off. Then I think it's a battery problem, issue and all that. I call housekeeping, and then I feel very sheepish when they tell me that this remote is not for the switching off of the TV. This remote is for something else, and this TV is, this one is for, for you to browse the channels. Okay. Now, all of us have been, have seen all kinds of remote controls in our lives, right? Don't you think this is a lot of cognitive load? How many of these buttons do we actually use? You know, we probably need to switch channels, increase volume, decrease volume, and, you know, probably turn off the TV, right? So, if you really look at this, isn't this a lot more simple and intuitive, right? So, it's, it's in every walk of our lives. A few years ago, I had to go to a bank and fill in a chalan if I had to go and transfer money to somebody, and then they will take that counterfall, stamp it, give it to me, and that's how money transfer used to happen. Then we said net banking happened, and now we are talking about using QR codes and, you know, just doing it on the fly, right? A lot of cognitive load that has been reduced, you know? Imagine if we can bring the same wow factor to developers as well, reduce the cognitive load, and what do we mean by that? We're saying that when developers are, you know, getting started up, let's say you joined a company, okay? And you have to get started. How long does it take before you can become productive? You have to set up, you know, whatever are the processes, the tools, and everything else before you can really start writing in a productive code, right? So, how can we reduce all that cognitive load for developers? What's the first, you know, area that we wanted to focus on? And in order to do that, and this has to follow you all through, right? It's not just the onboarding part. You know, through the developer experience, how can we abstract you away from the complexity, you know, till such a time that we talk about all the observability and, you know, monitoring, et cetera, that becomes the feedback loop. So, in that context, when we have to look at, you know, how we can help the onboarding experience, that is where we're talking about the Red Hat Developer Hub. The Red Hat Developer Hub is basically an internal developer platform. So, what it does is it's very flexible, it's very extensible, and it allows everybody in the team, you know, to have a single pane of glass, and this is actually helping improve a lot of the engineering productivity, because everything that you need in order to be able to set up, you're able to do that with the best practices, with the guardrails set up for security. There are also golden paths that will guide you in terms of, you know, what to do next. So, it integrates with all the best of industry standards, and as Ashutosh had mentioned a little earlier, if you've all heard about the CNCF project called Backstage, then Developer Hub is basically Red Hats optimized, supported, and opinionated version of Backstage, okay? So, what we will do is, in order for you to get a feel of what this is about, I'll request Ramke to give us a quick demo of Developer Hub. And how many here in the audience think all the code you write for your organizations and all the code which you use are assets to your organizations? And how many of you think it's a liability for your organization? Right? Writing code is easy, okay? You don't need humans anymore to write codes. You've seen that in the last few months. But another thing is maintaining code over a period of time, okay, has become one of the most critical factors. And very few people would be lucky in order to work on projects where they get control on what programming languages they want to use, what frameworks they want to use, if they want to deploy these projects. Very few people, maybe startups or some, or some big organization trying to explore a new paradigm or a new cloud or a new offering or a service from the cloud, they get to do. But day in and day out, in most of our careers in life, we are going to use, you're going to be working with somebody else's code, okay? You're going to be working with somebody else's patents. And sometimes you'll just be working with binaries. The original development teams of those code won't exist, okay? There might be code which you're working, which was written in 1990s. So, yeah, I mean, if you're trying to modernize mainframe systems, that code could have come from 1970s and 80s also. But the thing is, these code last for a long time and they keep the businesses up and running. So, one of the critical factors is developer onboarding, okay? So, most of India is very big in the service industries. You have lots of global system integrators here. So, one of the main process is working with legacy code and trying to keep the existing business the way it is running and trying to bring a lot of innovation into the newer businesses, okay? Technology, I mean, on its own can't deliver results. You need the processes around technologies too. It's not just the tools, right? Like, for example, if somebody gives me a Formula 1 car to come from, you know, Dumlur to here, okay? It wouldn't make any sense for me, right? I just need to go from point to point B, okay? And probably it won't even start on these road. So, it is like that. So, you need the right tools, you need the right processes and also you need a lot of things around the DevSecOps is about the culture which is around these tools and projects. So, most of the companies try to differentiate their engineering efficiencies, right? What do you mean by engineering efficiencies? The developers would like to make their code run a bit more faster. It's not like you have seen a new paradigm, new framework and your code is going to increase by 30 percent or 40 percent. These small two percent, three percent changes will have a lot of impact in your business deliverables. So, this is what they're trying to do. And somebody who is in the ops side is trying to secure his deployments, secure his deployments in the sense he's going to make his pipelines more secure. He's trying to see if his end users, okay, the end points don't have weak passwords, all of those things. So, how many of you have heard of the SolarWinds issue which are happening, right? And the CDN password is admin123, okay? So, things like this, okay, it is why do these errors happen? It's because of the cognitive overload which developers and the operations within the team have. And this one can have an impact on what is going on in the delivery cycle. So, yes, there are companies with great engineering cultures but still oversights can happen like these, right? So, one of the tools is backstage. I'll just show what backstage looks like. I have already made a deployment in order to save time. So, here we have a simple project, right? So, think of Wintervening as a gaming company which we have started and we want games out here. And people participating in this game get green credits when they run this game. So, this is how most of your organizations have a source code repository within your organization. And you'll be working with various teammates. Like, here within my organization, I have various teammates and they're working on their own projects. Sometimes we work with a certain member in a certain team. Sometimes we have our own independent teams. So, but the thing is, think of yourself that you have just onboarded yourself onto this project or to this company. And you want to get started. You want to know what is going on. Where are the Git repositories? Where are the testing systems? What is the ideal developer setup for this particular project? So, how many of you have onboarded yourself into an organization and been productive the first day? The first week? The first month? Three months? Right? So, the thing is, like, when I go and talk about developer productivity with certain organizations and then the developer in that company says, I got my laptop after two and a half months, right? So, it happens, right? It happens. Many companies have tight budgets and they want to be sure that, you know, he's not going to take the, I mean, the person is not going to take the client's code and run away and sell it on the black, I mean, dark markets or like those things. And it has happened. There are quite a few, there are quite a few places where companies sue each other and get sued by each other because there has been leakage in the code and this code leakage could have happened with a third party company which is out there. So, it is always critical. How many of your laptops are encrypted? How many of your personal laptops are encrypted? Right? So, these are few of the things, right? You don't do it because it's a cognitive load, right? But you need to do it, right? Okay. One simple question. How many of you have switched off your biometrics in Aadhar? See? Only 20% of the crowd. People know they lose money with it, okay? But still, they don't do it, right? Because this is a cognitive workload. One, probably you don't know where to read about it. Second, you don't know how to do it, right? So, and to add all of these things, the amount of technology, the rate of change of technology is faster than what training programs can keep up with, okay? This given point of time, 2023, if I go and ask somebody who is doing system programming what programming languages you are using, they probably would say go or rush, okay? And if you ask someone who is in legacy code, they might say, I'm working with Java 17, Java 21. Now, I want to try a few of the Java polyglot programming languages built on the JVM along with my stack. So, these are a few of the things. So, any company can have diverse polyglot structures. So, one of the easiest ways is, for example, how developer hub enables this is it makes the onboarding process easy. It makes the coding standards within your teams easy, okay? So, this one would improve the efficiency of onboarding and the developers within your organization would have the, would have only the piece of code or only the piece of third party code which they need to have. They won't have all random pieces of software. It is true, open source has given a lot of velocity for developers in terms of not reinventing the wheel, you're just taking some open source project, putting it into your code base and you're running. It is also true that 90% of the code bases don't update their dependencies over a period of two years, which includes a lot of vulnerabilities and most of you might have also listened to the NPM fiasco which had happened. One of the developers decided to remove his package. It kind of broke Instagram, Facebook and half of like almost there was a world war at that point of time. So, yeah. So, this is how a typical organizational repository looks like and here we have a hosted instance of, we have an hosted instance of OpenShift which is our enterprise Kubernetes distribution. So, the way it has been integrated into the workflow is like say we just need to go over here and enable backstage. The product name is Red Hat developer hub. It is still in tech preview. It is going to release very soon. If you want to try it out, please send us an email address. So, this is how a typical, this is our opinionated way of how backstage should look like for customers because the kind of customers which Red Hat works with are very large enterprises. These are all the banks, all the airline companies, stock exchanges, defense organizations of various countries, space organizations of various countries. So, this is how it looks like. So, one thing over here, it kind of pools in all the resources within your organization, all the projects which are within the organization and you can get a map of what and all is going on within your organization once again, just to your code basis. So, one of the first things is like the tech radar. Most of you might have seen this. So, here you can take a look at what and all footprint is there within our organization. What are they assessing? What are the projects within our organization assessing? What are there in trial period? What kind of software components have been adopted within my organization? So, you can pool from the resources, you can pool from your whole organization. What is the whole overall structure? Like, for example, in this organization, it seems to be a front end application. Obviously, it's a gaming company. So, it's JavaScript, TypeScript heavy and most of the, maybe they're using Python for some data analysis or writing small frameworks. And if you also take a look at it, the projects which are on hold are legacy projects. So, Python 2.x has been end-of-life, Java 8 has been end-of-life, COBOL. I don't know why COBOL is still there, but in 2021, COBOL programmers are one of the highest paid programmers. Who would have thought that? Because there are legacy systems keeping the businesses running and still they have not taken. And also, in terms of the frameworks which are being adopted within your organization, you get them. And another critical thing is you get a catalog of who is running what projects within the organization. Who is running, let's say, a photo app generator? Who is running any other thing? You can also take a look at the components and what the owners of these components and see what components each and every user is using within the organization. This is another thing. And what you need to do is the other thing is the look parts. Whenever somebody is onboarded onto the project, they are invariably going to spend a lot of time searching for how to use this framework or how to use a particular API in a certain way. Documentation of your code, documentation as a service within your own organization where the senior architects or the lead engineers can write it saying that on the software components which we have written, we have also created a learning path. This is how you need to onboard yourself onto the project. How do these set up APIs within our organization work? Documentation is very critical, not just within your code basis, but how a developer, like if he's an integration engineer, what he needs to be doing, what are the various processes we follow within the organization. Once everything is documented, it reduces the cognitive load from the developer. He wouldn't go searching randomly on Stack Overflow or try to generate code from ChatGPT or any other code generation tools and put it back into the project. So these are a few of the things which would work. Generative AI is not bad, but you need to train it on the data models within your own organization. The other thing is once you do that, the senior engineers or the lead engineers within your organization can create these golden part templates. And what these golden part templates are, certain pieces of code or certain pieces of Stack which are within your organization where anybody who is going to join within that particular organization or that particular business group can get themselves onboarded onto this project. Here, there are quite a few golden parts which are available, but all of these golden parts are custom made for the developer groups within the organization. How does a typical golden part look like in the back end? So these are the templates, how this part looks like. You just need to define what are the components which version of Kubernetes is here and where you're going to deploy it. You can create templates. So these are scaffolding templates. So within your organization, you need to create a scaffolding template like this to show what are the stacks you're using, what are the frameworks, what are the build tools. Within that, what are the base repositories and the images what you're using. And also, within your organization, you can use your GitHub enterprise or any other code repository within your organization in order to deliver this. And after this, you can share this template. The template gets pulled over here. And this is how you can share with your teammates. Like, suppose somebody has joined this organization and he wants to onboard him onto this project. All he has to do is choose this project. Because in the template, it's going to get the information where it is going to get deployed. Like, for example, here, it's going to be deployed on an OpenShift instance. This one could change. See, all of these components are open source. You can use them within your own organization. You can tie them together. But then you need to do that extra effort of keeping this underlying platform up and running also. So then you have two problems. One, you have your business problem to solve. Next, you have a backstage instance to keep it updated. And after that, like, say, if you want to say, what is the namespace of that project within the infrastructure? And you can choose who is the owner who will be doing this project. And then you need to provide in which registry you want to store this thing. So as soon as you hit click and create, it would create a whole template for you. And it will create a whole catalog for you. So hopefully a few of the things are already available. I have already set up one pipeline over here. This is the overview of what happens in the project. Like, as soon as I do that, if you take a look at it, it starts a good repository and it starts populating. And any developer who gets onboarded onto your project can get access to that source code. Thanks, Ramki. And I hope you're able to appreciate the cognitive load part of it that developer hub is able to reduce. I'll tell you an interesting statistic. But before that, let's hear from you. How many productive hours of actual coding that one is able to achieve in a day? In one work, our day, let's say, eight hour day, you know, how much of productive time actual coding happens? Okay. Well, the industry average is 55 minutes. Okay. So, and the rest could be taken up at anything else. You know, the things Ramki was talking about, setting up environments, meetings, and you know, whatever else, right? And many times, you know, you may get this feeling that if I was just in that flow, you know, when I'm in that zone, you know, when I want to do some productive coding, we all get into that zone sometimes, right? When we are at our productive best, right? You want no interruptions, you want no distractions, and that's when you give, you know, your best in terms of the coding. Okay. So, how do we get in that flow state? It reminds me of, you know, and I'm very unapologetic about it. But, you know, if I have to use the term binge code, right? It reminded me of binge watching Netflix. Okay. Now, what a Netflix done from a user experience standpoint, just for some people like me who binge watch Netflix dramas on the weekend. Okay. Once one episode is over, have you noticed it automatically moves to the next one, right? It doesn't wait for you to see the titles and all that, and then you can skip recap, you can skip intro, and you know, you can get into that flow. And there are times when Netflix has to ask me, are you still there, kind of a thing, because we're just moving episode after episode, right? That binge watching. So, what if you could achieve that when you're in the right flow and the right state and the right zone, if you're able to get the right flow, if you're in that flow state. Now, that's what, you know, we're trying to talk about. And in that context, you know, you may all have heard this term of inner loop. So, basically, when we talk about inner loop, you know, whatever are the packages, libraries, whatever else you need to do to be able to, you know, develop and get with some productive code, you know, done. That's all that aspect of the inner loop, you know, the part of the developer life cycle. So, in that context, what we're trying to do is, you know, podman desktop is the area that Red Hat has been focusing on in order to be able to give an easy way for developers to be able to work in their local development environment to be able to ease the way you're developing code in your environment and, you know, the what needs to go into the production environment. So, if you're creating the container applications, for example, and, you know, being able to, you know, get them into the pods, you know, into a Kubernetes and, you know, to be able to deploy them, you know, into OpenShift and so on and so forth in as seamless a manner as possible, that's the, you know, effort that's going in in terms of making sure that you have the right plugins to your developer sandbox, to your local environment and so on. So, in order to tell us more about this and, you know, how we can, you know, work well with a podman desktop, I'll give it back to Ramqi. By default, podman runs as rootless, unprivileged containers by design, right? So, that way, what happens with the underlying containers is it doesn't get access to the underlying root, okay? And there is no room for one container having malicious code affecting other containers within the underlying platform, right? So, this is one of the ways podman started getting popular. And by default, Red Hat, in most of the OpenShift instances, we run podman by default. And another way podman has been popular, popular is one, the security aspect of podman is, it has also been, it's also a CRIO compliant container, so you can use your podman containers on any of your Kubernetes instances. And another thing is most of the new software which is being created by most of the organizations, most likely 50% of the organizations are creating container images out of their code and they're distributing their code as containers. And this has become one of the skills which everybody needs to know and needs to have in order to deliver their software to end environments. So, podman desktop has been a project which is kind of a drop in replacement for Docker desktop. Docker desktop, podman desktop is completely free. It has got a very vibrant open source community around it and there are, last month we kind of hit 700K downloads. It's an upstream open source project backed by Red Hat. There's a vibrant community of contributors who are also non-Red Hat who are contributing to the code base of podman desktop. So, I'll just show you how podman desktop looks like. So, all the sessions, the developer hub, podman, all of them have deep dive sessions later today. I'm just giving a tech preview of what podman desktop is and how it looks like. So, this is how the podman desktop looks like. It's not a complete thing. I'll just change the resolution of it. So, here, if you take a look at it, there are quite a few extensions of podman desktop. You have the Docker extension for podman desktop, then you have the kind extension Lima. And also, my friend Deshwin would be showcasing the Red Hat developer sandbox where you can connect your podman desktop to the various registries which you are working with. It's pretty simple. You go to the settings, you go to the registry and here you can set up various registries and you can configure them. And then there are various other things which are available as part of the podman desktop. How many of you know what a Kubernetes pod is? So, here, if you want to run your containers as a pod within your local system without using Kubernetes also, it can be done. All you have to do is select which pods you want to run together and start them together. So, it is rather than all of these things can form a pod of various containers working together. And this is kind of a way in which most of the software is going to be delivered. You can't solve all the use cases with Kubernetes. Some kind of workloads require certain pieces of software to be written as containers but not run in Kubernetes also. And also, in certain cases, you might be running it on a large machine within your own node. You could use that. Of course, there are Kubernetes projects like a single node cluster and various things which are coming. But this is one of the ways in which you can deliver software using containers without using Kubernetes. Another thing is you can also pull in your images from various repositories, various image repositories from like key.io or Docker Hub and various places and also pull. And you can also build your container images locally and then you can send them to the registries. So, in the next talk, we'll be showing the Red Hat developer sandbox in which you can, even if you don't know what Kubernetes is or container, you are just a developer, you can onboard your applications onto a Kubernetes complaint system like OpenShift and it is going to build the container images for you. It is going to scaffold your source code. It is going to create templates for you to make your applications containerized and then you can deploy it onto any of the certified Kubernetes distribution, not just OpenShift. So, these are a few of the tools which are available. And another tool which Praveen, my colleague, will be covering is something called OpenShift Local. Within the sandbox environment, if you want to enterprise a way of delivering your software, you can have an OpenShift instance locally onto your workstation. You can experiment it out there and then you can connect to your production environments and just ship your code and images to those environments. For example, for creating a container, it is as simple as this. You give access to the docker file wherever it is and then you can create an image name. You can give the image name to be locally or you can use like your registry. Another thing is if you want your instance to be running on a developer sandbox, you can just register for a free developer sandbox which they will be covering in the next session and then you can export the project what you have built there onto the developer sandbox. These are a few of the instances in which you can create your container images and then you can deliver the project to production. And there are quite a few desktop extensions which are available. If you have a docker extension which you had worked previously with, you can bring in that registry, you can bring in that extension to Podman desktop also. And if you don't have an extension or if you have something unique, you can always raise a GitHub issue on the project and the project maintainers and the developers and the community could contribute to it, could contribute to the code. So this is how a docker desktop is, sorry, a Podman desktop is, I beg your pardon, Sylvia. So the third thing that we want to talk about is the feedback loop which is extremely important and this is something that has been demonstrated over and over again that organizations that have shorter iterative cycles, if you are able to deliver code in shorter iterative cycles and have that feedback looping in for the remaining development, they are far, far more successful than the ones that have that one large big bang kind of an approach. And I think most organizations are moved away from that, you know, that whole waterfall and everything that we used to talk about years ago. I think that's the thing of the past. Today, everyone is talking agile, everybody is talking iterative, but what's important is that feedback loop, right? And going back to the Netflix example, I think being able to give the right recommendations based on the patterns that, you know, a viewer is, you know, typically watching what genre of, you know, viewership that they're having and, you know, taking the feedback and putting that back into the loop is one of the OTT channels that I've seen them doing very well and it's true with our, similarly with our, so here we talk about the outer loop. The outer loop is typically where, you know, your build happens, you're checking for compliance, the security checks, et cetera, and moving into production, right? So this is where you might be deploying into a Red Hat OpenShift environment. I wonder why those black patches are coming in between. So here, you know, we want to talk about the Red Hat trusted software supply chain. So when we talk about the software supply chain, you know that security cannot be bolted on. Security can never be an afterthought. Security has to happen much earlier. And how many of you use a lot of open source components in your code? You know, the fact is that there are, you know, millions of open source components that are there in the communities, they are being used quite a lot, okay? And they go through several version changes. If for some reason the component you chose to use in your code goes into production and since then it has undergone some more changes, but the version that you have, you know, has some vulnerability, it can become very risky for your production code, right? Now, what Red Hat trusted software supply chain hopes to do and achieves is to be able to give you trusted content. You know, Red Hat, you know, software components are anyway, are going to be secure, verified, et cetera, but all the components, you know, if we are able to tell you from your IDE itself, if there are any vulnerabilities, if there are any security, you know, breaches, and if we are able to give you the whole provenance in terms of, you know, where this code came from, you know, so that you can be sure that this is trusted code, that's going to be very, very important. Otherwise, today if you really look at any AI generated code or anything, you know, the biggest problem is the ethical and the legal concerns, right? Where did that content come from? Is it from a trusted source? Otherwise, you will end up, you know, kind of incorporating it into something and that could, you know, lead to problems in the later stages, right? So, right from being able to give you that whole provenance, that whole audit trail to being able to generate software builds of material, that's what, you know, trusted content and trusted software supply chain hopes to achieve. So, Ramki will give us a quick view of what that is about. So, we've been working on quite a bit of tools, like one of the tools which would show is, sorry, we do have quite a bit of tools and extensions which are built in at various places. One is at the coding phase itself. We have tools to check for vulnerabilities which are there in your existing code. This is called dependency analytics. My colleague Mohit will cover about that in detail within his session. So, if you go to the VS code extensions and this is also available for IntelliJ and other popular editors. So, if you take a look at, if you just put red hat over here, there are quite a few extensions which are available and one such extension is the dependency, the red hat dependency analytics. So, what this one does is it takes a look at your source code, see if there's any known vulnerabilities which are there within your code bases and it will also create a, it will also generate a report and share with you, okay, this is, you need to update it to this version or you need to most probably remove this particular piece of code and put it and replace it with another code if there is any license violations. So, since open source is popular, 90% of the code bases use open source within their components. There's also a high risk, especially for the enterprise developers, there's always a high risk of mixing and matching your software licenses. For example, you can't have a piece of code as a dependency within your project which uses Apache and then try to put that code within something which is under GPL. So, it will be a license violation also and especially if you are taking it to markets like North America or Europe or something which has various gates and checks in place. So, what happens with those things is you need to catch all of these problems much early. You might have heard of this term called shift lift. Try to catch the production errors within your staging environments, try to catch your staging errors within your development environments and try to catch as much as the things within the code itself. So, we've been building quite a few extensions and few of the ones which are popular are the Java extension which has got more than 20 million downloads, Ansible extension which has got around 500,000 downloads and quite a few of these extensions help you and there's also another extension which can help you connect to your production environments and if you're using OpenShift and directly control it from this environment. So, these are a few of the ways in which you can use dependency analytics and try to rebuild your programs or various activities. Another tool which we see is within the projects itself. So, what we do is this is how a typical OpenShift developer topology looks like. You'll see more and more of these images. Within this, if we take a look at our build pipeline, so every time we make a change, it is going to trigger certain actions. So, for example, it's going to get your git clone package build push and along with this, there are quite a bit of security checks which happen inside. So, the way the developer load, cognitive load is reduced is they just can focus on the code. They're good at coding. They're just making commits and changes maybe to a branch, maybe to a certain tag or a master itself. As soon as the code checks come in place, all of these checks like security scanning and also checking for any type of squatting errors or build errors which can happen. Because the vulnerabilities can occur from any of the phases, the code phase, the build phase and even in your deploy phase. So, there are various gates and checks which are in place for each and every component out there. It depends on your enterprise software contracts, what and all you want to put in place. All of these things can be triggered just by building your checking in your code. So, that way the developer need not know, they need not pick up skills around CI, what extensions they need to be using and all of those, all of those things happen automatically within the project. So, in the developer hub deep dive project and then later we have a trusted supply chain dedicated talk, I'll show you how this one can be achieved. One, by looking at reducing cognitive load with developer hub, getting you into that when you're in that flow state, making sure that you have no distractions and you're able to really code productively, that's where you have the podman desktop. And then for the feedback loop, you know, all your transitive dependencies, you know, making sure that's trusted content, the security vulnerabilities, flagged off, giving you recommendations and so on comes from the trusted software supply chain. So, the whole idea is that developer experience is not just about the tools, right? It's also about the community, it's about education, it is about events like this, it's about the blogs, articles, hands-on tutorials, videos, presentations and so much more that you will find if you go to the developer.redhat.com website and where you will find a lot of interesting things to browse through. I hope you enjoy the rest of the event today. You, you know, have several resources that you can access. You can take a screenshot of this if you like, that can actually help you get, you know, to that ideal state and we also, you can learn a lot more about what we talked about, you know, through any of these links, okay? All of these will be available to you later as well and through the various sessions today they will get reinforced and you'll get a chance to see many of them in action. With that, Ramke and I would like to thank you for your attention and over to our host for the next session. Thank you.