Good morning. Good afternoon. Good evening, depending on which time zone you're coming from. I'm Ibrahim Haddad. I work at the Lynx Foundation and I have a couple of roles, mostly focusing on AI and data, open source AI and data, but also given my experience in open source building and growing open source program offices, I also help a lot of companies in the Lynx Foundation build and and grow and establish the open source program offices. So about maybe a month ago, I was told that there's this empty room that we have available. Do you want to do something with it? And I'm like, yeah, let's do an open source program office talk. So thank you for joining today. So it's a large deck, so I will not be going in deep in every slide unless somebody has any questions on it. So I'll try to kind of keep up a certain pace and I'm also happy to share the whole deck. There's like maybe 80 slides. So if anyone wants to have access to the slides, please reach out to me on Twitter or LinkedIn, whatever, and I'm more than happy to share it and everybody is free to reuse without any mention. So you feel free to reuse as you wish. So my experience with Ospor started with Ericsson. Over 20 years ago actually and it's a very interesting story because even in the late 90s and early 2000s there were open source program offices, but they were not called that. So the lab I was in was called Open Systems Lab and our goal was to find and basically create open source technologies that you can use in our telecom infrastructure and telecom servers, and we were doing exactly what Ospor is doing today. So over time, IBM in the early 2000s established their Linux Technology Center, Intel in 2002 established their OSTG, open source technology group. So and eventually over the years, maybe for the past six, seven years, we've kind of standardized on the terminology of Ospor's. So today's session covers a lot of topics. I have the abstract there, but I'm certain I'm not going to read it. But basically, you know, how critical open source has became to how we build software today. And there's actually a lot of what I think of as like cool graphics that I have in there. All of these are actually imported from Linux Foundation research papers. So all of the graphics, if you wish to use them, you can just go to the next research website. We've published a lot of Ospor papers. You can just download the infographics and use them. They're publicly available for free to use. Introduction to Ospor's, the Ospor transformation, which is something very interesting that I've experienced over the years where I worked in organizations where we started as a small group of people. For instance, at Samsung, I was the first hire to establish that group.  And now they're kind of shrinking down, right? So we talk a little bit about this transformation. There's no one format. It's every company has their own, whatever works for them. And over time, things change and Ospor's adapt, right? Talk about staffing, minimum staffing to run in Ospor, roles and responsibility. What does this office do? What do people do as kind of a minimum core viable operation? Challenges and some practices. So there's really quite a bit of information. And certainly everybody is free to grab a copy of this and to use them. So criticality of open source, as you know, today, open source is everywhere. I mean, just the fact that you probably took a car, flew here, used your bank, used the internet, everything in our modern infrastructure relies on open source. So when a company is doing software or they're building hardware that utilizes certain pieces of software, you're actually in the open source business, even if you don't realize it or your users of open source, even without realizing it. So there are certainly a lot of advantages that entices organizations to create and use and deploy open source code, but also to get to a point where they want to contribute to these components and use them in their products and services and grow these communities and support them to make sure that innovation continues to happen in project communities that you depend on for your products and services. So really, a lot of advantages I will not go through them. It's just a kind of quick introduction into open source. And there are really some very specific impact that open source has on any given organization. So it certainly exited the development of open solutions, provides implementation to open standards, a lot of the reference implementations today in open standards are actually based on or licensed under an open source license. So they're kind of open source software. It helped you commoditize the market, reduce kind of the price of strategic assets. You know, in a lot of times, companies use open source as to their advantage in different business situations. So certainly there are some technical advantages, but there is also a business advantage to it where open source is just another tool in your toolbox as an organization that you can deploy and use in specific situations. And certainly it's a great way to partner with other organizations, with project communities, individuals, collaborate with them on bringing new development and new innovation into whatever project that you're considering. So this slide actually goes back maybe 10 years ago when I started at Samsung talking about how open source enables our projects. And I actually, you know, once in a while, I will tell kind of funny anecdotes. So one of the instances in relation to the slide is, you know, as head of OSPO, I have to raise funds for my team every year. And it's like in the millions of dollars. So one of the things I've done at Samsung is I showed up to fund raising in Seoul, in South Korea, and I'm meeting multiple executives, everybody's in the room. Very few of them really know anything about open source. And I'm there to raise maybe over 25 million dollars for my group. And I had a slide that had about 30 product, pictures of products of Samsung. Everything you can think of that Samsung produces, you know, choose the top 30 products, I have them on the slide. And actually, it's a very small team, a group of executive, maybe, you know, 10 to 12 people and their handlers sitting kind of on the back seats. And I asked the question, you know, how many of these products do you think runs open source, right, or utilizes Linux and open source? And certainly, because they're super senior, like, you know, EVPs and SVPs, it took like, you know, a few seconds together to kind of relax a little bit and start kind of socializing on this question.  And the actual two answer is all of them, okay? So when you look at a portfolio of a company where every single core product that you sell relies on open source, you need to have an open source strategy. You need to build up your competency because you don't want to be in a position where innovation and development is driven by other companies. And most of them are actually your competitors. So you want to align your products with what's happening in open development to make sure there's good synchronicity across these efforts. So there's a lot of enablements that happens with open source. Some of it is, like, all, like, direct enablement, meaning something you do and you have immediate results to it. And some of it is indirect enablement, where you do in action, there's a direct result to it, but over time, there's some indirect advantages that happen that accumulate. And really, the result of all of these different enablements is, you know, better products, better services that you're building, a better relationship with your project communities that you depend on, and also, in some cases, depending on what you're doing, better relationship with your customers as well, especially when they have access to the code bases that they use in deployments. So some of these slides I have now, and this, as I mentioned earlier, is kind of infographics from different reports that the Linux Foundation has built over time. So if you go to the Linux Foundation research website, you'll be able to download all of these. So every single year, the Linux Foundation, in collaboration with the To Do group, they survey organizations about their open source deployments and their OSPO groups. And year over year, we compare these results and we try to figure out trends and what's going on across the ecosystem. So a lot of these results you see are actually from these surveys. And one of the very important trends that we notice is that once organizations start formalizing and adopting kind of an official OSPO group and they're able to hire better people, they're able to attract more talent and higher quality talent into their organization. I've actually experienced this first tent when I joined Samsung in 2013. So Samsung is not known to be a software company. It's not known to be good in open source. It was like really a very difficult situation. And it was very hard to hire for the first 12 to 18 months. And two years into it, I actually shut down my LinkedIn messages because all I get are messages from developers, hey, do you have any openings in your group? And we were able to grow that team from like 12 people but to hide the first year to six years later, we were over 100. And a lot of them are maintainers and committers in different key projects that we use. So the fact that we established the group, we had kind of formal presence, we had our own budget, we have different advantages like work from home, choose your own equipment, you know, etc., these different perks, we were able to build up that credibility that developers, you know, in the general, realized that, hey, you know, this company is kind of serious, otherwise they wouldn't do all these different efforts they're doing. And then we become kind of a target for individuals that want to join the effort. So it's really great on improving not just the product but the ability to attract talent. And in general, when you look at open source, it's just another tool. So organizations typically, you know, they have their own internal R&D, they have a relationship with, or investments in different startup organizations, they work with universities. So there's really multiple venues for innovation and open source is just one of them. And when organizations start thinking of open source as such, as it's just another building block and their innovation pipeline, it becomes a lot easier to work with and figure out, yeah, this is really strategic to us, as strategic as investing in startups, as strategic as building university relationship and launching projects with universities. And with that, most of the companies, when they look at their open source journey, and this is kind of the scale I use, all companies start as a consumer. They start, you know, we're using components of your different libraries, frameworks, tools, you know, operating system, you name it. And over time, they get to the realization that, you know, this is really good, we're able to benefit from that use and we wanna increase our commitment to the project and increase our influence in the development and the road mapping of the project. So they start increasing their participation and then they become kind of influential contributors and some companies go further to aim for leadership position in these different projects. And certainly this is on a project by project basis, meaning, you know, if you're a participant and you have contributors into the next kernel that are, you know, maintainer of different subsystem, that doesn't translate into any other project. So typically what we used to do at many of the companies I worked at and it's kind of an ongoing practice is company survey their open source bill of material. You know, what are the top, let's say, you know, 50 open source projects we're using across all these different products and services and create a certain prioritization scheme because that will guide how the internal open source effort will be put towards which projects and then focus on kind of the key critical projects. And every year this changes. So throughout my experience, we go through that exercise every year because every year there's new things happening, there's new products, there's products that we're retiring and so on. So every year we survey our products and we try to understand where we're using open source and what capacity, what are the particular components and where should we put our resources because, you know, when you look at any product, any given company produces, sometimes it's over a thousand open source components, libraries or tools that are in that product, over a thousand, right? So you cannot have involvement on all of them. So you need to prioritize at the top 2030 where they're critical to you. You cannot replace them. You cannot recreate them. You cannot outsource them. So kind of certain criteria around them and then focus on these. And a lot of companies, you know, they're super happy being just a consumer. Other companies push a little bit to become a little bit of participant. Others want to be a contributor. So it's on a project by project basis. We're on a given project you just consume. It's not a critical project. You don't care what happens there.  And as the importance of the component becomes higher, then you want to be involved in the project. So as part of all of that exercise, organizations create an open source strategy. And there are actually some pretty good open documentation on creating open source strategy. And even some organizations made available that internal strategy document online. So you can actually go search for that on Google, for example, and download them and figure out how company X, Y, and Z are building their open source strategy and kind of learn from them and adapt that as a template for your own. And when we examine all of them, there are usually kind of four key tenants to that strategy. The first one is kind of a focus on the project, and what criteria they use to decide what projects to get involved in. Second one is the actual community. You know how to build up a good relationship with the community and create that positive understanding between the community and the organization. A certain governance aspect to how open source is being governed within that specific company. For example, if we want to use open source component, what's the process, what's the policy, if we want to contribute to it. So that kind of internal governance. And then there's the general culture building the culture. And this is actually very important. And it relates to so many facets of open source across all different organizations. So I will give you an example on the culture. So I worked with very old companies that are over 100 years old, and I worked for companies that were five, six years old. And what's really interesting is with a company that was established when open source was already mature and available, and everybody knows it, everybody is kind of an open source developer. So if you think of, for example, Facebook or Meta now, their open source office is probably like five people. That's it. Why? Because the company was founded on the principle of, we want to use as much open source as possible, right? They started with, you know, they didn't go and outsource, you know, their hardware to some microsystems or use whatever, they started with Linux, Apache, MySQL, and Python, and so on. If you go to an older company, like for example, when I used to work at Motorola, you know, it was very hard to get started. So a lot of the newer company already started with open source, everybody understand that, a lot of the developers are hired, they have experience with open source, so there's not much of a culture clash. If you look, even it's on geographical basis, so I worked for companies in Asia where it's kind of very hierarchical order, you know, there's a boss who gives the order to the person and then you end up with like, I gotta go do this, although I'm not convinced with it. Whereas in like European or US companies, it's more fluid and you're able to, as a developer, kind of transmit what's going on and get a feel and have a better fluidity in what you're doing. So these kind of are the major four tenants of an open source strategy and they typically evolve on products or services in this case. So how can we work with open source across projects, different communities, how can we structure ourselves internally in terms of governance and build up a positive open source culture in the serving of our products and services. So you will see this kind of reoccurring and there are basically four core aspects to the work of OSPOS in general and I'll get to that in a little bit later on. So the first one, the first aspect is consuming open source. So companies need to consume open source, they adopt open source projects, they use them in their products or their online services and as part of that, they have to comply with the open source licenses, right?  All right, so now we've used 20, 30, few dozens, hundreds of open source components, now we need to understand how we're using them under which licenses they're coming to us so that we can go and fulfill the license obligations and kind of respect these different licenses. And then one aspect above that is where company sometimes go into the contribution territory which is, okay, now we're using and we're compiling with the licenses, we will start contributing to key projects that are important to us. So now you need a different set of infrastructure and enabling elements in your company. For example, you need a process to, internally to manage that contribution aspect. You need to have a policy. So think for example, in a company like Google or Meta or even Samsung where we had in Korea alone over 50,000 developers waking up every morning and using open source. So in a small company, you're able to manage that.  But in a company where you have thousands of developers, you need to have this massive infrastructure to know what's going on, to know that we're using these components, we're approving the use of these different components where we're not gonna have a license or compliance hiccups. So there's really a lot of challenges when you think of the infrastructure required internally in terms of at a larger scale. And this is actually one of the challenges I will talk later on. So this is kind of a crash course, an introduction kind of to break the ice. I would like to stop for a minute, see if you have any questions before we kind of delve into OSPOS and please feel free as I proceed. You can just raise your hand and I would stop and take any questions as we go. Yes, please. Oh, sorry. I thought you raised your hand. Go ahead. Is there a mic? Thank you. It's fine, we'll take one minute break and then. Because I'm pretty sure I will lose my voice by the end of the session. I have a question regarding when the company is, do not have a, if changes something in the strategies in the way we perceive how we are doing the strategies, when the product of the company itself is not open source or when we're just using consuming but also releasing an open source product itself? Yeah, very good question. So I will just rephrase kind of for the benefit of everyone. So the question is how, or if there is an impact on your open source strategy, if what you're using is not necessarily open source, so you have your internal activities, you're deploying open source, right? So that's, so it certainly differs. And one of the main areas where we have as an organization paid in the past because not in the links foundation role like previous roles paid extra attention is how these open source components we're bringing in, how they would interact with internal proprietary components from a licensing and compliance perspective. Because in many cases, and I'm gonna use a very simple example, okay? Let's say we're combining an internal proprietary piece of code and it relies on, let's say an LGPL licensed component. So we wanna make sure for example that the linking is dynamic for example, that it's not static, because if it is static, then we're generating a binary that contains code from both and as a result of that, we have to make our proprietary piece available as open source. So certainly there is a difference, mostly from another strategic level, it's mostly at a tactical level, meaning we were still care and the same interest in bringing open source component, encouraging reuse of technologies, encouraging minimizing time to market from the fact that we're picking up things that already exist, we don't wanna recreate the wheels, but where the difference is is there's additional attention on how these components we bring in interact with a proprietary component. Because if it's still open, if all these components are open source, you don't care because they're all open and you're gonna make them available. But what you wanna do is keep a piece proprietary and that's where the interaction happens. So there's a lot of attention paid at the architectural level of kind of isolating that proprietary value away from anything that could trigger a distribution that will force you to put up your proprietary stuff under an open source license. But outside of that, business as usual. And by the way, this is one of the most difficult aspects because to be able to do that, we typically call it architectural review. We do reviews with engineers and these can be like two hours long and sometimes there are some really complex system and there's like five, six, 10 engineers in the room and we're trying to identify how things move around, the interfaces, you know, system calls, et cetera, just to make sure there's no inference between the proprietary bits and the open source bits. So introduction to OSPOS. So what is an OSPOS? So everybody has their own definitions. From my perspective, having been involved in program offices, I set up a few of them, I managed a couple. OSPOS is just a program office that manages all companies' interactions with open source. You know, that includes using open source, contributing compliance, community events, open source foundations, open standards. Anything that touches open source has to go through that office which is like the orchestrator of all these events and activities across the whole company. So anything open source has to go through that office pretty much like the central operation of open source within any given organization. So they manage open source across the whole organization as I mentioned, across, you know, everything that happens within that given organizations. So why should you set up an open source office? I may be preaching to the, you know, you probably already have open source offices but basically it becomes extremely hard to track all the different activities across the company. So similarly to how you have a program office for a given product or program office for a given activity, open source is as important and it deserves the attention to be able to track all these different activities. So can you think, for example, of a large company like Microsoft or Intel or IBM not having an office like that? I mean, there would be so many redundant efforts. Even there would be some conflicting efforts, right? So the importance of that office is kind of streamlining open source activities throughout across all companies, especially when a company has multiple business divisions, right? So I worked in an organization where you have like the infrastructure division, the mobile division, the home appliances division, the TV division and so on. So that has to be kind of a sink on policies and strategy across all of these different divisions. And OSPOS does that. So they're growing. This is from the 2022 survey. Actually, I think yesterday or the day before they announced their 2023 server results. So this is kind of old. There's a newer version of the server that was announced. So you can go to the to-do group GitHub org and they actually have the new results published there. But basically it's a continuous growth year over year since we started doing the survey in 2018. So in 2019, we had more organizations establishing OSPOS than 2018. And then in 2020, more organizations establishing OSPOS than 2019 and so on. And now it's actually kind of an exception for a company not to have an OSPOS. It's kind of a default. Hey, something is off if you don't have one already. So where do companies start? I think I spoke to a different version of the slide where companies start as users, they become participant and dead drive for leadership. So one of the important thing is, okay, we talked about setting up internal infrastructure to support the efforts of open source. So in this slide, you see the different elements ideally an organization need to have to support the efforts of consuming open source and complying with the licenses. And typically I actually consult with a lot of companies and the first reaction is when they see the slides like, oh my God, that's a lot of stuff, right? Do we really need to do all of that? And trust me, I've been doing this stuff for a really long time and you only need like a few of these boxes to get started. And you don't get to build an infrastructure that encompasses all of these in a year or two. It takes a few years and it's a great goal to aim for. Hello, did I lose the audio? Are you able to hear me? Okay. So it's a lot of items, but basically in any given company I've worked at, and this is kind of my, everything you see here is kind of my personal production meaning all the content I created personally over the years to get to a point where we have this, right? So I was looking at all the different experiences that Eric's in at Motorola, at Palm, HP, Samsung and different consulting I've done to organization and I built up these different templates. So basically when you're starting in any given company, you want to use open source, so you need a certain way, a policy to govern the use, you need the process to implement the use, right? You need to think of strategy, how are we going to implement compliance? I'm going to start from the left side, okay? Under strategy, how are we going to implement open source license compliance? So certainly we don't want to be in the news as a company that is having or being challenged in terms of their license compliance. How do we manage inquiries coming to our desk in terms of license compliance? What is our disc tolerance? So for example, I worked for a company, a startup that had one product and that product used about 80% open source code. So our risk tolerance was zero. We have zero tolerance to any error. So we have to be 100% on top of everything. But when you're a company that ships hundreds of millions of devices every single year, you have more tolerance to errors than the small startup that relies on a single product. And that affects how you build up your policy and how you execute them. What's your M&A strategy with respect to open source? Do you do diligence? How, why, when, you know, all these different things. And then when software gets into your company via procurement, whether it's consultant, contractors, you buy software or whatever the case is, any type of software coming into your organization that is not created directly by your engineer, how do you handle compliance from that, right? So there's this aspect. So there are a lot of different components. And similarly to that, there are many other components in terms of communication, policy and processes to audit the code, to distribute the code, to actual development. I mean, it's a lot of stuff. And typically what I tell organization is, okay, the most important pieces to start with is set up a company policy. And usually it should be like very short. Everybody should understand that you'd be able to write it in like a single paragraph. And I've worked in companies where we have policies that were like 37, 40, 50 pages long. Nobody read, nobody really understood and it was like a lot of chaos. So I think my best advice on this is if you're in like an elevator and you need to give somebody a 30 second elevator pitch on your open source policy, you should be able to do it in 30 seconds. Otherwise it's not a good policy, right? So there are different components. So the policy and the process and educating your employees on what to do when they wanna use open source and how to comply. I think these are kind of essential. And from there you start building these boxes. So when I was, and I tell a lot about Samsung because it's like my most recent experience just before joining the LF, I started with like a couple components and it took me like five, six years later to implement everything that is here and on the following slides. So it's kind of incremental. And if you survey a lot of the companies, one of the services I offer to companies is I survey what they have and I kind of compare to industry plus practices and recommend improvements. And this is kind of the template we use for such practices. And I would really recommend you use that as a tool. You can go back to your organization and say, okay, let's print this and put a checkbox across all these different things that we already have and figure out what we're missing. And this will give you kind of a practical way to figure out where improvements can be introduced. This is not going to work for another hour to do that. So in terms of compliance, I kind of inject a few things here and there. There are a lot of challenges today. So the compliance space today is very different than 20 years ago. I remember my first report in 2020 was in 2000, 2020. In year 2000 was like, what is the GPL and what is Linux? So we're past that, right? So we understand the GPL, we understand the licenses, we understand what we need to do to comply with these licenses. And I think now the challenges are different type of challenges in terms of compliance. Challenges with respect to scale, we're not using dozens of components. In some cases that are products that use 800, 900 and sometimes over a thousand open source library and tool. So how are we able to track all of these components and comply with the licenses at such a large scale? And this is just one product. And if you're a company that shifts dozens and a lot of type of products, then that scale is multiplied. Transparency, speed, right? Speed is extremely important because we want to be able to keep up with the development internally. So if you have hundreds or thousands or tens of thousands of developers that wake up every day, download open source code, integrated, compile it and build it, you need to be able to keep up with all of that from a compliance perspective. So compliance, the speed of ensuring compliance is actually very important. And certainly accuracy, you know, you can do a very fast job on all the code and it's super sloppy. So the goal is to do a really good job on all the software incoming and to be very accurate. So these are kind of the common challenges you will face. I actually have, the Linux Foundation published a few e-books on license compliance to help organizations implement compliance programs. So you're very welcome to download these. They're like 50, 70 pages, detailed manuals on how to build up efficient compliance infrastructures. So I will skip kind of rules for developers. These are kind of my top 12 rules. I would encourage you to take them and adopt them if you find them useful, communicate them to your engineers. Like, you know, here are things that you should do or shouldn't do when you're working with open source software to avoid any kind of compliance issues. I see people taking pictures, so that's fine. All right, I messed up the slide. So, contributing to open source. So this is kind of continuing with the theme of, okay, first we use open source, we need to build up that massive blinding infrastructure to capture everything. And now, moving to contributing to open source, we have another set of infrastructure that we need to have in place as well. So I will start from the very simple things, right? You don't want your developers to go and download whatever they want and contribute to this project without kind of different checkpoints. So companies typically have policies that manage the contribution aspect. They have a process to implement the policy and automate it, so things are not done over email and kind of in a way that is hard to track. So you have a process and a policy. Companies offer guidelines so their engineers what to do, what not to do when contributing to open source projects. And typically when you add that stage, you have a certain level of prioritization and aligning your developer's interest with your company's interest. A lot of times developers may be interested in contributing to a project that as an organization really you don't care about. So you wanna make sure that any type of contribution towards a given effort you have internally is approved and is managed in a proper way. And this is where in many instances organizations start to have a dedicated group that they call Ospo because then they're brashing out. It's not we're not just using and complying but now okay we wanna contribute to project. We want to figure out where to put our efforts. We wanna figure out what open source foundation we should work with because a lot of the projects are hosted in foundations whether it's the LF or any of its umbrella foundations or the Apache Foundation, Eclipse, Mozilla and others. And then typically at that stage there is also an interest in getting involved in open standards and in providing reference implementations. So you can see things are kind of brashing out and becoming a little bit out of control because the number of efforts and the number of areas where you can work and becomes so much more. And then, oops, sorry. Another messed up slide. I think this is the translation from Google to PDF or something like that. How can you make all of this work, right? So you need to create the right environment and this kind of ties to the culture point we discussed earlier. So a very good example of that is, I joined one of the companies to lead the open source effort and I was assigned a Windows laptop. I said, okay, I took in and I threw Linux on it and then I couldn't touch email because there was no support for IMAP on their email servers. And then the VPN wouldn't allow me to access the network from home because there was no VPN support for Linux. And then I couldn't work from home. I had to be in the office because of how the network worked. There were so many complications, right? So when you put very motivated individuals who are highly skilled, like say, in any given open source domain in such an environment, they cannot succeed. So you need to have all the right environment for them to succeed and provide the right incentives and the right exposure. So by exposure, I mean, it's like we need to allow our developers to attend events like this, to socialize with their peers, to meet face-to-face, to present their work, get feedback on it. So this is kind of the type of, what I mean by the right exposure and give them the right incentives. And I have actually a pretty funny story. It's actually a true story and I agonized with it for about a year until I was able to resolve it. But basically, in one of the organizations where I worked as head of open source, one of the engineers or developers, they have performance bonus. And at the end of the year, they get paid the bonus based on certain metrics. And one of the metrics was a line of code injected or accepted in upstream. So yeah, and that created so many problems because it is absolutely their own metric to have because you're prioritizing volume over functionality and quality. And that created the second problem where a lot of the engineers were dumping useless code because it was a lot of lines because they're aiming for bigger bonus and developers, maintainers in the project are injecting all of these. And then to a point where in some of the projects we were paying in, they stopped taking in, they pretty much blocked our domain name. And it took us really few months to recover from that. So providing the right incentive is actually very important because it drives the behavior, the right behavior. So this is actually a true story. So I will skip this benefits of upstream code. We all know that it's actually very important to upstream code. You wanna minimize your internal technical debt. You don't wanna maintain different forks and so on. So this chart actually, I like this, not for the fact that I actually created it, but it's actually visually, it explains the importance of working with upstream. And I actually use this a lot. These couple of slides, this one and the one after was executives who don't necessarily have experience in software or experience with open source. And to address why we should be involved in upstreaming codes, right? So typically, if you're not upstreaming code, you're like pulling code from a given open source project. You apply your customization to it. You add functionality. You add, you fix bugs, fix code, whatever the case is. And then you merge it with the product tree. And then you don't upstream it, right? It stays internal. And then the next time there's a new upstream version, you have to repeat that and do it again for any new functionality you're adding. So it's creating a lot of internal code that needs to be maintained. And actually in one of the organizations I worked at, there was one graphic library where our internal fork had over 200,000 slant of code that was the delta with the main steam. And we had two engineers full time working to maintain that. It's the EFL libraries. I don't know if anyone knows the EFL. So true story, right? So it was costing the company two senior engineers full time just to maintain the fork of one single library. So the other model, which is upstreaming way is you download things upstream from the open source project, you apply your changes to it, and you push it back. And you work to integrate that with the project so that the next time you go and download the upstream version, your functionality is already there. So you don't need to maintain that. So ideally you wanna have zero technical depth. It's almost impossible to be at zero, but you wanna be as light as possible. And this is really the core reason, the one, if I have to say one reason on why a company should work directly with upstream, it's for that reason. And for that library I mentioned EFL was 200,000 line of code. Even after like four or five years working on this, we still couldn't manage to push it because it was just like, as we call it, spaghetti code. That's, we had to rework everything. It was like an item that we have to live with forever, pretty much. And because typically things start small, right? Okay, we're just gonna carry this code. And then over time it builds up and builds up and becomes unmanageable and it teaches certain points where it's unacceptable to push that code upstream. You know, they're gonna kick you out. So another kind of survey information, 65% of the organization contribute to upstream and this is actually going up year over year and I believe the 2023 survey that was published a couple of days ago actually has better numbers than this. So if you're building internal presentations to kind of convince your management on why you should participate more in upstream development code, you can certainly go back to the OSPO survey, pull up the results, showcase what's going on in the industry because they also have a breakdown of specific industries. You know, they look at telecom industry, they look at finance, at automotive. So if you're, for example, in the finance industry, you can exactly know what's the percentage of companies in the finance sector have an OSPO. How's that changing year over year? So you'll be able to get industry specific information as part of your supporting documentation. So becoming a leader in open source project, this is actually very easy in a sense at the conceptual level. Okay, you know, you need to contribute and be visible in the project, drive code and have kind of consistent presence in the project. You know, now take that and translate it into an engineering or to a business leader in any given organization. For them, they're not thinking that, they're thinking, oh, I need to go hire so many people, I need to get involved in sponsored open source events, I need to be involved with the foundation, right? So we need to always create that correlation between, you know, actions and how that affects our internal efforts. And actually, I try always to kind of inject stories here and there just to keep it as interesting as possible. So in the early 2000, and I'm taking you back like 24 years, I was working at Ericsson Research and we just started the process of evaluating the Linux kernel and kind of testing with it a little bit to replace our internal operating system, which by then was called Telorp TEL ORB. And back then the maintainer of the Linux kernel, today the maintainer is Greg Roe Hartman as the kind of lead maintainer, there's certainly Linux store holds, less active on a day-to-day basis, but Greg Roe Hartman, right? But in 20, in year 2000, it was a high school student who's 17 years old, living in Brazil, who was the maintainer of the kernel. So at that time I was a senior researcher at Ericsson in Montreal and I'm talking with my boss, who's the director of research, trying to explain to him that he submitted the patches and we were working with the maintainer and they couldn't grasp that. And then he was asking me what is a maintainer, who is this guy and so on. And it was so hard for him to understand that it's a 17-year-old kid in Brazil somewhere in the jungle who is actually holding up this massive company called Ericsson. And remember Ericsson in 2000, it was Ericsson, Cisco, these companies were the Facebook of today and the Microsoft. I mean, these were the top tech companies. So it's actually a very humbling experience because these companies come in, we are Ericsson, we're Nokia, we're Alcatel, we're this and that, right? And then okay, now you're pending the 17-year-old kid somewhere on a 286 computer waiting to test your code. So it's actually very interesting, but basically it's engagement with Foundation, engagement with Project and following Project processes and whatnot. And on all of these different topics that I touched on today, we have really a library, a large library of publications that are very practical that you can tap into on any of these resources and make available to your colleagues and kind of learn from. Because a lot of this content is real life experiences that we pulled in from working with hundreds of companies at the next Foundation, we put together in a very practical way. So we talked earlier about the consumer, participant and contributor and dealer, and certainly they overlap. You cannot overnight jump from being in one phase as a company to jump into the second phase. So you can see what I tried to do with this graphic to show that they overlap and they're project dependent, right? So you may be just a user of Zealob Library, but also you're a user of the kernel and you participate in the discussion on the mailing list and so on, but also you're a contributor to Node.js or other things, so they overlap and it's dependent on a project by project basis. And this is a cool graphics to work from when you're working in an organization because some organizations are very rigid and it's very hard to kind of get funding to get things for the different efforts you wanna do and you wanna show that continuity. You wanna show that we have to transition from one phase to another and that involves additional funding. It involves, for example, attending an event and presenting the work we're doing and trying to convince others that our technical solution is the one that should be adopted and so on. So there's really a significant aspect to that transition from one phase to another. So one of the very interesting, oops, discussion aspects is, how do we set up an OSPO? How do we organize it under a given company? So the next few slides are pretty much like circles and squares, so it's like just back to kindergarten in different colors. So my first slide is, sorry, go ahead. Yeah, so I will make them available on my LinkedIn profile and if you want access to the actual slide, just drop me an email. My email was, it's my first name, Athletics Foundation and I'm more than happy to share it. So one of the first slides I have if you don't have one, it's time to establish, right? This is easy. But I think there are multiple variations of how OSPs are set up and it depends on a company by company basis. So some, and I have different models here and I call this like corporate level where typically a lot of the OSPs are folded under the CTO office, right? So what I did for the next few slides is I was looking with a lot of the company that I work with and I see how they structure their OSPO. Where does it sit? Is it in research? Is it under the CTO office? Is it an independent office under whatever function engineering? And I try to kind of model these in here. And actually there's a good lessons to learn after we view all of this. So there's, I will not spend any time on this really. They can be under CTO, they can be, this was one of my roles. I was head of research, I was responsible for internal R&D but also I owned the OSPO function, right? And I had multiple areas of technology that I was responsible for in open source. There are different setups under engineering, you know? So I think the whole idea behind these different setups is that, and yes, there's the virtual OSPO, right? So a lot of companies don't have the luxury to have dedicated resources. So they have different people in different units, you know, in marketing, in legal, in engineering, kind of working together to fulfill kind of the basic functions without having kind of an official thing called or office called open source program office. I think that whole thing is just to say that there's not a single way to do this, right? You can structure an OSPO any way you want. What's really important is just to get started and what I guarantee to you is that year over year that structure will change. I've been in OSPs that were, you know, a handful of people, like five, six people that grew to a couple hundred people and over time they're back down to five people. And I think there's a very important lifecycle there which is, yeah. So the lifecycle is a lot of companies, especially, and I talked a little bit about older companies, right? That were created pre-open source and so on. So a lot of these companies, they create an open source program office and they start staffing people and then they realize, you know, we need to bring in open source expertise. So they start hiring key developers in projects that they care about and these key developers would give them kind of immediate credibility in the different communities but most importantly they act as mentors for the internal developers to help them figure out how things work and review patches before they submit it and so on. And over time the goal is to build up that competence but then once everybody is a few years down the road, right? Once a lot of the engineers are aware of the policies, it's kind of part of the culture, a lot of the new hires are coming in with open source experience, you don't need to have dedicated engineering for open source. So when you look at very established companies in open source like Google or Meta or IBM, you know, they are open source companies. All of the developers touch open source one way or another. They don't have kind of a dedicated engineering team just doing this or just doing that, they're spread out. And I've worked in companies like HP where we had a corporate level open source office that does everything for the whole company. Then they transitioned into a business division open source office with very little presence and then the head of open source at that point moved to the LF, right? And then now there is none. Why? Because it is part of how the company works. It is kind of a de facto thing that everybody knows how to open source. Everybody is familiar with the policies. There are just a couple of people that's keeping things in maintenance mode, just keeping things updated. But beyond that there isn't. So there's this kind of, let's create an old sport to fulfill the function to create a presence for the company, to build up the culture, create engineering force focused on open source. But then once everything is done, you kind of cancel your existence and then you go into a different form. By the way, this is my own hypothesis. This is not like a Linux foundation thing. So if you disagree with it, you're actually disagreeing with me and that was my employer. And actually I wanted to write a short paper on this kind of just to trigger a discussion because I see this a lot. So I'm intending to work on this towards the end of the year where I take use cases of different companies that went from having no sport to having small sport and that also grew up to hundreds of people and they went through the downgrading and now they're like a couple of people. And you can see it in several organizations. For example, the Microsoft open source program office is like 12 or 13 people. And then I was visiting their campus because I used to live in Seattle and somebody pointed to me like, you see these two buildings? They've got like hundreds of Kubernetes developers in their hundreds, right? And this is just one major component. So they have thousands of developers working in open source and their whole open source office is just like 10, 12 people. So in terms of staffing, there are a given kind of minimal set of people that has to be kind of present in that office. So I would just, I would not go into specific details. Just obviously you need to have the head of the office supported by a software architect who's got a really good understanding of the core products that the company is working on and trying to correlate that with what's going on with open source and what open source component can we create and bring into the company in support of bidding these different products and services in the company. By the way, as part of the compliance book I mentioned earlier, there are very detailed job descriptions to a point where actually companies actually go and grab that and modify it a little bit and use it as actual job posting. So you can rely on these descriptions. There's usually a technical evangelist, you know, not kind of a pure evangelist but somebody with a deep technical background that is able to go to events, create demos, participate in technical discussions and pretty much promote the contributions of the company and understand how these contributions fit the products and also how they fit in the open source project and try to lobby other organizations to use and participate. There's typically some form of compliance expert on the Ospo. It really depends on the company by company basis because some companies, they have the compliance function on the corporate level and part of that big compliance office, there's a subset focused on open source license compliance but in many cases, there's somebody who's got a deep understanding of the open source compliance aspects that assist in that. And certainly there has to be legal counsel, not necessarily dedicated to the Ospo but available to help with all the open source legal mentors. So these are kind of the four or five core roles. I've used these roles in previous Ospo that I created and managed and there's another aspect that I didn't mention here but developers. So in some of the Ospos where I was working we've had a bunch of developers that we hired to focus and eventually we thought that it's not a good model to do and eventually transferred these developers and kind of sprinkled them across the different engineering team to help kind of spread the culture and the awareness and kind of the best practice on how to work with open source and it actually is a model that worked through well. So I will skip, oh, this is Ospo, okay. So in terms of primary responsibility, responsibilities of an Ospo, there's a lot of them as you can see on the slide and this is kind of a more expanded view of the early slide we show were responsible for using and complying and contributing to open source. This is kind of a deeper view of these three different categories. Working with open source foundation, tracking metrics, implementing inner sourcing, creating guidelines. So there's like a whole bunch of stuff and the more you drill into it, the more you realize like if you don't have an open source office and you look at this, like, oh my God, we need to have one right away, right? There's so much stuff that you can actually do. And again, going back to the to-do group, this is why your companies with Ospos are actually more active in open source and it's kind of logical thinking but it's actually also proven in the Ospo survey as well. So the more companies have Ospos, the more they're involved, the more they have formal activities, the more they're visible, the more they have influence in the project. So the challenges, a lot of challenges, there are five key challenges, okay? And if you work for an Ospo today, I guarantee and I'm kind of willing to bet money on this that actually I would bet my drink vouchers that you've come across several of these, okay? And what's really interesting about this specific slide is I carry this slide for like the past 10 years and when I go to presentations I've done 10 years ago, it was like two or three items in each one of them and over time it kind of built up to have more challenges as the experiences kind of grew. So you'll have cultural related challenges, with respect to the actual operation of the program, challenges with respect to tools that you need to use internally, continuity challenges and this is actually one of the most impactful and I have a very funny story, true story as well. So I worked in a company where every year they do executive rotation. So I was a VPA reporting to the country CEO and every year I have a different CEO and every year I have to in January go to the new CEO, my name is Ibrahim Haddad, I'm the VP of this, basically starting fresh and it was so hard in terms of fundraising because every CEO have different priorities and every CEO have different kind of challenges they wanna do for the company, achieve for the company and they may not care about open source security but they care about open source cloud then what do I do with my open source security activities? That's like $2 million I need to fund, right? So the continuity of strategy, the continuity of funding, the executive support, the continuity of that are extremely critical and you probably experienced times where executive change and then you got an email and then you have to figure out what to do with people, right? I have like 10 engineers working on a certain graphic library and now this is not a priority anymore, what do I do with them? So one of the things I actually did for my team, we adopted kind of quoting what the model that Google created which is like the 80, 20% so we've had this thing where we didn't come up with it, again the credit goes to Google, we just adopted it, is across throughout the year, we have at the beginning of the year, developers decide, I'm a graphics developer, I'm a current developer, I'm whatever developer in the area they are in and they choose an area they wanna expand their expertise in. So for that, and these areas are predefined by us as management, my core team and myself, where we try to see where are we looking at next year, what's gonna be hot for this given, for our company in a year or two and we try to build up that knowledge through the 20%. So we're not doing any critical work, it's just basically take that time, five, six, seven hours a week to learn as a developer and because we want you to be ready in a year that if we shift priorities, you're already kind of in that environment. So that helps us quite a bit. So all these different challenges and certainly there's the education bit, which goes in multiple ways. Oops, here we go. So the education piece is actually one of the core challenges because in many times you're kind of educating your superiors. A lot of times as vice president of open source or vice president of R&D or working with CEOs or SVPs or EVPs who don't necessarily have the background in open source, don't have that knowledge. So there's kind of executive education, you're kind of educating above you, you're educating your peers, you're educating your staff and in many cases, as in Ospo, we've done a lot of formal training, we actually created training courses and recorded a lot of them and it became kind of mandatory for our teams and anybody touching open source. So we've done a lot of that and actually for instance, one of the things that I really liked that we've done and I would highly recommend doing it in your organization is kind of new hire orientation. On the first day when you have new hires they typically got like the brainwashing company stuff and we've added like four or five slides on open source. Okay, here's what we do with open source. To use open source, go to that web link to contribute, do that, here's the link, right? So from day one, they know that we as a company we're heavily involved, we have policies that they have to follow and they would know who to follow up with. So we've done a lot of work in these areas. So it is actually overwhelming and I guarantee that anyone here working in Ospoz would experience most of these, if not all of them. And I think the good news is there's a way to address each one of these, right? And the advantage we have today is that we have, we can look back at all these companies that came before us and experience these challenges and learn from them. And there's actually the to do group which is kind of a collection of 150 companies that have Ospoz that come together, share best practices, share how they address these different challenges, they share tooling that they've developed to address different things that they come up with and so on. So if you're in Ospoz and I would certainly recommend becoming part of the to do group, there are no fees or anything of that sort, it's just like free effort under the LF that you can join, they meet regularly, they have different geographical, I know I'm on the Europe and Middle East call so I show up to that call and you know, so there's efforts in specific to Japan, in Europe, in the US, in support of different geographies. So you had a question?  Do you start to make it up? Okay, so. I haven't done it yet. Okay, awesome. So this is by you. Right here. So you can go to this guy. By the way, I'm not sponsored by the to do group. I'm, and there are a lot of factors that influence the success of Ospoz and this is actually, I went back to my Twitter feed from many years ago and I grabbed this from there. This was actually a poster I created myself when I was trying to recruit office source developers and I was telling them, you know, if you work with us, you have the ability to work remotely. This was like, I would say, 12 or 13 years ago. I mean, now working remotely is different, especially after COVID, but before it was like, not that really, not that popular. So you can work on remotely. You are guaranteed time for upstream development. So if you are as an organization, you want to hire office source developers, you cannot just hire them and put them on something completely different. I mean, there has to be continuity for the work in the open source community and there has to be a certain respect and time allocated so that they continue with their open source duty, which is why you're hiring them. So there has to be time allocated and understanding that this person we hired who's a maintainer or a committer in, I don't know, a webkit, they need to have a few hours a week dedicated to continuing their role as a maintainer. So we can not just force down a lot of different work that they would be in a position where they have to choose this or that. Freedom to work outside of the control of product team. This is very important, right? Because I worked in places where the Ospo was put up under like head of engineering or, you know, SAP of engineering and over time we became just a development arm for the product. And then we lost autonomy and we lost freedom in the areas we should focus on. We become just the open source team that knows the components including the product and then we become kind of an extension to that group. So in future teams that I set up and I run for years, I always made sure that I don't have a high dependency on any given product team from a funding perspective. So I always had the kind of criteria that any type of open source development that my team does has to at least benefit or be funded by at least two different product teams. So I always have kind of a way, some flexibility in my operation. So we provided clear guidance on priorities in specific projects.  There's always kind of clear line between what needs to be done in the open source project and how that's gonna help us in the product. Opportunities to be visible at open source conferences and actually that was one of the major things I actually negotiated as part of my recruitment into that specific company where we need to have a budget for the team members that join so that they're able to fly to different events. They're able to meet their peers. They're able to share the work they're doing, lobby for technical solutions and this and that. And that was actually a very successful experience because we had a separate budget than our had come. So we had around 250K per year and that was just travel for events and we would spread that at the beginning of the year we figured out who wants to go where and kind of spread that and that's where it worked extremely, extremely well because then it created additional motivations for the developers because if you're presenting at the Kernel Summit, you gotta work your ass off to get things done so that you get to go on that trip and the money is guaranteed and the trip is there. It's just waiting for you to do your work. So it was extremely good. And access to proper open source infrastructure, right? So as I mentioned, my own experience getting Windows laptop and no VPN access, though I'm up access, it was a nightmare. I couldn't access anything. So then in one of the companies, it was so frustrating to a point where we actually created our own infrastructure on AWS. So we had our own email addresses, ebraeme at, I'm not gonna sit in there with the company but we had like open source OSG dot whatever the company name. So we had our own email infrastructure, we had our own VPN, we had our own Wiki because we needed to exchange a lot of data files like in the hundreds of megabytes, especially on the graphics side. And we couldn't do that internally. It was like a nightmare. So and what was really interesting is per headcount our costs towards AWS was about $30 per month per person while I was paying out of my budget and on $600 for our internal IT for infrastructure that we're not using, right? So and this is actually common. Now it's a little bit better but this is actually common across multiple companies. So we ended up spending, I don't thousand bucks per month on an infrastructure that serves extremely well, which is less than the cost of two headcounts paying for IT really to do that. So all of these factor actually influence and it is a success of bringing in resources into your Ospo and maintaining them longer term. That has to be a trick for this one. Okay, so recommendations for making an impact as an Ospo. Identify your reliance on open source software. I mean, you need to start from somewhere and the first step is try to understand where are you using open source software and which product and how far are you dependent on it? And I think this is actually an extremely important step because it will define everything you do from that point on. And a lot of companies, I mean, I did a lot of reports produced by the companies that produce SCA tools, the tools that helps to scan code and identify what open source software you're using. And a lot of them include this staggering statistics of companies not knowing they use these hundreds of open source components or not knowing that they rely on 40% of their code is open source and so on. So there's actually a lot of open source is so ambiguous that a lot of companies actually use it at the developer level, but when they do their due diligence and they do their scanning for their code basis, they actually discover a lot more code used than actually declared. So your starting point is, I think, and this is from my personal experience is identify what open source you're using and where and how critical it is to you and how dependent you are on it, right? And that will give you kind of a good starting point to decide how to prioritize whatever effort you're doing. Yeah, so I think for the next few slides, and I'm really towards the end here, is all these infographics are from a report that was published by the Linux Foundation Research on how organization can have more impact through their open source development. So I just grabbed these different infographics and I dropped them here. So you'll be able to access all of them. So set up your organization to implement open source infrastructure for compliance, consumption and contribution. This is critical and this scary slide with like 50 boxes, this is like your starting point. And you can use it as a way to benchmark what's been already implemented in your company where you need to do some more work. So that's kind of a great worksheet for people to figure out where improvements are required. Be patient and seek influence, right? A lot of companies wanna get things done right away, right? And this is like a lot of hard work over a long period of time to bring in a developer who occasionally contributes to open source project and get them to become kind of a trusted committer or even a maintainer. We're talking years. So companies need to be very understanding of how that process work and it's an exercise of building trust and continuing to contribute and not just code, but contribute to the technical discussion and the direction of the project. So this is actually a very good illustration where you have the water and you're kind of watering the plant and it takes a while. You put in seeds and it takes weeks before that seed becomes a little plant and grows and it's a very similar process. Practice and encourage an open and cooperative mindset. A lot of companies have competing teams, competing groups. And I worked in a company where it was a known fact that they actually established two of everything because they wanna create that environment of competition and eventually one of the teams will get there and then we're on the path of getting wherever we wanna get. So to be successful really in open source, you need to practice these practices internally and be successful because if you're not able to collaborate with the people you work with in your office or in your company, it's gonna be a much harder exercise to do that with outside people, especially that some of them are actually competitors. So that has to be, people have to be in a certain mindset that I'm here to collaborate. I wanna solve a problem. It's a big problem that I cannot solve on my own and hence I need to go and find likely minded people with the same challenge that wanna solve it as well. They're open to collaborate with me. We have to be patient and understand each other. There's that whole mindset that has to be there. We talked a little bit about the IT infrastructure. It might be less of a problem now in most organizations. However, this was kind of a real pain for the past 20 years. A lot of companies actually suffered from it and at one point in one of the organizations I even had two laptops. One that is like the corporate issued one and my own that is like the vanilla, whatever you went to or whatnot and move around carrying two laptops. But basically this is actually a very important aspect because we need to make sure that developers have access to the tooling and infrastructure. They need access to be able to do their job, right? So, track success through metrics that are designed with an open source environment. So I gave an early example about a metric that was kind of tracking the line of code that developers do. So another one was, so all my teams I had developer, well, I was responsible for multiple technology areas like cloud security, graphics, operating system and libraries and so on. And for each of these different areas, I had one person do kind of janitor work on all of these different projects. And this is basically going and they call it an open source like carrying wood and giving water or whatever just like low hanging fruits. Just go to the code base and see what are the easiest things to fix and spend time fixing it, okay? So that person at the end of the year has a minute like 600 patches, which is like incredible. But these are like super easy stuff. Like we're talking like 30 minute, 40 minute per patch to, you know, and plus the associated time work to get it up. But then you have like the more serious senior developer they probably have done like 100 patches. And out of the 100, there's like 20 that are super critical that took the majority of their work throughout the year, right? So then if the metric is the number of patches, the janitor, the code janitor, which is the person that does easy low hanging stuff should guess like the price, right? But in terms of criticality and functionality, it's the other way around. So kind of putting the right metrics in place is extremely important because it will help drive the right behavior. Follow a lightweight and tailored approach to a contribution approval. So in what that means is it's very hard to get contributions out from the company if you have a very complex approval path. So for example, if you are an engineer, you need to get your manager's approval. The manager has to go to the director. The director needs the C2 approval. Once the C2 approves, it has to go to the patent office. The patent office approves, goes to the legal counsel and then you're out. This approach doesn't work, okay? So we figured out a path where based on the type of contribution you're making, you might have a different approval path because the whole idea of the hospital is to facilitate the use, the consumption, the contribution, and so on. So I'll give you an example. If it is a simple fix, basic functionality, just the engineering manager needs to approve. Easy. You issue a ticket in JIRA or whatever internal system you say, I want to get approval to contribute this functionality and you choose the type of functionality. Say, small fix just kind of for discussion purposes, right? And then the ticket goes to the engineering manager and most likely they will reply to it within an hour or two, right? If it's a major functionality, it goes to the, let's say, the engineering manager and the director. If it is internal code that we're planning to open source, then it becomes a different story, then it might go to the legal counsel, right? So there are a lot of ways that you can structure the approval path so to make it super easy and less bureaucratic to get code out without having to need, you know, six, seven different approvals for every single patch. And one of the things I've done in my teams in different organization was get a blanket approval for all developers working exclusively on open source. So at the beginning of the year, I know these 10 individuals are working 100% on the links kernel. I give them approval for the full year and we're done. Just go. Otherwise your legal counsel or whoever overseeing compliance or whatever, they will get hundreds of tickets every day and that's unmanageable. Yeah. I'm sorry, how much? If you're made processes for small contributions, sounds great, but also seems to be counter to the requirements of the entire industries and the organization. So I'll give you a parallel. So I'm not very familiar with the finance industry, but I was working in the telecom industry. Okay. So I worked for Ericston for five years. I worked for Motorola for two years and all of that on the infrastructure and mobile site. Okay. And the telecom industry, you know, we thought we were very special. We're like, you know, we're highly regulated industry. We have to deal with FCC. We have to deal with us. We have to deal with that. And at the end of the day, it's just software. There's not much to it, right? And I think from that specific perspective, and again, not knowing the specifics of what you have to deal with in finance because I don't have that vertical experience. I mean, I come from telecom and infrastructure, but basically the whole idea is how can we facilitate the use and contribution? Okay. So that model that I presented now, which is kind of expedited approvals, based on the type of contribution, you may take that and again, I don't know what your specific internal kind of regulation you work with. And as an example and try to figure out, okay, well, there's this idea of providing, depending on the criticality or the functionality provided in that contribution, let's figure out a way to minimize the number of approval because if it's like B9 or like a very simple fix or whatever the case is, there's no need to get the attention of five or six people across the chain to get it approved. And that also delays the approval. So the whole idea is like, we need to keep going and we need to keep going fast. But again, I don't know if this is your question because I don't have the specific. It's both, yeah. Because there are cases, yeah. Exactly. And actually, I will give you the background on that model, so I actually created that model maybe like 12, 13 years ago. And I was working in a company and I had a team of six people working on these different stages. And basically, the ticket was going from one of my team member to another. And overnight, I lost everybody due to massive corporate restructuring. And then I created the ticket. The ticket comes to me as, because I'm taking the role of the other person. I review it and approve it. And then it goes to me because I'm also fulfilling the function of it. And it was, actually I have a slide where I like, I have like six of my pictures and it's like going from this guy to this guy and this guy is the same, okay? So the whole idea is, how can we get the approval as fast as possible? And I'm not talking about skipping any type of two diligence, just in many cases, not all the due diligence need to happen for every single case. So, and when you think of that, I don't know, maybe in security, you may need to do additional export control checks, right? So maybe this is something you can not skip. So that's kind of embedded in every single check, in every single approval that you have to do. But there are other things that, there may not be a need to include the patent lawyer on any contribution because if that piece of code was created and intended for contribution to start with, there's no need for that. You may need to include the patent lawyer only if you have internal code that existed before as a proprietary code and now you're open sourcing it. So there are different use cases and once you identify these major like four or five cases about 85% of the tickets will be funneled into these. There's always like small, very small percentage of cases that doesn't fit the mold across like these major categories and these are dealt on a case by case basis, but it should be as streamlined as possible. And the finance industry is kind of in this phase where let's take the telecom industry today. Today you pick up your phone, you make a call. That call today would not happen if there was no open source and analytics period, right? So it's the same thing for automotive today. You go buy a range over a BMW, Toyota, a Nissan, a Jaguar or Ford or any of these cars. All the infotainment system in the car is actually powered by Linux and open source. So, but it took them maybe 10 years to get to that point. So now the finance industry for the past few years has been kind of more active in the space and trying to do and help the digital transformation through the use of Linux or open source in general. And you are at that cusp where you're like, okay, now we are at the scaling point. Now we need to scale. How can we do that, the adoption and the contribution at an efficient scale? Because previously, and I work with different institutions but on the AI side in finance. And there are different pockets of individuals and teams working on open source, but now a lot of these banks and investment organizations and others, they're actually setting up an hospital and they're going into that scaling. So you need to figure out a way to maximize the efficiencies. And what's really interesting is there was a statement from the CEO of Morgan Stanley, which is, he stated that the largest category of jobs in Morgan Stanley, the number one largest bank in the US is software developer. So they have more software developers in the bank than any other job category. So the scaling issue, I think, is the thing you're gonna be dealing with. Sharing information across the vision is actually a pain across multiple of the companies I worked with. So in fact, I worked with one company where I actually had to sign in the aid to share information and discuss with other people working in the same company in a different division. True story. And it took weeks. So sharing information is actually critical especially if you need to be able to use and apply these open source principles internally to be able to really successfully do it with other people, other companies and competitors. And I think I touched on this where you have to contribute to strategic or strategic project where we use dozens and hundreds and thousands in some cases of open source projects. Nobody has enough resources to be focused on all of them. So we need to figure out a way to understand what are the most critical projects that we rely on and focus our efforts on these projects. I'll locate time to open source developers to meet their upstream responsibilities. I think I touched on that. One of the main factors why open source developers need their jobs is because they get forced into a situation where they don't have time to continue their open source upstream responsibilities. So we need to be respectful of that and make sure that if somebody is a maintainer or a committer in a given position and which is why we hire them as an organization, we need to allow them to continue in that function and allow them to have time to do that part of their job. Partner with product team on our streaming code. So as OSPOS are a cost center and I've lived through this for so many years we rely on funding from product teams. So everything that I do as an OSPOS leader in any of the OSPOS I've managed and set up has to match and align with the benefit that we're producing for the product team. Otherwise we become irrelevant very fast and then when the new year comes in you're in for a new round of funding and then you find yourself as normally. So anything that these OSPOS have to do in terms of innovation and technology has to align with the specific needs of the products or services teams. Yeah, not developing open source talent is very critical. I was working with an organization where we had two or 3,000 developers up to a company where we had 60,000, 70,000 developers and no matter how much resources you have you cannot go and hire all the open source developers out there. So you need to find ways to improve the open source competency and both on the technical side in specific technologies and also on the methodology and compliance and other aspects of open source for off your existing engineers. So developing internal training program, developing mentorship program, pairing developers together, sending in developers to events like this one just to kind of increase and use it as a training opportunity so that you're not just able to hire developers but also you need to improve the skills of your existing developer and bring them up to par to become cometers and influential in the specific projects you're involved in. Partner with product team, I think I mentioned that. This might be redundant. Allocate open source developers to meet the upstream responsibilities. And I apologize for the redundancy. This is actually the first time I do this like an hour and a half. So there might be a slide or two that actually we've been through them in different places. Or I'm using the strong back and forth same slide. Develop open source talent internally. I think I mentioned this now. Creating mentorship program, this is extremely essential. And we've done this in a couple of companies where every senior developer typically is assigned two, three, four different junior developers and the senior developer has part of what they do as part of mentorship is they review all the patches prepared by the junior developer before they actually go and submit them. So that gives them kind of an internal review before they actually go live with it. And that worked extremely well where we're able to assign a few engineers to every senior developer and putting a time limit of three, four months depending every company is different on the lengths of that mentorship. And ideally when that mentor graduates then they're able to submit patches without kind of internal supervision. And today in the Linux foundation we even have the LFX mentorship program where individuals are able to nominate themselves to be mentored as part of kind of a larger program that we have. So this is something that didn't exist back then but it exists today. So I would encourage you to look into it. So it's part of, if you look up LFX mentorship so you'll be able to land directly on the homepage of that project. Participate in host open source event. This is extremely helpful. I mean, for the first few years in my career I was working for the organizations that recognize the importance of this. And I was in my early 20s and I was like hosting events of like 20 people showing up to the office on Saturday making sure there's like the food is served. We have pizza, we have like hats and like super things like that. But I mean, it brought us closer to the community. It brought us closer to the developer to understand how they think what's important to them. They started to see us in a positive light and it was kind of free learning experience. Certainly today, 25 years later it's a different environment. We have like these professional events and so on. But one of the things I do with a lot of the startup I work with is like go to, figure out what meetups are happening in your city. Are there any meetups like for Python? Are there any meetups focused on pie torch? Is this important to you? Offer to host them? I mean, there are a lot of things like that that are small but have really big significance and it kind of helps build bridges with the different communities of the projects. So by the way, thank you so much for not leaving yet. This is pretty awesome. So massing open source, like to become really a master in any given trade, similar to open source. In open source specifically, you need to be very good at three things, right? Using open source, complying with the licenses and contributing. These are really three essential building blocks for any organization to become a very strong company in open source. So when you look at companies like IBM or Google or NVIDIA or Intel or any of these really massive companies that are known for their open source activities, they are extremely, extremely good at all of these three building blocks, right? So for consumption, there's really a list of recommendations you would do to improve your practices there, similar to compliance and contribution. And there are really three core principles to embrace when working with open source. The first one is we cannot hire as any given organization, you cannot go hire all the smart people in the world. I mean, you need to figure out a way to collaborate with smart people in other organization, smart people at universities. You need to collaborate with people that are working for a competitor company. And the way to do that collaboration is under the open source umbrella. So we can do that. The second principle is open source R&D creates significant values, meaning there's billions of dollars of open source investments that exist today. You know, hundreds of millions of lines of code. In my umbrella, I've been in Foundation, LFA and Data and the past four years, we've created 23 million lines of code across 54 projects. I mean, this is hundreds of millions of dollars available in AI investment to any company. And the value of your internal R&D is to leverage that. You know, your internal R&D team should be sitting and thinking, you know, there's all these thousands of components, these hundreds of open source AI libraries and tools and framework. How can I use them and benefit from them in building whatever I'm doing for my own organization? And the third principle is kind of in a different sentencing or different words is like they're not invented here syndrome. Like you don't need to create a project to benefit from it or to use it. A lot of companies excelled at benefiting from project that they've never created and they came in late to the party, right? So you can benefit from a project you didn't create, you can participate in the community and become a leader in it, even though you were not the principal author or creator of that specific technology. Another, some infographics you can look at later. So in terms of resources, there's like as I mentioned, there's a bunch of books.   You can actually go to the Linux Foundation ad-ex platform. A lot of the courses we provide are actually free. Developers or participants need only to pay if they want to take the test and get the formal certificate. But outside of that you can audit a 20 hour course over the period of like two weeks and study and get all the knowledge without having to pay anything, right?  And as I mentioned, I will post my slides and on my LinkedIn. And if anybody would like to get the actual copy, please send me a note. My email is my first name, Ibrahim at linuxfoundation.org and I'm more than happy to share it. So thank you.