 It's my privilege to kick off the Ospo-Con track. Hanna Jimenez is here. Hanna is our fearless leader on the Ospo-Con tracks as well as just really getting all of us together from the Ospo perspective. I wanna start off by saying the last four years have been anything but boring. Would you agree? It's been an incredible last four years. Pandemic and then big macroeconomic changes. And I don't think we are the same people that we were in 2018, 19. I know I'm not, I'm forever changed. And Ospo's are forever changed too. We've evolved, we have to evolve. We can't be the same Ospo that we were in 2018 and 19. We're looking at the world differently. We have different challenges today. And so hopefully you will get a chance to see some of the challenges that I see and some of the opportunities I see. I've decided to focus on four of them. And I welcome you all to add new challenges that we should also consider. So my name is Nithya Ruff and I run the open source program office at Amazon, not AWS. We support all of Amazon as a team. We support the AWS part which a lot of you are familiar with because that's what we serve developers and where developers work. But we also support the stores, the devices, organizations like Fire TV and Alexa, et cetera, and Prime and Music. So the entire spectrum of Amazon companies is what we support and very proud to support that. Okay, I want to start off with the history of Ospo's because I think it's important to kind of see where we came from and why Ospo's were created. To me in the 1990s, I started working in open source in 1998 at Silicon Graphics. And so to me in the 1990s, you had the early tech companies and tech providers like IBM and Sun and SGI and HP who started using open source and shipping open source based servers and products. And they used to have something called open source strategy office or the Linux Development Center or open source technology group. So they weren't quite called Ospo's but they did Ospo kind of stuff. They helped navigate open source across the company and teach people how to work with open source and kind of acted as a liaison between company and culture community rather and community and company. And then in the 2000s, building upon the fact that you had a lot of free x86 servers with Linux running around and huge amount of compute capacity, you have companies who are now called hyperscalers, Yahoo, Twitter, Google, Facebook, et cetera. Start building humongous data centers at hyperscale, creating production level data centers to fuel their services. They built it upon the shoulder of a lot of open source. So a lot of open source and infrastructure. So you start seeing them create something called the Ospo. And the Ospo's in those days were responsible for open sourcing some really terrific software like Hadoop and just a lot of Cassandra came out of these companies and GraphQL and React Native from Facebook, et cetera. So there was a lot of good work done by these Ospo's. You see people like Simon Phipps and Denise Cooper and Eileen Evans and others. Part of this vanguard of leaders in open source program offices in those days. Then in 2023 right now, you find that open source program offices are everywhere in every vertical, in public sector, in universities, it's become the norm. It's become a well-established concept. And you have groups like the Ospo Plus Plus and to-do group who really take time to connect all of these Ospo leaders together, help them grow and help them become better Ospo's as a whole and they run teaching sessions, mentoring sessions, et cetera. So it's become a well-established concept now. So what is an Ospo? I keep talking about this four-letter acronym. Ospo, I think most of us know it, but just to ground us, Ospo is designed to be the center of competency for an organization's open source operations and structure. But it really varies. Each Ospo does what their particular organization needs and should. It should really fit into the needs of that particular organization. An Ospo in a university is different than an Ospo in public sector is different than an Ospo for a company like Amazon is different than what it used to be when I was at Comcast which was more of a digital transformation company serving media and entertainment. And you find that open source in academia is really growing and Jacob can attest to and take a lot of pride in the fact that Johns Hopkins and Carnegie Mellon and Cross which is a center of research in open source software at UC Santa Cruz which is now becoming a full-fledged Ospo for UC system in California. This is incredible and they're taking on an RIT, they're taking on the mantle of open science, open data and universities used to be kind of the IP and patent very rigid organizations from an innovation perspective and now they're looking at other ways to innovate and flourish. And you find in public sector also cities like Paris, county, country governments, United Nations organizations like the World Health Organization have Ospos and in fact the European Union recommends Ospos as a new tool for governments. Am I getting this right? Good. And it is becoming, I love this diagram because I think it's creating a common language for us to talk across these different constructs across universities, public sector, academia, foundations, companies and you know who your Ospo Connect is in these organizations and they help you navigate that organization. They help you collaborate across these organizations which I think is a beautiful language that we've created through a common way of looking at Ospos. And when you look at the maturity model of Ospos which comes from the Linux Foundation's deep dive into Ospos, you find that all of us took this journey and sometimes we stop in various stages. I also find that various parts of our company are in various stages of this adoption. And so it's not always even, oh yeah, we climbed the steps and we are now leaders. What I find is we all start with adoption. Sometimes companies don't know that open source is coming in or are oblivious. Sometimes they're very conscious that open source is being consumed and they're consciously consuming it. Once you start understanding that open source is in your company, the next typical step tends to be creating policies on how we use it, how we consume it, what licenses are okay to use, how we'll distribute it, how we will release it. And so legal teams start getting involved. But you need an organization between the legal team which is often one or two people and we don't have enough legal experts actually in open source. And then you have a huge pool of developers, right? So typically what ends up happening is development organizations bottleneck into the legal team in early stages saying, hey, can I use this license? Can I do this? Can I do that? And legal is recreating policy again and again and again and answering the same question again and again. And one of the big reasons OSPOS come into existence is to act as this development advocacy organization so that they can field questions from developers, understand developers' needs, how they're using it in their production and technology and to then translate it into questions that need to go into legal or questions that need to go into public policy or into marketing or into business decisions. So open source program offices really act as a developer advocacy organizations to help developers with policy, process, automation, so playbooks, et cetera. And cultural transformation, as George and I were talking about is really educating all of these other organizations in the company, purchasing, legal, et cetera on how open source norms are and what's acceptable and what's not acceptable. And then you find inevitably when you use open source and you have access to source code, you want to modify it, you wanna fix it. And then you want to upstream that fix or you want to contribute back into open source. And that's when engagement starts happening and developers are becoming part of the communities that they're contributing to, that they're using, that they're part of the upstream work in. And that creates a lot of new norms for the company. How should our developers participate in this community? Should we make time for them to do open source and which community should be involved in? And we struggle as companies to justify the amount of time developers need to spend in working with upstream communities. Often the impact is not immediate and it's not in terms of revenue or cost. And so we kind of say, I don't know why so and so should have to spend so much time working in upstream when they can be working with customers or with revenue bearing products and features and functions. So I'll suppose get into the business of advocating again with businesses to say, you do need to invest in upstream. You do need to work with your dependent upstream projects. You do need to invest in developers working and spending time, becoming a part of that community, building trust, fixing things, chopping wood, lifting, bringing water, fetching water, et cetera. And the last stage I would say is typically leadership and some parts of our company are leaders I think because they are not only contributing back and engaging with their upstream communities but they're releasing code and they're releasing original work done in the company because they say we want to make the world a better place and we want to put this back in the world so that others can benefit from the work they're doing. And that is really the objective for a lot of us I suppose is to get there, not just consume but contribute, educate, make cultural change happen, create the connection between community and the company or the organization and really give back and really make the world a better place because we are here. So having said that, what are some of the challenges and opportunities that face us in 2023 and beyond? I want to start with the first one which is developer experience. And the reason I start with this is because Diego and I are both part of a larger developer experience organization at Amazon. And for many, many years when I worked in an OSPO I would think of OSPO as more risk mitigation and that we are all about risk and about education. But it occurred to me that we are also about making it productive and easy for developers to do their best work. And that risk mitigation does not have to come at the cost of toil and time and delay and developers having to stop their flow and filing a ticket to ask a question from a compliance perspective or from a cultural perspective. So we started looking at how do we reduce toil? How do we automate some of the low risk, low judgment items into the system, into tooling, into workflow? So we don't have to have developers stop and file a ticket. Can I consume this or stop and file a ticket? Can I contribute this? Or can I release this code, et cetera? So make it easy for them to do the simple things. And tooling is what a lot of OSPOs do also because there is no bespoke open source tooling today. For every language, for every company's custom workflow you need different tooling. So we end up doing a lot of tooling and a lot of process and mechanisms so that the toil on developers to stop and ask and stop and consume is lowered. Because I mean modern software development is about using open source. It's about engaging, it's about contributing. And if you make each of these steps heavy and toil-laden or difficult or causing delay, you really have a very poor developer experience. The other thing we started working on is empowering developers to more early in the development process, asking questions and having tools such that they can discover the level of risk or the level of issues in open source they face so that they can solve those questions early. They can file a ticket early, consult us early and solve those problems early in the development life cycle rather than wait until a product is released or they're a week away from something. And education and playbooks is something that's so important from a developer perspective as to why we want them to do something when they should come to us, when they should resolve this issue themselves. I think it saves hundreds and hundreds of hours of people's time to wait. And most OSPOs, by the way, are usually small, small groups of people. They're usually, I think the OSPO survey says most are between five and 10 people on average. And we are about 15 of us, but it's still, if you're serving thousands and thousands and thousands of developers in a company, you don't scale. So all of these steps really help us empower developers and to scale compliance and education and process across the company. The self-service piece has become more and more important for us also. And then I think a lot of companies do this at Comcast. When Brittany and I worked together, we had champions and ambassadors across the company because we can't afford to do everything ourselves and we want to elevate the knowledge level in each business unit, in each organization of people who know what open source is and can advocate in their business unit and work to reduce the toil for that business unit. And by the way, they also have really detailed knowledge of how their business uses open source. So they bring that contextual knowledge, high context, high judgment to doing the work. And so we've been really investing in champions and Diego is part of that program and we have, I think about 200 champions now and we hope to get to a thousand so because we have like 90,000 plus developers across the company, so you can't scale with what we have. So those are some of the things I think OSPOs are doing today, not just mitigating risk but balancing risk and developer experience as a whole so that developers can do their best work and have high impact. And security is the other area, I think that we've all been getting involved in. Can you show me your hand, raise your hand if you are actively working with your security teams in your company? Exactly, exactly. We've become best friends with security and I think OSPOs have to be the cultural guide to open source. Security is an expert at what they do but navigating open source security is a different game altogether. You have thousands of producers of open source, vulnerabilities are disclosed differently, how you patch it is different and how you navigate and work with this is different. So becoming a best friend to security and working with them and tooling is extremely important. So I think everything from working with your company and educating them on why they need to support upstream projects, why they need to support things like open SSF is advocacy work we do. The second thing is not just screening for license but screening for security, screening for community health and again really bringing that knowledge to the tooling organization and making sure we're screening a broader set of things. And tracking has become such an important element, right? I mean if log4j is used in, I don't know, 10,000, 15,000 places across your company knowing where it's used and how it's used is extremely vital information when you are given that order to patch all of those servers or all of those applications. And it's also important from a Biden directive and from an SPOM perspective, but it's good hygiene to know where you're using your open source dependencies. And then keeping your software updated and fresh and then patched. I think the survey from Synopsys said that a lot of times a patch is available, the vulnerability is known, a patch is available, but the consumer has not bothered patching and that has caused exploits like heart bleed, et cetera. So keeping on top of patching is something that's so important. And then security and OSPO partnership, we in our OSPO have increasingly been working with our security brothers and sisters and making sure that we understand their perspective when we manage tools like GitHub and manage tools across the company, but also provide them with knowledge of how open source works and what to look for and how to engage with communities, et cetera. Who has heard of chat GPT lately? Who hasn't heard of chat GPT lately? So it's, I mean AI has been around for quite a while and machine learning has been around for quite a while, but all of a sudden it's front and center. And it's front and center for us. We get questions on use, can I use it as a service to generate code or do something? Where can I use it? And how do I get the source? What was the model trained on? What's the license for that source? Who owns the copyright for that source? And so we are having to guide developers on safe use and create, our legal team has been working to create a policy around this. When can you use it? When can you not use it? How can you use it? And things of that nature. So OSPO is a smack in the middle of all this because it seems like a logical place to come to. If you're going to this organization for license use, I wanna ask them about data sets. Can I use this public data set? Can I use this model? Can I use this service? And so we've been getting into that. We are also clearly getting into compliance and due diligence, right? What should we look for to allow people to use a data set? What should we look for from model perspective? What's okay, what's not okay? Thankfully we have some really educated legal teams that we are working with who have been helping us do the due diligence, but we need to standardize these processes because the tsunami is coming. The questions are going to escalate and we need to have standard operating procedures in place for all these questions when they come in. And lastly, how should we participate in AI? Should we contribute data sets? Should we contribute models? Should we release them? How, what license should we use? What construct should we use? So all of these questions, they're emerging fast and furiously and OSPO's need to start getting ahead of these considerations. And participation also includes policy, education, participating in policy, because there are a lot of regulations coming at us from Europe, from US, and we need to understand what that means and whether we need to advocate for developers in our organization and developers in open source and make sure that their freedoms are continued. This is one that's been around for a while and will continue and is continuing more and more to me with the macroeconomic climate especially and shifting investment levels in companies. I always think about, am I articulating the value of what we do inside the company? Am I making an impact? Is my team and I making a business impact? Are we helping the company? Are we understanding what the mission and business objective of our organization is? And are we tying our work to that? Because you don't want to become irrelevant, you don't want to become just a cost center and it's easy for OSPO to be looked at as a cost center and the first place to maybe eliminate or change. And so the chaos group does a lot of good work on metrics, but to me it's articulating what business impact are we making by different businesses, how are we helping with cost reduction, toil reduction, time to market, enabling new partnerships in the company, helping teams in the company navigate foundations, become members of different projects. How is it helping our brand from a reputation perspective, from an innovation perspective? So measuring and communicating this regularly is such a critical part of the OSPO job. It's very easy to get buried in the work that we're doing and not to do this. In our case, we have business reviews every quarter, so we constantly work to refine what we are communicating in those business reviews and how we are demonstrating impact in the company. I wanted to kind of end with a little bit about the Amazon OSPO because I said it's important to understand the business context in which you live and what you serve and what are the objectives and outcomes that the company cares about and shape the OSPO and the open source organizations in your company to serve that. So in our case, there really are three reasons why we invest in open source as a company. One is we build on open source extensively. Across the company, we use a ton of open source. I think some of the surveys say companies use between 70 and 90% of their stack is open source. I dare say we are in that average. Whether it's devices or AWS, we absolutely are builders, our developers love open source and build with open source. And customers, especially on the AWS side, want us to be a good platform for open source development and to support open source projects that they love. On the device side, which is consumers, they care less about what we build on, but they care about innovation. They care about great experiences and time to market. So customers do indeed choose open source. And the last piece has become more and more important to us, which is that the digitization of the world depends upon open source and we have to sustain it. We have to make sure that it's healthy and that code is healthy, communities are healthy. And so these are the three pillars that guide us in terms of why we do open source. Just very quickly on the build on open source side, since the early days, open source has been core to what we do and it's how modern development works. So we support our builders, our developers and we support the use of open source across the company. Customers, I talked about the fact that on AWS and the other side, they use open source. And frankly, our partners on the devices side, whether it's a semiconductor partner or an ODM want to collaborate with us and open source is a great way to collaborate across that chain. And the cloud, if it's your computing platform of choice, you want it to be easy to use open source. And the last one, we actually have a new leadership principle called with success and scale comes great responsibility and we want to leave the world a better place. And so we do want to be a good citizen and sustaining open source is critical to us, both selfishly as well as because the world depends upon it. And so we are on a continuous journey to be a good citizen of open source. The to-do group survey, I believe is the 2022 is available and the new one is coming up and Anna will probably share that in her talk. Other resources, there's a deep dive into open source program offices on the Linux Foundation website. And selfishly, I want to plug the book, Open Source Law, Policy and Practice, which Amanda Brock edited and I contributed chapter 19 which is on Ospo's. And I think it's a great reference book. We're doing book signing at 5.30 tonight in the expo hall. And if you want to do more deep diving, there's a security panel later this afternoon in room 211 that will go more into open source security. So if you want a deep dive into that, book signing I talked about and then ask the expert tomorrow if you want to talk more about what we're doing or want to ask me a question, that's a great place to be. And that's the talk. I think we have, how many minutes do we have for questions? Okay, that's what I prepared and I think we should open it up to questions and have a discussion. Yes, I have my good friend Suzanne here who deeply works in that area. So I will call upon her to comment as well. And Suzanne, this is a... So the question was, how are you demonstrating positive brand impact and I guess perception surveys? So we have a marketing team which lives in open source marketing and strategy which lives in the marketing side. So they've been running surveys every year about perception of customers of our work in open source. How important is open source to choosing AWS as a platform? What kinds of things do they want to see us do? And we've been using that as one of our sentiment analysis and brand impact surveys. The Ospo survey, the to-do group survey is a good one because it really shows how developers are perceiving different companies from their open source brand. I look at that and see, are we improving year over year? Are people seeing us more favorably than before? The soft aspects of coming to a conference, people saying, hey, I really like what you guys are doing. You seem to be improving. Clearly articles written about your work is good stuff. But let me ask Suzanne to also comment. Suzanne, by the way, leads open source marketing for VMware and she's been really focused on this area. An NPS survey that is directed to our customers. We also measure perception change in more industry types of surveys and a brand tracker where we ask that specific question. What do you think of VMware as a resource? Is it important to your buying criteria? And then we also benchmark that data in the offensive survey that Nithya mentioned, which is coming from to-do group, which acts a similar version of that question. So we start to triangulate where it lands in customers' eye line, if you will. And while I have observed over the last few years, it started with the sort of, huh, in customers to today where it's like, yeah, I know I expect you to be there, VMware. That is a given. You will be there and you will be a leader. And it's an important part of our overall personality in the market and the open source program office helps to guide a lot of that activity. When I started with the open source program office, I approached it from a perspective, marketing strategy that I call do, be, do, be, do. Which is go do it, go be it. Then go do it and go be it. Go do it and go be it. And after you've done that, then I'll start telling the stories about it. Yes. Because marketing likes to tell the story in advance of the delivery. And I flip that on the top. It's like, no, you go be and do. And then I'll come back and talk to you in such a closing office about stories to be told. So if you have any other questions, you can find me afterwards. So I'm kind of adding onto that. I'm curious too. So like that's a beautiful story that how you're able to externally share open source and mission and Amazon and this that, you know, that's amazing. Externally, what about internal shareholders, right? There are people that are signing your budget. So how can we share, there's many different ways that we can leverage, product by these metrics to share with our stakeholders. But what is one particular underlying pattern that we could all leverage to kind of make sure like, hey, our office is relevant in some way? That's a really, really good story. And in fact, it's even more important to make sure that not just developers, but middle managers and the executives are seeing that this is very crucial to innovation and, you know, development in the company. One of the constructs we are using is a business review. Every single organization in Amazon goes through a business review every quarter, month, weekly. We are just doing a quarterly review. And the first page is metrics of, because we live in builder experience, we try to aim at how we're reducing toil, how we're reducing delay, how we're reducing paper cuts for our developers, how we are speeding time to innovation. So it's been more making develop experience really good versus revenue or cost, because revenue and cost is so, so darn difficult to connect the dots to, you know, yeah, because of this upstreaming of this batch, you know, this resulted in this. So we are using quarterly business reviews a great deal. The second way is, frankly, there's an internal newsletter that the open source marketing team has developed and it goes out every month. And I know we used to do that at Comcast. That is so important because people need to know what's happening and what kinds of things we are working on. Third, we do launch announcements whenever we do, just like a product team, we do a formal launch announcement when we introduce a new program. So when Diego introduced the champions program, we did a launch announcement and amplified it to all of leadership and, you know, on open source Slack channels, et cetera, so that people know that we are working on their behalf and we are introducing all these different things. I welcome ideas from others in terms of how are you doing business impact communications in your company? How are you making sure you're heard and your value is heard? Yes, that's fantastic. So the point made was how much money we saved on support contracts because, you know, we were able to access source code and fix it ourselves. I think Sheila probably can attest to that. At Comcast as well, we would say, you know, we are saving X amount of dollars by not buying proprietary software instead buying, you know, an open source, commercial open source. And then if you move further from commercial open source to actually supporting open source upstream directly yourself, you're saving, you know, much more money. So that was very tangible from a financial savings perspective and then the ability to kind of patch things yourself and jump in and do things versus wait for a vendor or wait for someone else to fix things is quantifiable. Yes. So you're saying community maintainers, how can they make it easier for companies to engage? Yeah, so the question is, how can upstream maintainers make it easier for us suppose to show engagement or invest in engaging with those upstream projects, right? Did I get that right? Yeah. One of the concerns I hear from a lot of us is it's difficult to upstream a patch because, you know, I have to wait for the upstream team to kind of include it, have to socialize it, have to, the process is much longer, have to build trust and sometimes the patch that I submit doesn't get accepted, I don't get feedback. And I know the burden is put on the maintainer but I think the more frictionless that process can be for companies to contribute or others to contribute to the process that would be better. I think the onus is also on us to engage early and communicate and work with maintainers to make sure that we are, you know, earning a seat at the table to contribute, right? Because you can't just come in and do a fly-by contribution and leave. The other thing I would say is to teach, you know, people from companies who are engaging with your project to become advocates for the project inside the company and support the project through whether it's GitHub sponsors or to ask you, you know, what do you need as a maintainer and what should we do to support you would be really helpful. We are telling our teams who have strong dependencies upon open source projects to please spend the time to do, you know, blocking and tackling for the project and maintenance work, not just, you know, be someone who throws a contribution over the fence but to actually be a part of the maintenance team and support the group and ask them what they need. Because we depend upon it, but we also want to make sure that these projects get what they need and are supported by us. I don't know if I answered your question. Okay, hey, sorry. Yeah, you can zoom in as well. At what point is the company, I don't know if the smallest company you've seen that has an Ospo, and at what point should I start lobbying for an Ospo instead of having to absorb all of this from the DevRel program? I think any size company can have an Ospo. It does not have to be an entire person or a full team. It can be someone whose job it is to coordinate the Ospo. Anna will also add to it. For example, Netflix I think has a volunteer, a set of volunteers across the company. They don't have a formal Ospo, and they kind of collectively work together on Ospo-like functions. It could be someone in a startup whose job it is, whose enthusiastic about open source, whose job it is to advocate and become an expert at it. And I think, frankly, every startup should be thinking about open source hygiene, open source IP, and open source engagement with communities. But Jacob's going to say something, then we're going to go there. We should talk more. Yes. It's very much related and you just have to think of it like you're one main open source product, like popcorn, or a trino, and then you just start clearing a lot of all the other open source projects. And if you know about things like the security, if you're planning, if you're complying, if you're organizing, you don't kind of think you automatically get asked these questions, and I sort of like weigh a multiple hats in that. But it's basically actually happening. We just don't have the official link at all. Yeah. It's just a gradual journey, but the tasks will always be there and once you sell your software, someone is going to go, whereas my dependency lies in compliance and stuff, very quickly, and then you automatically doing all of the work. And because you know from the open source project, you're going to be doing the all of the work. It's just a little bit. And you get out to bring that label into the organization because it widens your scope of responsibility and communicates that to your leaders that well, there's all the legal things that need to be sorted out, trademark stuff and not the legal compliance stuff. So it helps you to potentially get a lot of complainers to help you with that or at least work with the regular steps. One last piece I'll say is at Sandisk when we didn't have an OSPO, I wrote a one page pitch to our SVP of engineering saying why we need an OSPO. So that may be another thing to do and to do your research and say why it would benefit cockroach labs to have an OSPO and how it will help with brand perception but also with developer experience and other aspects here. Yes. Yes. Don't forget about it. Yes. Because we do sales friction, it makes the customer more comfortable. And that is really important. It's money. It's the path to money. Exactly. Exactly. Don't be embarrassed by that. That's right. I think we're running out of time. Sadly, I want to ask a question of all of you. What other topic should be included in things that OSPO should be thinking about in 2023 and beyond? What did I miss? You can shout it out. Yes. Yes, yes. We need to be the conduit into the company for open source foundations, organizations, maintainers, et cetera. And then back out again, right? Be a guide to open source. Yes. I would love... The to-do group has been documenting that religiously and they do, and I will probably share that. Emma, you had a question or comment. So how you're seeing that work, seeing the champions be successful and broadening that. I would connect with Diego Horquera after the call and talk because he's intimately involved in driving the champions program. In fact, yeah, in all of these details. It's not easy. A lot of heavy lifting. Yeah. Right? Yeah. Yeah. And so... But lots of benefits. But there's a lot of benefit. So thank you so much for being here and I hope this was useful. And I welcome other suggestions for topics that we should include in this discussion of what we should be doing in our 2023 and beyond. Thank you.