 Good morning and thank you for the stalwarts. You know, you have stayed here for the entire conference. Fridays are always tough. So thank you for staying here. Yeah, so my name is Arun Gupta. I am part of the open ecosystem team at Intel. I have been around open source for a while to a range of companies have taken companies. Prior to this, I was at Apple, then prior to that at Amazon, I've taken companies like that through systemic changes on what it means to bring an open source change. And open source is not just like a tool change is a people process technology culture change. All of that comes about. So I think what this presentation is basically my experiences across the board. But I've seen what works what doesn't work. The fundamental question to ask really is, is open source your culture or is open source your strategy? Because guess what? If it's only strategy, then your culture eats strategy for breakfast is super important. You could have a strategy that this is our strategy. The CEO says that. But what is the culture of the people, you know, and really the people who are executing are the ones that define the culture all the way from top all the way to the bottom and in between as well. So is if open source is not part of your culture is not going to sustain. I can I can give you countless examples of you could do open source at the French, but then it stays at the French. It never becomes critical. You are never incentivized to do open source in the company. If you're not incentivized, guess what? You're not going to work into it. Then you then you're going to have a burnout. So it's fundamentally important that open source is really tied to your core business of the company. You know, or at least it is producing revenue. It cannot be like, oh, we are doing open source because we like it. There will be more. I talked to so many teams across Intel and previous companies as well. If you want to do open source, what is in it for you? Why do you want to do this? That's my first question. But do you understand what going open source really mean? Do you understand how much extra resources that you may have to put to ensure you can grooming the community, building the community around that? So what I'm going to use is I'm going to use a framework on how an open source culture is defined. And this is sort of really the framework that I've applied across the board. So if you think about it, there's a business case part of it. And there is Ospo, that is truly the enabler of open source, you know, sort of the champions in the company, inner source, which is sort of applying that open source methodology inside the company. Internal events. Sure, external events are equally important for your external presence. But internal events are equally important. Why you need to be participant in these open source foundations where the leadership work happens. Advocacy inside the company. How can you have champions inside the company that help you build that better business case. And then chopwood carry water, which is often not valued enough, but I think is one of the critical elements here. So let's go one by one on business cases. I'll talk about my examples of when I've gone through multiple companies of how I've seen open open source work over there. So I've worked with a few companies. The business case at Red Hat is quite obvious. This is upstream first mentality. We put everything in the upstream and then we do the professional services sales supported product, very well known business model and they were the first company to hit a billion dollar mark many years ago on open source. That's pretty cool. So let's go one by one couch base is was a startup when I joined several years ago, about 300 people company. The whole model was called this is a no SQL database. So if you want to use Oracle, but if you don't want to use a relational database or Oracle or SQL server, then you could go to MongoDB, which is a document database. But then you could use couch base, which is a key value. No SQL database, different design paradigm. But the point here is they had an open core business model where the core of the product was open source and pushed out into the public. And then if you want enterprise features like RBAC, like high availability disaster recovery, you know, like scaling across beyond four to six nodes. So things like that, the moment that becoming more critical, that means now you are doing some serious business out of it. And that's when they say that is only available in the enterprise version. And that was directly tied because really the open source lowers the barrier to entry for consumers. They can start trying it out, get a feel for it. So it is very important that you have a very good developer experience because if you don't have it, then you're going to lose it. And then they will never going to come to that. So at couch base, we really used to talk about sort of the developer funnel. And in a typical marketing language, but like how do you get the outreach, make sure the funnel is big enough and then you can make them go through the route for the down. One of the biggest benefits at couch base or at any open source efforts essentially is how you build intellectual knowledge versus the intellectual property. And what I mean by that is because your project is out there in the open source, essentially what you're doing is, you know, there are people trying it out. There are people writing about what works, what doesn't work. There is Stack Overflow, there are blog posts, there are conference talks, there are forums all happening out in the open, which usually doesn't happen. And people digging into the code and telling this is a line of code that doesn't work. And I can send you a pull request that intellectual knowledge is built over a period of time as opposed to intellectual property, which is the case for a close source product. I worked at Amazon for a few years, and the whole deal over there was I was working with multiple service teams and guiding them on their open source strategy. We released Amazon Coreto, which is Amazon's distribution of open JDK, or we released Firecracker, which is the back end for AWS Lambda, which is your serverless platform. And that was all done in an open source manner and how we do it and why we do it was critical. Customer obsession, you know, Amazon wants to be the most customer obsessed company in the world, and that was sort of their primary reason. The reason we did Amazon Coreto at that point of time is because customers were asking, hey, we need something more reliable, more predictable than Oracle JDK. And hopefully less more expensive as well. So that's the reason, you know, Amazon said we are doing open JDK inside Amazon as well at Amazon scale. All AWS services are using it, might as well push a distribution out of it. Beauty of it. You know, customers need it. You're already doing it. Push it out. It's all done in upstream manner. All the changes, et cetera, all go in upstream or there allows you to and talk about tying it back to the business. AWS services, if you think about it, pick a RDS, pick EKS, pick a service. Now there is some open source angle involved in there and showing that upstream compatibility is super important. And then making sure if a service is not based on open source and having that integration with that open source services equally important. So that's where the innovation comes in. And that's where the direct business value come in because customer come and tell Amazon, hey, I'm doing this spark thing. Here's a plug in that matters to me. I need that integration as part of the service. So that start working, start putting upstream contribution into that plug in so that it is well integrated into the AWS service itself. So that no internal folks, basically no technical debt was super critical over there. I used to work at a food company. I actually mentioned that name earlier. And it is neither part of strategy nor part of culture. To the extent that you can't even say, yep, I worked at a food company. You can't even say the name publicly. Now I don't work there so I can talk about it. But really the reason we were doing open source at Apple because if you think about iPhone, Mac OS and all of these places, a lot of open source used over there, but not produced potentially. But so the idea was that this is the part of the house where we don't need to touch anything. But we were doing a lot of infrastructure. Apple was running one of the biggest Kubernetes infrastructure in the world. Not a lot of people know about it. We were using, we were still using massively a Siri pick a service that you're running. They're all using those, you know, PyTorch and TensorFlow's. They're all running on JDK and Python. So very extensive user of open source software. So the idea was we don't want to focus, you know, we don't have the engineering resources to build an internal Kubernetes. Leverage it. 95% of your work works. Put the 5% effort, put your maintainers out there and then get that process going. So that it really gives Apple the focus. The focus is really the iPhone or the MacBook or whatever product we are launching. But that gives you the focus essentially part of it. It also enabled the address the growing needs of engineering. That was a critical element of it that, hey, we are only a small team. We need to really tap into other people. How this is done. Tap into that collective wisdom of the community. And then I remember I joined February 2020. And in the following year, we were able to hire 40 people from the cloud native community. And that was all because Apple started talking about it that, hey, this is what we're doing. That's the thing that my team enabled over there. Let's talk about what we're doing because once you start talking about the technical challenges, that gets the geeks excited. And that's when they start coming to think about it. And the stock price was well, so that helped a bit too. Why do we do open source at Intel? Again, customer obsession is fundamental here. If we think about it, Intel is fundamentally a silicon company. So being a silicon company, how our customers consume our product is using these open source projects. You go to a public cloud, private cloud, network edge, wherever you go. Customers expect the open source projects to work on our silicon out of the box. So that's where we contribute to 300 plus community projects across the board. And tell us if some project that matters to you where Intel is not contributing, that should be optimized for Intel silicon, we will get in. That's sort of the primary reason because that's how we distribute our platform value through OSS. Our fundamental party line at Intel is we believe in open ecosystem. That's super critical to us because that's sort of what creates an equitable playground for everybody as opposed to one vendor really dominating that I'm going to define the rules of the game here. Let's create an equal playground, let's together co-opied to make that sustainable. And we have been in the open source community for over 20 plus years. We were the founding members of LF, Linux Foundation. We have been doing chopwood carry water, people like CROBE, who are part of the open SSF, and our tech chair, and several of us at Intel are deeply involved into the community. And this is beyond the job that we already have at Intel. That's sort of the chopwood carry water thought process. So that's sort of the element around business case part of it. Now let's talk about OSPO. So what is OSPO? OSPO is open source program office. And if you think about the primary purpose of open source program office is to really foster that culture in your organization around open source. Open source is coming in. Open source is going out. Make sure we are compliant. Make sure the culture is there. You're talking to different business units. Hey, we want to create, we want to push this out in open source. Let's do that in the most legally compliant way. That's super important element over there. We also define, you know, if we are working with the upstream communities, how do we help you understand the social dynamics? If you've always worked inside the company, how do we help you operate in that upstream community? That's the experience that the OSPO usually has. And then, of course, streamline the process. The idea is to remove the friction as people are contributing to open source. That what are the tools? You know, how long does it take by the time you have thought of an idea and you have the code ready to push it upstream? Is it required like multiple weeks of approval process or can you actually streamline it and go through a tool and say, yeah, I thought of an idea. I have a code. I can push it out. This is a beautiful guide by Linux Foundation. It talks about sort of what an OSPO functionality looks like. It talks about really different elements of OSPO, very clearly what are the benefits because it truly brings that cultural change in OSPO here. And I'll be happy to share the slides. At the bottom of the slide, there's a link which basically says, you know, where this thing is available. I'm just going to to do group to do group is a LF group, which basically talks about to do means talk openly do openly. So it provides the guidance around how do you structure your OSPO? Where should it sit and all of that? So that's sort of the next idea as well. So they have done a very extensive what they call as a OSPO deep dive. And in this what almost 40 page? Yeah, almost 30 page document. It talks about how your OSPO should be structured. So if you don't have a OSPO and you want to create an OSPO or you if you have an OSPO, it is not efficient. I would be glad to talk to you in terms of anything around your OSPO structure where it should be sitting. And I've been I've created OSPOS. I've been part of OSPOS that have set all over CTO marketing legal all over the place. And there is no one right answer. It's very, you know, with like any question the answer is it depends. So it's a very nuanced discussion, but I'm happy to do that. OSPO at Intel is part of my team. And we are part of the what we call as a software and advanced technology or the Octo group office of the CTO. So we are part of the Octo is a central organization spanning all across Intel. And that's where we provide that center of expertise for anything around open source. It's a wonderful team. It's been there for many years. Actually, we provide training and resources for that people understand what open source is. We provide common language to people. You know, when we got in, I realized, oh, we're not talking open source in the same language. What you're doing is really source open as opposed to open source. You're not embracing any of the culture or the ethos or the philosophy of open source. So we wrote an internal guide. Hey, these are the different levels of open source. You know, call out if you're doing a project. What is the level that you talk about? I think that's sort of the thing we do. We educate business leaders on why we should do open source, how we should do open source. We want that to be a very conscious and a deliberate discussion and a decision. As opposed to, oh, we just wanted to push something out over the firewall and now it's open source. It's not. Are you an OSI compliant license? No, let's start over there. First of all, I think that's the discussion that we constantly do. Let's talk a little bit about inner source. So inner source is nothing but really applying the best practices that are we have known in open source for over the years into your company. And it's a lot more comfortable because now you are inside the firewall. But think of this like when we think in terms of open source, we always say, hey, open source, my community is going to manage it. Think about that community being inside your company essentially. So really what it is, is you are saying it's a unified code base. You're talking about, you know, I'm going to do my engineering meetings in an open transparent manner. You're talking about, I'm going to do TDD. You're talking about a governance model that is there in your project. You're talking about that, hey, my project is live on my internal GitHub repo. Anybody can see the code and they can send a pull request and I will go through the process, do the review. There is a CI CD and there is a dependency, you know, that you can exactly track. So I think those are all the good things that we have seen across the board for open source, but bringing those practices and principles to inside the company. So why adopt an inner source strategy? You know, it enables discovery. That's the biggest thing that we have seen like at Apple as well. We were trying to build that inner source movement because we realize, you know, in one particular business unit at Apple. When we started doing the discovery, we realize six teams are exactly trying to solve the same problem. It's just about log ingestion. So do you really need to start from ground up over there? That's the kind of discussion we started having. And then we said, oh, you know what? Let's think about putting your code on an internal unified code base. Once you do that, then you tag it properly so that people who are coming to that inner source portal, they can look at it. Somebody is already doing log ingestion. And whatever they're doing, that solves 80% of my cases. And if I could tweak this piece here, if this is how I could scratch my itch, voila. I need three less engineers and I can actually just contribute to that project and make that project that much more valuable, driving business value for me. So that discovery is super important. That collaboration element is critical as well because now you are not trying to solve the problem all by yourself. You are actually working very well with other engineering teams. And because you are part of the same company, same team, you know, you could actually share a lot more details. You could actually start talking about, like, I remember when we did this at Amazon, we were doing Amazon Coretto. Because we were all part of the same team, as we were swapping Amazon Coretto, these folks could actually share their deep JVM logs to our team because we are all part of Amazon. That would not be possible if you're a distributed vendor. So the benefits of collaboration are there. Improve quality because, you know, as they say, you know, given 100 eyeballs, all bugs are shallow. So you're improving the quality overall as well because within your company, you're seeing those different engineering use cases. And then what you're doing is really creating that foundation on how you're going to operate and, you know, be more successful, bringing more integration across the company. So Intel has gone through this over the last few years. We have a developer platform journey that we have done. So for example, we have a unified code base where we migrated tens and thousands of repos scattered over multiple code bases. We brought them to a single unified inner source repo. Different organizations, but the code is available in a unified code base. And in that code base, what we have done is we have like a very well-defined mechanism to enable discovery. Now, we have defined a nomenclature that if you're creating a GitHub repo, this is how it's going to be called. This is a system. Is it an application? And that's the nomenclature that we follow. So people can intuitively start typing those words in our inner source repo and it enables discovery over there. On top of that, we really bring all the advantages of inner source that I talked about. Discovery, your reusability, because then you can start seeing the governance model. We're really trying to start put a structure, a consistent structure across these inner source repos. And finally, where we want to get to is the future, where we want to have that unified CI CD, where by the time, you know, somebody sends a pull request, automatically CI CD is trickle, a new build is available, and then they can use it. And the whole advantage of that is now you can start, once that is in place, you can start bringing in a lot of value over there. You can do, like you heard Eric Gruber's keynote a couple of days ago. He was talking about the only way to get there in terms of coverage is by automation. And once you have that unified CD, then you can say, I'm going to start detecting vulnerabilities. I'm going to put a CVE scanner. I'm going to give you automatic SBOM, you know, generation of it, whatever format you want. It's a single point of place where you can put that functionality and get that benefit. So I'm not going to go deeper into this, but lots of benefits of inner source that until that we have seen, make it easy to find the code across teams, the discoverability we talked about. We are looking forward to improve the corporate wide security posture because across the company, if you are on an inner source portal, then we can say here is a corporate policy, and we can just enable it a single point of time because we have a unified CI CD as well. Let's talk about internal events. So these are some of the reasons why we sponsor external OSS events. And this is not Intel specific. This is what we have seen across the industry, actually. Like when I was at Apple, when I was at Amazon, even at previous companies, these were the reasons why we're doing it. And guess what? These are the very same reasons why you would do internal events as well. In addition to all of those benefits, it really improved discovery of your efforts within the company. Like I remember we did an inner source summit at Apple. I joined February and in September-ish, we did an internal Kubernetes summit at Apple. We have a thousand-plus people from all different teams at Apple talking about their cloud-native journey. And we could talk a lot more freely, a lot more openly inside the company. Oh, this is what you're doing. I did not realize this. Let's collaborate. Let's partner. So that kind of creates that open-source culture inside your company. It really allows you to advertise within your company without going through a public job posting, hey, these are the jobs that I'm hiring for, and people start interacting with it. That's how we used to bring a lot of people over there as well. And then one of the benefits that was the last point over here is really be able to curate external speakers. So from the inner-source summit, from the Kubernetes summit, we figured out what are the talks that are being done. And we highlighted some of the speakers that, oh, this talk was really good, or this speaker needs a bit of a training, but the content is good. And we recommended them to submit talks to KubeCon. So it kind of takes a journey from there. Yeah, I talked about the Kubernetes summit, the inner-source summit. Earlier, a couple of months ago, my team ran the OpenEcosystem summit at Intel. We had almost 2,500-plus people that joined that OpenEcosystem summit. This was very widely received. We had three different geographies. We had 150-plus sessions. We had executive keynotes on the top left, what you see is Greg Lavender. He's our CTO. You can see the technical talks, all sorts of fun stuff. This went on for three days, and so much excitement around it that people want to share what they're doing, and that improves collaboration. And that brings the culture exactly. Internal hackathons are very much a part of it. Literally last month, we just finished our internal hackathon in the company where we identified a set of projects where engineering teams were facing challenges that, hey, we need to get more contributions to it. And guess what? We actually got almost 40-plus new contributors to those projects. These were external-facing projects, but we worked with internal people and really groomed them to understand what does it mean to send your first poll request? What does it mean to do a code review? So things like that, the maintainers have to be ready. But then, essentially, what you're getting is quality inputs. And there are, again, best-known methods on how you handle a hackathon, essentially. So those are the things. Open source foundations, again, if your company is part of a foundation or not part of a foundation, you're hopefully following the activities that are happening over there. And I'm not saying foundations is the means to be all and end all. But really, they really help advance open ecosystems if you think about it. KubeCon, three, four weeks ago, there were 10,000-plus people over there. I was run by CNCF, the Cloud Native Computing Foundation. So there's a lot of value that is driving out of these foundations. And really, what that they do is they help you define and maintain top-end technology and standards. That's where the meeting of the minds happened. This is run by Linux Foundation. So people come over here, they talk about, and I honestly, I go to a conference, either I'm speaking or for the hallway truck. I've never attended a session for a very long time, actually, because the hallway track is so much more interesting and entertaining and valuable. It really gives you that impact to me, honestly. And from the foundation perspective, it also makes it a lot more vendor-agnostic, because now you have a neutral IP, copyright, et cetera, all those benefits that you can get, essentially. Some of the foundations that we are part of, you know, I am on the Cloud Native Computing Foundation Governing Board, also the Governing Board Chair, also on the OpenSSF Governing Board. I'm the alternate on the Linux Foundation. Intel is part of 700-plus standards and foundations across the board, because we believe that truly drives OpenEcosystem, and that's sort of the culture that we have at Intel as well. Another point that is super important is, now Ospo is part of OpenEcosystem team at Intel, but all the business units have their needs. So how do we make sure that these business units, as they're building a case, how do we make sure that their case is credible? How do we make sure that they're putting in the relevant information in there? And that's where these advocates and champions, they come in very handy, because now in each business unit, there is an advocate and a champion who understands this is what Ospo's expectation is. They help them build that business case, and by the time it comes to Ospo, we have seen the approval rate of projects jump significantly once we started having those advocates and champions. We have these open source advisory council inside Intel, where we talk to all the BUs, help them understand the OSS policies, and this is a model that I've seen working at other places as well to be very effective to. This is the then proverb. You know, it says, essentially, before enlightenment, chalk would carry water. After enlightenment, chalk would carry water. You have to do that. This is how you make food. This is how you drink water. You need those two things to survive. So oftentimes people think about what chalk would carry water mean is this work is not really required. No, but that is really fundamental to the survival of the project. The glorious work is, oh, there's a brand new feature I created, and here you go. Voila. I'm the owner of that feature. But all of this work, this is the non-glorified work. Who's going to review the code? Who's going to onboard new mentors? Who's going to review the proposals? Who's going to write the proposals? Who's going to put comments on the proposals? You know, there is a SIG that is happening, a special interest group, who's going to lead that SIG? Who's going to get time to lead that SIG? And if they're leading that SIG, what's in it for them? And how are they going to be incentivized at their workplace? Does the workplace even honor it, or are they doing it in their fun time or free time? So all of those things, reviewing conference talks. KubeCon had what, 1,000 plus submissions? There's a program committee that is reviewing those talks. And that program committee are people who are full-time employed. So that's, again, a chalk would carry water work. So a lot of effort goes in there. Again, this is something that has been very much a part of the DNA. At Intel, lots of folks contribute to a wide variety of ways at different technical leadership advisory council roles. Kube is sitting in the room. He's a tech chair. If you want to talk to him, what does chalk would carry water mean? He's truly the poster for that. So we're going to get back to this here again. You really want to bring, if you want to build that open source culture, these are some of the elements that I've seen work. And I've seen if these elements are not there, it would not work. And if these elements are there, they definitely enable that, improve the chance of success over there. Last slide here. If you want to learn anything about that we are doing at Intel, the left side is a QR code for open.intel.com. Where we talk publicly about our efforts. And on the right side is our Twitter handle. If you want to talk to us. And this is a slide and that's a wrap. I think we're right about time here. Oh, we have actually a few minutes. So any questions that you have? I think it's getting a mic for you. Thank you. Great presentation. I really like what you did in terms of the presenting, the overview of hospital roles and open source. Given that Intel is such a big operation and the foundation of infrastructure in the world. How do you choose the open source projects that you want to support? Clearly, there's millions of projects out there. What's your evaluation process? And how do you choose that? And how do you contribute? Do you have resources in place that does that every day? Yeah. And I have a second question for that. Yeah. No, I mean, I think I said in the beginning, the reason we contribute to open source, because our customers get the product value through that. And our primary product is silicon. So whether you are in AWS or GCP or Azure or wherever, private data center or Edge, if you are the way you are using our product is by having that platform run, having that open source project run on our platform. So we contribute to those projects and then make sure that those projects are fully optimized. And oftentimes we release a new instruction set. So make sure that the features are enabled into those open source projects ahead of time. So Colonel, if it's Colonel, if you think about it, we have been the top corporate contributor over there for 15 plus years. And the reason we continue to contribute there heavily is because as new instruction sets are coming in and these chips take a few years to build on and the kernel community is pretty complex as well. So to make sure that we are doing this in the most vendor agnostic way and be able to navigate that social fabric takes a while. That means you have dedicated resources in-house that are just specifically focused on the Linux kernel, for instance. Correct. All of this work that I'm talking about, contributions to these external projects are all done inside Intel. Wow. Great. And I'm looking at your future. You showed that slide where you're talking about the, I guess the regulations are coming from the federal government where they're talking about S-bombs and that's the station of S-bombs. Can you describe what are your challenges you're seeing with the whole aspect of automation? You're talking about the CI CD process and you generate an S-bomb and you do S-stations, get the artifacts. How do you see that on the RMF process? Well, that's the future right now, right? So that's what I said. That's exactly what we are working on today. We are working, there's a U.S. government mandate starting June, like next month. Essentially we have to be compliant with that. And that is not retroactive, but that is for new projects. So that's something that we are definitely working on. Great. I participate in the SISA working groups that have the discussions every day. And I'm curious to know if you have anybody that does that. Well, Grobe is the tech chair. So yeah, he is the man. That's it. Please talk to him. Yeah. All right. Thank you. Hi there. I'm Courtney Robertson and at GoDaddy and a lot of our open source work at GoDaddy ultimately is in the light of Web Dev. And tooling for hosting and things of that nature. We had an Ospo department had before I arrived there. Reorg's incorporations happen. People move on. I'm here this week because I'm interested in helping relaunch said Ospo and I would be new to looking at things from this perspective. My background is in professionally trained education. So I am looking at this from a dev ed dev rel all of those perspectives. Do you have slides available and or any resources that show kind of examples of reports to give to C-suite sort of folks advocating. So a good starting point. Yeah, this would be a great one. Actually, if you take a look at this link, it talks about deep dive into Ospo's. It kind of explains what the Ospo structure is where the Ospo needs to be located. What makes sense. It's a really deep dive document. It really talks about what are the pros and the cons of where it needs to be located. All of that. So that's one part of Ospo. The other one that we're talking about was dev rel. And usually Ospo and dev rel is not one in the same function because and dev rel is a lot bigger term. Right. Are you doing dev rel within the company outside the company? Yes. So I think. Yes, all of that. I am the dev rel right now. Perfect. Yeah. That's awesome. Thank you. Thank you. Great talk. Any recommendations for how to encourage folks to chop wood and carry water? Yeah, I think the only way I have seen this working is, you know, Well, there are people like probe who just do it because they, they fundamentally believe in it. But really. Being able to incentivize them at work. Like I remember back cost 15, 20 years ago. We were given 20% of our time at Sun Microsystems when I was working at there. We were given 20% of our time that we were taking the company to a cultural change. And 20% of the time was go answer the questions on the forums. Go make sure you write the blog about it. So that was 20% of the time. We were actually given over there. And that's how we saw it scale. Like my executive had what almost 2000 people in the org. All 2000 people. In your annual focal, you have to say, what did you do towards your 20% and that's definitely a scalable model. But I think something to be sensitive about is open source projects have so much to be done. So you really want to strike that balance. How much of chocolate carry water you want to do? How much, you know. You don't want to be at a point where you're burnt out exactly that. Okay, what I can handle this. Neither my work nor chocolate carry water. And one thing that I've seen CNCF really being good at is they recognize these individuals. We do this chocolate carry water annual award. So Patrick only, for example, he works at Intel. And he was recognized as a chocolate carry water. Award at coupon Detroit. So I think those are simple things that goes a long way. Actually recognizing incentivizing and just giving a simple five. You know, I mean, those simple things go a long way. Yeah. You mentioned that you have to tie your. Your strategy and and to your business. You said in a few slides. Yeah. I think when you look at large companies like Intel or Google, I think they have the financial resources and the will to do it. Right. I mean, medium sized companies, you know, how do you, how do you make your management believe that, you know, how do you tie this? Well, I mean, couch base was a three or people couch base. Well, I mean couch base was a 300 people company. When I joined it was a startup company. A lot of pressure from the VCs to focus on corporate quarter by quarter. What are you selling? What are you like? How much money are you making? When are you going to go IPO? I mean, finally went to IPO after I left. But so there was a lot of pressure over there, but I think that's where having an executive who believes in the fundamental nature of it that open source is fundamental is critical. And I've, I've been talking to a lot of executives from the sales and marketing, they're thinking is very short term. What is my quarter going to give me? If you are going to an event, how are you going to give me a product? It doesn't work that way. You know, I mean, like when we, the changes that we started making at Amazon three years ago are showing the results now. And that's my guidance to the team as well, that whatever you're doing right now, they don't think about it in a short term. It's a long play. I think that's a critical behavior trait. I think we should expect. It's very fundamental to set the expectation. And that's why my strong recommendation to be not part of the marketing team, you know, Ospo or DevRel functionality, they don't get it. They're like, and for the right reason, because they're very focused on the sale, the nurture campaign. How do you go through the funnel, the pipeline? Because they're very, and they both have very complimentary roles. I don't mean to say in a negative sense, but they have very complimentary roles. Because end of the day, DevRel plays a role where you can actually enable that big, that funnel bigger for them. And I remember when we were at coach base, we were trying to get into a new geography. So what we did is we worked with the marketing team hand in hand that, okay, we want to get into that geography nine months out. So over the next six months, essentially, I used to run the DevRel team over there. I worked with our evangelist. Let's identify. Hey, we have a Java SDK. We have a .NET SDK. We picked up the SDKs. Let's identify those meetup groups over the next six months. Let's schedule talks at those meetup groups. Let's socialize the community so that they understand a little bit. And then we were basically priming the pump for marketing to get into that territory, as they call it. And now you make the sale. Because if you walk in cold with trying to make a sale, it's going to be very difficult. I remember many years ago, I walked into a customer account in Brazil. I walked in. The guy was taking me in. Hey, Aaron, we need to sell our application server. We'll talk. We'll find out what's going on. I walked in. Three people sitting in the room. They just shook my hand. They said, thank you very much for your blogs. Just write these two blogs, and we will buy the application server. So my point is DevRel and they have to work hand in hand, but don't have DevRel focused on immediate quarter. That's not going to work. That's the wrong approach. I think we're just over time. So we'll take a last question, maybe. How to maybe take all these guidelines and put it into like a small tiny company that maybe would be me as a OSP. But my real question is, what are the risks? Can you see companies getting hot by publishing their code and publishing parts of their tooling and whatever? And I think that's where you have to ask the fundamental question, why do you want to go open source? A lot of the teams that come to us, they say, hey, we want to go open source. My first question is why? I love open source. I've made my career out of this, but my first question is why do you want to go open source? What's in it for you? You want partners to collaborate? Can you not give them source code out of the line? Or do they want you to be open source? So understanding that why is super important. And I've talked to, I've consulted with companies, there are five people company, ten people company, and they ask me the question, oh, do I need to build an Ospo now? Ten people company, you don't really need an Ospo. You know, you probably the Ospo and the DevRel and the sales and the BizDev as well. So I think that's where you have to figure out the why is super important. Let's not confuse, you know, as at Intel we say, let's not confuse activities with progress, right? So think about what are you trying to do and why you're trying to do and what is the outcome of it, which is super important. All right, thank you everybody.