 So hi, my name's Elon, one of the scale co-founders. If you have not met you yet, please come by and say hello. There's lots of other folks wearing jerseys like this that have been part of Scale for hard to believe almost 21 calendar years, but 20 years of getting together in venues to celebrate open source. So thank you, and so Scale is made in large part possible both by of course all of you coming out here to celebrate with us and inviting your friends and your family and your kids who are joining over at the Scale Kids track just across the way. But it's also made possible by a ton of volunteers. As I said, most of them are wearing jerseys like this or if they're on our tech team, they're wearing the Wi-Fi password, which is penguins, not Pasadena. Again, it is penguins. I did not expect all of you all to remember Wi-Fi passwords from three years ago, but apparently you do, and then you tell me it doesn't work and I, it's again penguins. But yeah, so please take a moment to thank them for helping make Scale possible. Both now with applause, but also just in the hall if you see them, you know, I don't know, pat them on the back, shake their hand, give them a high five or a socially distant, you know, I don't know, elbow bump or fist bump or something that you are more comfortable with. But we're excited to have you all here again. I know it's, I know in LA rain is weird and people don't like to get in cars when that happens, but I'm glad that you braved it and came on out. We've got a great keynote planned for today. We've got Arun Gupta's joining us. And there's, you know, we talk about Scale being around for 20 years. Yesterday we celebrated open source, the OSI being around for 25 years as part of their birthday celebration. I think Nix is here celebrating their 10th anniversary as a project. There's a lot of anniversaries in the open source world happening right now. It's hard to believe we've been doing a lot of this stuff for a quarter of a century or longer, especially, you know, for those of us that started Scale, most of us were in our freshman or sophomore year of college when that happened. So it's, you know, this is, it's a big deal that, you know, the conference can drink now and at least in the States. But there's, you know, there's an opportunity here for us to learn from leaders in the open source world about things that they've done, things that they've seen so that we take advantage of their lessons as the next generation comes and starts new projects, new foundations, new things. We don't always know the why of how things got, why things got to be how they are, why we made the decisions that we've made, whether it's around culture or around governance or around technical details. It's important that we don't forget that and a lot of it's not written down. So it's exciting to bring folks from the earlier days of open source out to come tell us. And there's not a lot of folks that have been involved in the open source world as long as Arun. He was, you know, part of the Java community at Sun early on as they were open sourcing and opening up. He's been at Intel, he's been with the CNCF, he's been with a lot of organizations. So we thought it would be a good opportunity to learn from him about, you know, culture and building welcoming communities. And hopefully we can take those and apply those to our new communities as they're growing here for the next 25, 30, 50, 100 years of open source. So with that, I'd like to invite Arun to come join me on stage and he'll share his experiences with us. Thank you Arun. Thank you. All right, awesome, good morning. Rain in California, we are not used to it but it will take it. We have been in drought for, I don't know, how many 17, 18 years I guess. But it will take it, so thank you. And saying that scale started when we were freshmen, I was before that, that shows our age. We'll take it again. Thank you, thank you very much. My name is Arun, I work for Intel. I believe the best way to solve world's toughest problems is through open collaboration. Why? Open gives you diversity. Open gives you inclusion. Open gives you transparency. Open gives you effective problem solving. Open gives you that trust in the solution. It is so important, pick any problem. COVID happened, how did we solve that problem? By all pooling in together. I was reading a study about something that Intel did with UPEN and we were talking about, hey, let's build that machine learning model by which we can do lung nodule deduction. And initially the data was only created out of California, Massachusetts, and New York, but that model was to be deployed around the world. How do you expect that model to work without that diversity, without that inclusion, without bringing everybody into that solution? So there is a real depth and power in building that open culture. So I've worked through a few companies over my career building transformative changes over there to bring that open source culture and those are the lessons I intend to share today. All right, a question. How many people think open source is your company's strategy? Okay. How many people think open source is the culture in your company? Yeah, about five or seven people in each case. Guess what? If it's not the culture, culture eats strategy for breakfast. It is super important that open source is the culture. No matter what the strategy is, you define this where we wanna get to in three, five years, but unless it's the culture, because that's how people operate. That's how people behave. No matter what the strategy is, is the culture is the explicit force that you have to bring down to the engineer level, everybody, that's what defines the culture. The other key part that I wanna call out is that after having worked through multiple companies, open source in an enterprise very clearly needs to be tied to the business case of the company, which is the crux of the company. You know, it cannot happen on, I mean, it can happen on fringes, but it stays on fringes. It doesn't become critical to the company. So open source really need to be tied to the crux of the company, otherwise it is not sustainable. So in terms of the open source culture, here are different elements that I intend to talk about. And I'll talk about the business case, the relevance of open source program offices, inner source, internal events, open source foundations, advocacy, and CW Power 2. We'll wait for that acronym a little bit later. So let's talk about the business case element. These are some of the companies that I've worked at. And what I'll do is I'll flash through what was the business case at those companies. And yes, I did work at Fruit Company, I can't take the name of it yet. So Couchbase was, I mean, where the open source seed got into me was really at Sun Microsystems, because that's where we took the entire company through the change of bringing that, you know, close source to open source element. Worked at Red Hat, but Red Hat model everybody understands, but now come to Couchbase. Couchbase was a small company when I joined about 200 people, a no SQL database company. They had an open core with the enterprise product around it, very typical classical model, you know, on how you commercialize open source. You have an open product, you know, which is limited. You can run one, two nodes, whatever, but the moment you wanna go to enterprise scale, you want high availability, disaster recovery, those kind of features, those are only available in the enterprise version. One of the biggest advantages of there was how you build intellectual knowledge by being open versus intellectual property. That intellectual knowledge is where developers are really looking at the open core part of the product. That's where they're writing tutorials, blogs, videos, you know, they're building that intellectual knowledge which is generally not available if the project is IP protected. I worked for a few years at Amazon and these are some of the reasons, you know, I gave a talk on why Amazon loves open source, some of the reasons why Amazon contributes to open source. Customer obsession is their first leadership principle and they always talk about that, hey, let's make open source pragmatic for an OSS project because the customers want open source to be pragmatic. Nobody takes, downloads my SQL from the internet and say, I'm gonna run it in production. That's not their core competency. They say, you know what, I'm just gonna use RDS and that's my service. Nobody downloads Kubernetes from GitHub and say, I'm gonna run it in production. They say, hey, I'm gonna go to EKS and run it. So that's sort of the customer obsession element of it. Innovation is a key element because how other AWS services could be integrated, you know, that's why a lot of the AWS contributions go back to open source. And of course, the big one really here is the reduced maintenance overhead. They don't want a technical debt to be inside the company. That's why anything you do, you push it out the upstream and then the community manages it. Now, I worked at the fruit company for a couple of years as well and these are the reasons why they would focus on contributing to upstream. Well, the first and first, the most important part is really doing that community-powered innovation. You know, if you pick something like Kubernetes, Kubernetes is what, 4,000 companies, 50,000 plus developers. And if it serves 80% of your need, or 90% of the need, you don't need to create a new Kubernetes. So you just tap into that collective power, you put your PRs and fixes and maintainers into the project, and that really allows you to focus on what your core competency is. It also allows you to enable the growing needs of engineering. You know, engineering demands are growing, they're scaling, there are similar companies that are doing that kind of work, so you just kind of continue to work with it. And one of the big parts for the fruit company really was, how do you attain and retain the best talent in the industry? If you want to run Kubernetes at scale, this is how you do it. Now, I was lucky enough to be behind opensource.amazon.com, opensource.fruitcompany.com. Both of those websites were built from my team. And now I work at Intel, and my team also manages open.intel.com. Now, why we contribute to open source? Our customers, they consume our platform through open source frameworks. Pick a framework, PyTorch, TensorFlow, OpenJDK, Kubernetes, LLVM, GCC. Pick any open source project, Kafka, Hadoop, Spark, pick any open source project. They like to run it on an Intel platform, whether it's running on AWS, Microsoft, or GCP. And so we make sure that those open source platforms are optimized for Intel platform. Our product portfolio is, again, built on that ubiquitous horizontal platform, as opposed on a vertical platform, so that promotes innovation. And a big part for us, as I was talking about CW Power 2, that's chopwood carry water. I'll talk about that element a little bit later, but we have been contributing to open source for over 20 years. Intel is a top corporate contributor to Linux for 15 plus years, top 10 contributors to Kubernetes and OpenJDK. So those are the projects we continue to push because our customers demand us from that. Let's switch gears. Let's talk about open source program office. What role that plays in your company's open source culture? Well, first of all, what is an open source program office? Of the people that are working, of the people in the room, how many of you have an open source program office in your company? About eight of us. Okay. I believe if you want to change that open source culture in your company, setting up and establishing an open source program office is fundamental. It could be one people, it could be two people, start small, let it grow from there. Because why? Well, because the whole role of OSPO or open source program office is to foster an open source culture in an organization. When I joined the fruit company, there was no OSPO. I set up that OSPO. Like, hey, let's bring everybody together. It's a central place where you can bring your open source concerns. It really defined how you're gonna consume and how you're gonna produce open source. You work with the legal team, you work with the marketing team, you work with the PR team, you work with the engineering team. So all of that discussion is super important. Now you also help out with the open source compliance reviews and there are different structures of OSPOS. Legal could be part of it, legal could be a sister team, all different ways. But really the biggest impact that OSPO creates is it gives you a guidance on how do you work with the upstream communities? And one of the major impacts that I've seen at different OSPOS that I've been running is how do we streamline the process? You wanna contribute to upstream? How do we make sure we identify the bottlenecks in that process and try to streamline it? Either simplify the process or introduce a tool that makes it a lot easier for you to contribute to open source. Now this is a beautiful definition from Linux Foundation. For those who don't know, Linux Foundation is a major open source foundation where most of the heavy open source projects sit and they have a to-do group that talks about OSPOS. So this is a guide that was created by them. It's a graphic which talks about what is an OSPO? And if I were to read, for example, it says, OSPO is designed to be the center of competency for an organization's open source operations and structure. That's sort of the definition of OSPO. So once you have that formal body, then the open source culture starts becoming, because that becomes sort of the central point, essentially. It also talks about why form an OSPO? Where could the OSPO sit? What could the structure look like? You know, what are the maturity models? So if you are starting to begin with, what role does the OSPO play? It's a beautiful structure in there in terms of a maturity model. Dig a little bit deeper into this. It talks about a deep dive into open source program offices. If you're interested in setting up an OSPO, it talks full detail. Where should it sit? What the maturity model would look like? How many people? What roles are essential? How do you get started? All of that. Now within Intel, of course, we have an OSPO and I joined Intel less than a year ago, but we have had OSPO for a very long time. And as part of Intel, the OSPO sits of a horizontal software group as part of the CTO team. So that's where it sits. Now, within Intel again, just like usual OSPO is a center of expertise for open source operations for us. Like there are multiple BU's within Intel and they want to consume and produce open source. So we provide the training and the benefit of how you do that in the right way. How do you make, what are the community expectations and norms so that you're able to meet that? What licenses to choose? So we talk about all of these things. And then we also work with business leaders on the value of open source. We help them make strategic decisions. Should you open source it? Should you make it monetize it? How do you handle those discussions? So those are constant discussions that are happening within the company. And we also influence and adjust other policies. Oh, we have to do make sure when the code is pushed out is secure. But that is controlled by a different adjourning team. So we work with them. So I think it's a very wide network that we very wide influence that we create within the company. Let's switch gears. Let's talk about inner source a little bit. So what is inner source? Inner source is basically apply usual open source principles and best practices to close source software. And that's what inner source is primarily about. And when you think about open source, you usually think about, yeah, there's a unified code base. There's a visibility. There's a transparency in that code base. You can see what is available where. You can send a pull request. Somebody will merge it. There's an issue tracker. There's a GitOps methodology. You can do CI CD in that. And once you discover that you don't need to start from ground up, you discover there is a 80% need mat so you just contribute. So pretty much the same open source principles, but that could be now applied within the context of your enterprise. So that's sort of the concept of inner source. Now, why adopt an inner source strategy? And some of this narrative I've taken from docs.gitlab.com. So real shout out to them. They're one of the best documentations of what inner source is. So let's talk about it. The first is discovery. You know, by maximizing the visibility of software across the company, you are enabling people to see what's happening. You know, hey, because I need to create something new, but without discovering it, without knowing what exists, how will I know that I can build on top of it? What is the governance model? You know, can I send a pull request? How many other teams inside the company are really using that project? So that discovery element is super important. The second is increased collaboration. Once you have the discovery enabled, what that means is the code is read only at least for all of the company. Now, I'm not saying you put every repo in inner source. You don't have to. And as a matter of fact, at the fruit company, we had inner source repos and non-inner source repos. And at Intel, we are on the other end of the spectrum. We have a lot more inner source and a little bit to code, which is not inner source, which is perfectly fine. So it depends what your business need is. But really, once you have the availability, once you have the discovery done, then that's what improves collaboration, because then you are really digging deep into the code. Then you are saying, this is the exact feature I need. And not just filing a pull request or an issue, you are actually filing a pull request with the feature development itself. And that really improves. This amplifies the productivity of the project maintainers. Linus once said that every contribution that is made to Linux, even if it's a typo, a bug fix, makes Linux kernel that much better. And that's the same philosophy now you're applying to inside the company as well. The third part that is important is the improved quality. The open source projects that survive are the ones that are clearly healthy. And by healthy, what you mean is, is it a multi BU governance? Or is it like just one maintainer that is maintaining the project in a hobby? What is the governance model? Is there a contribution ladder? That means, maybe initially I'm a user of a project, then I become a contributor to the project. Now I wanna be a maintainer of the project. And if my business unit, if my team is gonna strategically rely upon the project, I may not want to rely unless I am a maintainer on the project. Because that allows me to influence the direction of the project. So, but overall, it helps you with the improved quality because now, if I'm a maintainer, then I'm gonna be testing that project in my use case as well. So the overall quality goes up. And but not the least is really the inner source builds the foundation, which we'll discuss in a moment. And now, at Intel, what we call as one source, where all the source code is unable. Now, it gives you the ability to have improved security posture, much more collaborative, one CI, where not everybody has to create their own CI CD. And all of that is just amazingly wonderful benefits of inner source. So let me walk you through on how we have adopted similar philosophy at Intel and what benefits it has shown. So far, what we have been able to do, we have been able to migrate thousands of repos from dozens of source code control system into one. And in that one repo, multiple organizations, but those are deliberate organizations as opposed to accidental organizations. Now, it's a single source code control. So you know they have different governance model. So we have adopted a naming scheme over there. Is it an application? Is it architecture? Is it a hardware? Is it a software? So immediately, you can start filtering those 100,000 GitHub repos. What are you looking for? And then the information starts bubbling up. So that's a very critical element. So that's the foundation that I was talking about that is required for one source or inner source. Now, once the one source foundation is done, that's when the inner source principles can be applied more rigorously. So now you have a single source code control system. Discovery becomes a lot better. Reusability accordingly goes up as well because now you're able to discover, you identify what the gaps are, what are your opportunities, and what does it take for you to submit that pull request and then the reusability goes better. Collaboration goes better because now you can truly talk about multi or governance or multi BU governance that, okay, it's not just two people who are maintaining that project but I can actually put a maintainer over there. So the maintainability, the security, the entire posture of the project goes that much better. So that's where we are today. And what we are looking for in the future is really that improved security posture that I was talking about. We wanna be able to build whenever you want. We have one CI CD so allows you to build, scan for vulnerabilities, test. There's a mandate by federal government on SBOM so that would allow us to roll out SBOM across all of these inner source projects, code coverage, what kind of artifact generation needs to happen. So that's really another unified CI CD that we are looking at it. And eventually, that's where we wanna get to. That's really the beginning, I would say, of the Intel developer platform within the company. So the benefits of inner source, as I was talking about is improved collaboration, discovery, reusability, joint maintainership are just immense and we are already seeing those benefits within Intel. I cannot talk through most of these points. So make it easy to find and reuse code across teams on what we see benefits of inner source at Intel. The most important part is it remove silos. Nobody's working in their own unit because you have a name scheme. The discoverability is a lot easier by default globally to all software engineers so you can start looking at the code. We have a governance model, multiple organizations. They have different governance model on who can do what kind of a thing. And the consistent naming conventions is what I talked about which really allows that improved discoverability. We are also very excited about the improved corporate wide security posture that here is a security posture because it's one source, one CI CD, one source. We can actually roll it out accordingly at a central place. And then the thing that we're also looking at is how do we improve repository and project health? So how do we generate like a dashboard where we can send automatic email that, hey, you know what? I don't know how many of you are familiar with OpenSSF but that's open source security foundation and they have created this thing called as OpenSSF scorecards. So we are thinking about, hey, can we inject those OpenSSF scorecards and send automatic reports that, oh, by the way, here is the OpenSSF scorecard and let's improve your security posture and here are the recommendations. All right, the next point, let's talk about that. Now, these are some of the benefits for external OSS events if you think about it, right? You know, these are some of the reasons why we contribute to external OSS events. It's a very visible presence. So if you see the lanyard, you know, right next to your heart, that's us. So OpenNTL, that's my team. It's a visible presence. It allows people to connect with the brand and it's a hallway track or the most meaningful and fundamental way. And I go to conferences, either I'm giving a talk or I'm in the hallway talking to all the people that I know, honestly. I was walking through the expo floor yesterday and every other booth, I was stopping realising, oh man, yeah, we met like 15 years ago, I've known you for 20 years. The vibe in the expo floor is just amazing. And then you reconnect those bonds and then you identify those collaboration opportunities. Participate, you know, oftentimes, like if you go to say LF member summit, which happens twice a year or open source community summit, that happens again twice a year as well. There are community leaders things that happen over there. For example, last year in November, we were in Tahoe in middle of a storm. There was a LF member summit, but we have all day open SSF governing board meeting, a strategy meeting. So all the members could come and have that discussion. Expand industry connections. There are usually diversity events at these. So for example, next month, next month we are going to Kubecon and there's gonna be a diversity luncheon that we're gonna be part of. We tend to hire people, a lot of people, you know, most of our hiring is like, either we have known the person for a very long time or identify a new candidate and talk to them at that time. But what do we do there? Speakers, booths, demos, usual stuff, right? Now you may think this is all for external events only, but this is equally applicable for your internal events as well. Just that the scope is inside your company. So let me actually go back to this slide and let me talk you through this slide from a different perspective, internal OSS events. So when you're doing an internal OSS event, it becomes a visible presence for your engineering team. It becomes a visible presence of what are, what cool things that your team is doing, what positions you are hiring for, what are the tough engineering problems, challenges you are solving. I start highlighting those elements. You know, it builds deeper collaboration, there are hallway tracks, so all of that comes along with it as well. So exact same set of benefits, but for internal events as well. Now, what are the benefits? So let's go back here. Improved discovery of efforts within the company. It again breaks down those silos. Inner source, internal events, they all bring that element. And I'll talk about some of the internal events that I've done and how amazingly successful they have been. They enable collaboration. They say, oh, I didn't realize you were working on this. I didn't realize you were working on this. Left hand, meet the right hand. It really allows you to create that interpersonal relationship because once you start knowing the engineering teams are working, the leaders talk as well, and then the one source is born, and then you can do a lot more collaboration over there. It also becomes an internal promotion of your talent, positions that you're hiring for. You can start recruiting over there. And then the way we look at it also is, how do we curate external speakers? You know, you have spoken often times. People are not very comfortable speaking in front of an audience. So with internal events, now most of the things are virtual, but it gives them an opportunity to practice their skill. We provide mentoring, we provide coaching, and we help them with the slides, help them with the storytelling. So you can do that in a somewhat of a safe environment because this is all internal. And once you provide that safe environment, once you enable that safe environment, they feel a lot more confident and comfortable going in a public setting. And then you continue work with them. So that really helps you curate those external speakers. So some of the internal events that I've done over the last few years, at the fruit company, we ran a Kubernetes summit. There's about 2,000 people that showed up doing all sorts of cloud native things across the company. This team is doing, that team is doing, and then we started kind of interacting with each other. Enabled a lot of conversations around that. At the fruit company, we also ran an inner-source summit. The attendance was not that big, but very curated audience because these people are truly, truly getting into the nuts and the bolts of inner-source. How do we enable it? How do we make it successful? How do we drive inner-source forward? How do I do a maintainer workshop in an inner-source project? And more recently, I think a couple of weeks ago, we ran an open ecosystem summit, which is sort of my team. So we ran an open ecosystem summit at Intel. And what I'm showing you is a screenshot of that was circulated across the entire company when we ran the open ecosystem summit. We had executive keynotes over there. We had executive panels over there. We had 120 plus talks, 50 plus project videos were submitted. This event was done in three GOs. So the inclusion was a big part of it. And what I was excited about particularly is that, yes, the open ecosystem team that sits as part of the CTO office ran it, but the diversity across BUs was just outstanding. I was really pleased with the diversity element over there because we paid conscious attention to that part of it. And this was done in the scrappiest possible way. Submit the talks and then from those talks is what the tracks evolved essentially. This was the first version of V1.0. We definitely have a lot of lessons and learnings. And we're gonna make it better next time. There's already a commitment for version 2.0, but that's gonna be next year. It does take a lot of drain on your team to run an event like this. And we literally had a five week runway for this to deliver successfully. But a lot of people came together and we delivered it. And the kind of feedback that we're getting is just amazing. And again, I'm gonna go back to that whole element of discovery, collaboration, enablement. I didn't realize this team is working on this. I didn't realize, so you start creating this. And then those 50 project videos and those 120 technical talks, those are all recorded. Sorry? Yeah. Yeah, so those are all recorded. Well, Open Intel is the public website. This was all an internal summit though. Yeah. All of those project videos, et cetera, are recorded. So from there, we're gonna start curating on what could go on Open Intel. Now, attached to these events are also internal hackathons. So inner source, internal events, internal hackathons, all of these are really critical elements on how you enable collaboration, how you build that. And really, internal hackathons, the reason they are super beneficial is because it's where you can run things like maintainer workshop. Let me tell you how to be a maintainer on a big project. So for example, you could fork a big project like say Kubernetes and walk them through. Let me guide you the steps on what it requires to be a maintainer and continue educating them and nurturing them to be on that path. May not happen today, but at least in six months, they are on that path to become a maintainer. Really allows you to tap into that community-powered innovation, everybody is over there. You know, the way we have organized it is before the actual hackathon, we will have a readiness workshop where people will show up, we set up their environment, and then on the day of, actually even before that, let's say 15 projects are participating, we'll create a tag on the internal repos that, hey, good first issue. Everybody identify the good first issue that you wanna get solved from your project and you tag it and then we create a dashboard and then on the day of the hackathon, people just go to the dashboard, they say, oh, I know Python and I know machine learning. Show me all the projects that are related to and show me the good first issues in that. Then you kinda start drilling it down based upon your expertise and then it kinda makes some matchmaker role. Now, this project needs that help, boom, connect. And then you start allowing, then you kinda start discovery, then you start putting your skills to test and you submit a pull request. And then the maintainers also are prepared that, yeah, on the day of, I mean, it's not just the day of, usually we run it for a couple of weeks. And then we had a, we kinda gamified it a little bit, where we said, okay, we're gonna run a dashboard where we will give you points, we'll give you points for doc fixes, we'll give you points for code fixes, we'll give you points for features, major features, so on and so forth. And then there was a competition, this was again done at Fruit Company, but that's where we created that dashboard essentially and people were quite excited. So it's not just like, you know, the quality of contribution really matters too. There were cases where employees were excited to learn a new skill or a language. Well, I've been thinking about learning Go for a very long time, but now this gives me an opportunity to pick up that skill because now I have five days, my manager has allowed me to contribute here, so I'm gonna go pick up and then I can leverage that skill, it's a transferable skill to an external project as well. Let's talk about the purpose of open source foundations. So open source foundations, think of like Linux foundation, cloud native computing foundation, Apache foundation, open source security foundation, there are hundreds of them, but those are the foundations that I'm talking about and what they really do is, they really advance open ecosystems because most of these foundations, they thrive on that principle of open transparency, collaboration, diversity, inclusion, all of that. By participating in these foundations, you are really at the forefront of defining and maintaining technologies and standards. So you make sure that you are in these foundations, like the way Intel participates, usually we are at the top here, and then pass the knowledge that we have learned internally to the foundation and whatever we are learning from foundation, bring it kind of in-house. So it's a two-way bridge. You really, it gives you an opportunity to engage and collaborate with industry peers, you know what's happening at the latest edge, it gives you an opportunity to kind of shape the industry and it also helps you amplify your brand and people across the industry. And by just putting that on your resume and actually doing the work brings you that much more credibility. It's more important to do the work than put it on the resume though. From Intel perspective, the way we see it is, we are part of 700 plus foundations and standard bodies. As I mentioned, I'm part of the Linux Foundation, I'm part of the OpenSSF Foundation. I'm also the governing board rep for Intel on OpenSSF and I'm also the governing board rep for Intel for the Cloud Native Computing Foundation. And I'm also the governing board chair for the Cloud Native Computing Foundation. So it's really fun, really engaging way to collaborate with the industry peers and take the industry forward. And I talk to hundreds of customers on how to make Cloud Native better for them. Similarly on OpenSSF, we are constantly challenging how do we improve the security posture? What is the relevance of SBOM? What is the relevance of the security mandate? Cyber security strategy was just announced a couple of days ago. How do we implement that? How do we operationalize that? There are multiple working groups that you can participate in. So all of that brings that culture back in the company as well. So let's talk about advocacy a little bit. Now Ospo would be one team, two, I don't know, how many people could be there in Ospo? I've seen Ospo's of all sizes from two people to 50 people. But depending upon your size, it's very important to have your internal events in different business units or different teams. So for example, there is a team that want to present a case for contributing to Open Source, but they may not know exactly all the nuts and bolts of the process. So those internal champions in that team and the business unit will guide them through that process. So that by the time the process comes to Ospo, most of those details are ironed out. It also raise awareness and educate OSS policies that what can you, what you cannot do, again, helps scale Ospo. Gives you that feedback loop as well. And the last point I already talked about that how it helps you prepare a better business case from the unit to Ospo. Because end of the day, we want to churn out more and more projects, but also making sure our policies are met in a timely manner. So let's talk about the last element pretty much. As I said, chop wood, carry water. Now, this is a Zen proverb, which says before enlightenment, chop wood, carry water. After enlightenment, chop wood, carry water. This is something that needs to be done no matter what. Oftentimes, people think that, oh, Open Source means all the glorified work of sending the pull request, creating a brand new feature, and becoming a maintainer. And that's the end of it. That's probably 20% of the work, particularly if I think in terms of bigger projects like Kubernetes. A lot of the work is non-glorified work. It's help behind the scenes and it's countless number of hours to get it done. Well, somebody has sent a pull request. Who's going to do the code review? Who's going to do the debugging? Who's going to do the LGTM? Looks good to me. Who's going to do all of that? The actual code contribution comes much, much later. The deeper discussion actually happens in the SIGs and the tags. SIGs is a special interest group, and tags are the technical advisory groups. So a lot deeper discussion happens in the SIGs and the tags. Who's going to lead the SIG charter? Who's going to drive the discussion forward? Hosting and building community meetups. That's a big deal. Onboarding new members. If a project like Kubernetes, people who are graduating out of college or developers who are trying to onboard onto Kubernetes, what is their onboarding experience? So there is a developer working group in CNCF that is exclusively responsible for that. But nobody gets paid to do that. People are driving that out of their volunteer desire. And then, of course, reviewing conference talks. Event like KubeCon, there are 1,000 plus 1,100 talks submitted for Amsterdam. And it's like an Ivy League college. It's an 11% acceptance rate. So somebody has to review those talks, create the talk, create the track. So this is the right fit for the community. So that's an important element. So all of that is chopwood carry water. And again, at Intel, we really value that. We have been doing that for over 20 years. These are some of the elected positions that we have seen in the community. So for example, Kathy Zang, she is on the CNCF Technical Oversight Committee. This is her second elected term on the TOC for CNCF. TOC really drives the technical agenda of CNCF. They approve the project, what project goes at Sandbox, incubation, maturity. They talk about all of that. Similarly, Krobe, on the far right here, he's part of the Technical Advisory Council on OpenSSF. And again, the TAAC is the technical arm of OpenSSF that takes the OpenSSF agenda forward. Asim, he's a chairperson and executive director of Green Software Foundation. They talk about the sustainability angle of the software. What are the green software principles? How do you make your software more sustainable? Marlowe, she led the effort for environmental sustainability. She's a co-chair for that working group. These are all chopwood carrywater work, which it makes it impactful, which is very much needed in order to make the world behave in an open source manner. So if I can bring it back all together, I really feel these are the critical elements that I've seen across multiple companies that I've worked at. And you need to have a very credible business case which is tied to the core of your business, of your company. Ospo, if you were to make one change in your company to bring that open source culture, I would say set up that Ospo. The next foundation to do group really provides a comprehensive set of resources over there. Then from there, you can start building the inner source culture, start running internal events. You don't have to run like when we ran the OpenEcosystem Summit, we had about 2,500 attendees over there. You don't have to run that big or sort small, depending upon the size of your company and your team and your capacity. Open source foundations also brings that culture because you're now engaging back and forth. Advocacy is important, allows you to scale Ospo's and the chopwood carry water work is required internally and externally, no matter what. So make sure people are identified. One of the important elements that often is not talked about, why would it get people fired up to do the chopwood carry water work? They need to be incentivized in their focal, that yeah, this is work is valued and I'm gonna count you for that work that you're doing in the community as part of your annual focal. Otherwise, it kind of becomes like a dying hobby. It's super important that we focus on that and as if you are a manager of a team, if you work for a manager who doesn't understand, let's talk, I'm happy to talk to them. This is super critical work. Just the last position here. These are two QR codes. The one on the left really takes you to open.intel.com. That's where we talk about everything that Intel does in open source. On the right is our Twitter handle. So if you wanna talk to us, tweet at that handle. We try to be regular over there. If you wanna talk to me, please by all means tweet over there. And this is the legal disclaimer and there we are. Andres, stop here. Thank you. Thank you Arun for sharing your journey with us and helping us to learn a little bit more about the work that it takes to transform an organization. Some of the companies that you mentioned are started off as maybe not open source averse but at least not open source. Pillars of open source community. Others started open source hostile and ended up in another place. I'm not picking names, I'm not pointing any individual one but I'm saying it takes a lot of work to transform an organization in that way and we've seen that happen a lot in our community. Over the last, I don't know, 2030 whatever years that we've been doing open source and free software and the like. So if you have a moment, we usually do a little bit of Q&A with audience if you're open to answering some questions. Yeah, well, I think one of the things I would say I always keep telling my team that whatever work we are doing now is gonna show and impact a year or two later. You know, don't confuse this with sales and marketing that oh, whatever I'm doing is gonna happen in Q1 and Q2, no. Whatever impact work you're doing is gonna start showing results a year or two out. As a matter of fact, the work we did back at Amazon, we are like, I was talking to the current manager of the team and he was telling me the same thing that we are seeing the benefits now around of everything you did, for example, at that point. So you need to be patient and you need executive support to help you build that culture. Please go ahead. That makes a lot of sense. Changing culture in any organization is hard, whether it's around open source or around other things that you need to change the way you wake, what you think about being important every day. Yeah. So, sure, I'm gonna let, so I guess I'm gonna hand this off to Phil real quick unless there's another handheld in the back there. And if you have a question for Rune, he'll run to you. Thank you. Really enjoyed the talk. I love open source and I want to know, like since it's not part of my day-to-day job, how do I advocate for like, what do I ask for, 20% time or what do I do? Yeah, I think that's an excellent question. And there are more people like you honestly where open source is not part of their job. And usually the way it starts is, it starts as a hobby that, okay, I'm gonna play with it. I'm gonna do it off time. I'm gonna do it on weekends. And then see if you like it. You know, I see if you start getting a kick out of it and then see what are the principles that you are learning over there you can start bringing into your job. And I can bet you on this, it will start showing impacts. And then once you are at the point where ready to take the next step, talk to your manager. Because you know, one of the things that for example we did back at Sun is, when we were trying to change the culture of the company, we made sure that our president, vice president at that time of the Java team, he said, everybody gets 20% of the time to respond to at that time. 15, 20 years ago, stack overflow, do the blogging, help the community. So that was a top mandate. So oftentimes you could do these things in little fires at your own level, but what makes it sustainable is when it's a top down mandate. You were talking about the advantages to, I get the inner source concept using the open source software development tools applied to the internal code. Isn't one of the other advantages, if there's a point, especially like some of it happened at Sun and maybe every of all of the older organizations, where there's a point where you wanna take that inner source code and now make it public. Can you talk about that? Are there things that you wanna look at? No, absolutely. I think there is a maturity model as we say, and that's what we started working at one of my previous companies, that initially let's say you are a private repo, then from that private repo you may graduate to that, okay, now I wanna get collaboration across multiple teams. So you get to the inner source model and then some projects may only stay inner source. They never get out of the company, which is fine, perfectly fine. But then some projects may have a desire that now I wanna graduate, like I'm a cloud native project, why do this by myself? Let's tap into the collective wisdom. So they may have a desire that, hey, I wanna get to a cloud native or a CNCF sandbox project. So then we had enough knowledge and wisdom within the team where we could kinda guide them that, hey, when you are going to apply to be a CNCF sandbox project, here are the things that they look at. So during inner source phase itself, we can get them ready and prepped up. And then inner source, I think one of the points we didn't talk about is putting a code out in the open and saying, yep, it's gonna work, people gonna send pull request, somebody magically gonna merge it, no. You go to resource for it. And generally what we were telling the teams is, hey, plan for about 20 to 30% of your time for guiding these maintainers, guiding these contributors and merging their pull request. What are the benefits of it? Is like, how it becomes more diverse. So I think that element from close source to inner source to open source and within CNCF again, sandbox incubation graduated, there's a full ladder for it. Thanks, great talk. As a leader in a big company like Intel, like tens of thousands of companies or the fruit company, where obviously tens of thousands of employees, it's easy to set up an open source office. But as a leader for a leader of a smallish company, let's say hundreds of thousands, how do you tell the executive members of the C levels of people to be allowing this office to be set up? Because of course there's incentive involved and all that, right? So how do you give tips for leaders? Yeah, no, absolutely. At couch base, which was a 300 people company at that point of time, we technically didn't have an OSPO. So I was hired as a vice president of developer relations, but we were sort of running the OSPO as well. And we were kind of working with the folks that, okay, when are you gonna open source? How are you gonna open source? What is the open source strategy around it? So we were working with that. So I think OSPO could literally start with one person as a matter of fact, right? So my point is, or even with a half a resource for example, you could say, you know what, this person is gonna be OSPO and I would say LF has done a fantastic job for that deep dive on the to do, sorry, the OSPO on how the OSPO should be set up, how it should be structured, should it be part of marketing, should it be part of CTO, should it be part of legal, should it be part of engineering? It does a fantastic job of kind of detailing it. But if you have specific questions I would love to address, but yeah, I mean, OSPO could literally start as small as one person or half a person if you want to do it that way. And then it's all about that person becoming sort of the central point that open source is happening, let's talk to that person, because then that person becomes a focal point for inbound and outbound communication inside the company. Cool, we're just coming up on 11 here. So I think, you know, I think Arun will be around for a little bit if folks wanna chat with him. I guess a couple of quick things. First of all, we wanted to thank you for joining us here at Scale. Thank you. So one of our traditions is to sort of welcome our new keynote speakers to the Scale family with a Josie. Thank you. So thank you. And then here is some local chocolates from here in Pasadena. There's a, that we wanted to welcome you, again, welcome to the community in the Scale family. Thank you so much. So thanks Arun. For those of you that are sticking with us, we will have again tonight, Expo Four is now open. You can wander over there and say hi to all those exhibitors that Arun was talking about all the energy. There's some more coffee and snacks in there again, thanks to Stackhawk. Next set of sessions starts at 11.30. Tonight in the exhibit hall, we have our game night. So whether you wanna play board games or video games or VR or any of the other fun surprises we have in there, please come on by and enjoy. Tomorrow morning, we'll be back in this room with Dr. Kitty Young, sharing some of her lessons from her career. And then again, in the closing keynote, again, back in this room tomorrow afternoon, Ken Thompson, creator of UNIX, Go, UTF-8, lots of other things, come join us for that. Thank you again for being here at Scale. Enjoy the rest of your day.