 be dominated by one group or be totally biased. For example, Wikipedia in Japan, Wikipedia in Croatia is dominated by a single political group. Then I went on to have an awesome conversation about how we collect and use big data, affects the genders differently. And then over Glass of Wine I had a conversation about managers and their political beliefs and how that can affect how they treat their teams. And all of those conversations are gonna stick with me. They're gonna change the way I think, they're gonna change the way I act in the future. And we can only have those here. So I'm so excited to be here. So my goal with this presentation isn't to like impart a bunch of wisdom on you. It's to like start those conversations. So I'm hoping that the ideas that I give you today, you'll go on and have a conversation over lunch, you'll have a conversation tonight over Glass of Wine, and we'll all learn a little bit more. We'll all go home thinking a little bit differently and we'll create awesome open source programs offices so that we can all create work better together. So that's my goal. So more and more people have been asking about open source programs offices lately. I've talked to large retailers, I've talked to banks around the world, I've talked to automotive companies, and they're all asking about open source and about open source programs offices. And my first thought was like, wow, didn't we solve this like 15 years ago? Like, haven't I spent my career doing this? Like, didn't we do a good enough job? Did we not give them the tools so that they could just start one? Like, there's still all these questions and still people thinking about it. And the more I thought about it, the more I thought, well, maybe there's more to it. Actually, I wanna take a minute. I'll go back a slide, but I don't know how to do it with my little fancy clicker. I want each one of you to think about an open source programs office. It can be the one that you work with, it can be your ideal dream open source programs office. It can be what you imagine an Ospo to be if you're here to learn about Ospo's, but take a minute and think about your open source programs office and like, what does it do? Where does it live in your organization? Who's a part of it? Okay, now that you have it in your mind, I'm gonna ask you questions about it later. So as I was thinking about all these Ospo's and like, are we really like reinventing the wheel every year, like, or have we not learned anything? I thought maybe creating an open source programs office is like riding a bike. So when you learn how to ride a bike, some of it is about bike technology. And bike technology has definitely evolved over the last 100 years. So you know, when they first started, you got these big metal or wood wheels, they didn't transfer the power between the person and the wheels very efficiently. There were no handbrakes, there were no training wheels. So all of these are things that we've evolved over time that make biking easier or better. But everyone still has to learn how to ride a bike. Like even if you get the fanciest bike with training wheels, you're still gonna have to learn how you balance, you're still gonna have to learn how you steer, you're still gonna have to figure out how to pedal. And I don't recommend that you take the latest fanciest e-bike and learn how to ride, perhaps like stick with the training wheels. So I think Ospo's have evolved in the same way. So I think Ospo's, here's what I was gonna have you imagine your Ospo, keep it in mind. So Ospo's have evolved in two ways too. They've evolved with the technology, so how an open source program's office, like what tools are available to it, and each individual Ospo also has to learn how to ride their bike. So think about your Ospo, shout out, what does your Ospo do? Like why does it exist? What does it do day to day? For your organization or for you? Empowers developers, empowers faculty, makes things easier, defines strategy, brings people together from across the whole organization. Tries not to cry and try to form policies. Maybe we can learn from each other in that one. All right, so Ospo's do all these things. And as an industry, we are evolving our open source program's offices. So we have tools now that like, we're trying to define policies, you can actually go out and look at several other policies. We have, used to be the first thing you did was look and see what software you're using. We now have software that will automatically detect that for you. So as an industry, we are evolving, we are learning lots more. And I'm gonna tell you about a handful of things that I've thought of that we've evolved as an industry. But I really would encourage you at lunch, you know, during other presentations, think about the things that we have evolved and think about ways that we could continue to evolve to make it easier for these new people. So one of the ways I think we've evolved is our thinking on licensing. When open source software first came out, how many people were around in the year like 2000, 2005-ish, all we talked about was licensing. And everybody was an expert in licenses. I took a copyright class at my local law school and I knew all about licensing. Thankfully, like we have a much better understanding of licensing. Now we have a lot of shared knowledge and information about it. We have organizations like the OSI, the open software initiative that help define what is a standard open source license. So we've come a long ways. So people getting started in open source now don't all have to go to take a legal class at their law school or pretend to be an attorney. Detection is another area that I think we've really evolved in. When we first started with open source software, I was at Hewlett Packard and we wrote a tool that's now been open sources phasology to actually detect open source software because it was very manual. Now we have tools like, you know, commercial tools like white source that you can buy. So how we find what we're using has evolved a lot. Another way that we've evolved is like understanding project mechanics. I think when open source first started, each project was a little different. Nobody really had an idea of figuring out like is this thing real? Who works on it? Now we have like standard places to put the source code. You can use GitHub or GitLab. We understand what a contributor is, a maintainer is. You can go and look and see if the issues are active. We have the whole chaos project which is helping define metrics. So we have a much better understanding of what it means to be a project and how to evaluate it and how to interact with it. We have much more advanced funding and support for open source software projects. So there's foundations like the Linux Foundation which puts on events like this. The Apache Foundation which helps with all those projects. There's, I know Microsoft supports dozens of open source foundations and open source projects. There's also additional efforts that are just coming out now just evolving in the industry of how do we support that individual open source software project maintainer? So for example, we've joined the FOS Fund effort. So every month Microsoft gives $10,000 to a project that our employees pick and we give that through GitHub sponsors or an open source foundation to an individual. I think that's still, that's still growing. Like we're still learning as an industry how do we support individuals who are working on open source software? And so those were just a handful. A handful of ways that our industry has evolved. So I don't, I'd love to hear like just two or three from you all and then I want you to continue that conversation later. What's another way that we've evolved as an industry? So if someone was gonna start an OSPO today, what do they have today that they wouldn't have had 15 years ago? They have more people to talk to. So there's a community like this. There's a whole conference around open source programs offices. A lot more training. So there's free training online. There's training you can take at universities. A lot more training. One more, more understanding of best practices. And lots of talks here like, you know, I went to talk yesterday where Goldman Sachs talked about how they just started their OSPO in the past year. Like so a lot more places than people you can learn from. So individually I think creating an open source programs office is also like riding a bike. So you, no matter how much you have, how much training you have, how much best practices you read, you still actually have to do it. And your organization is probably not identical to any others. Your culture is a little different. What your attorneys are comfortable with is a little different. How your software developers work and their environment is a little different. Why does it stop working? So I think one of the first things that individual OSPs have to do, no matter what tools they have available, they have to know what they're using. They have to know what open source software am I already ingesting and what things might have my developers open source. And that's the very first step that they need to do. And I think it's often the step that they do to prove that you actually really need an OSPO. You really need an open source programs office. At Microsoft, we are using 60,000 different open source software components across the company. And if you count each individual use, because each one is used in more than one place, it's like nine and a half million instances of open source software usage that we are tracking. So if there's a security vulnerability, we can immediately notify that team. So the first step is what are you using? The second step people get to is like, they immediately decide that everybody has to ask for permission for everything, right? Like, oh my gosh, there's this open source stuff, we don't know what we're doing, do not use it unless you talk to me and talk to the attorney and like let's make sure we know what we're doing. Eventually that evolves over time to a spot where you set guidelines and policies. So you can actually, you know, you learn enough that you can say, it's okay to use open source software in these circumstances, or it's okay to use it with this license, or it's okay to use it internally, just don't ship in a product without talking to us. So I think another major way, each individual OSPO has to get to that point on their own, like and figure out what the policies are for their organization and what they're comfortable with. And then I think OSPOs grow to where they're helping and encouraging their employees to contribute more. So like at Microsoft, we created a mapping your open source career checklist that people can look through and decide, figure out how to add open source to their plans and how to talk to their manager about using open source. We have a series of workshops about contributing to open sources of Microsoft employee, what does that mean? What does that look like? Are you allowed to do it? Absolutely. We have like, how do you grow your community? How do you enforce a code of conduct? Because having a code of conduct is good, kind of easy to write one, lot scarier to actually have to enforce it or do something about it. And then companies start doing outreach. You start coming here and sharing your story about how you created an OSPO. You start sharing the project that you're working on and the project that you did open source and hoping that others come and contribute. Because as we heard from Selena, like if you don't have a community, it's not really open source until like others are also participating in it. And so open source programs offices evolve over time. They start by using open source, then they eventually get to contributing back to those projects, which is much harder than you think. There's like a huge, what's the syndrome where you think you're not good enough? Imposter syndrome, yes, there's a huge imposter syndrome. And then it gets to creating new open source and open sourcing things. And I found the more the company is a software company, the more comfortable they are with that last phase. The less they're in the technology software industry, the harder that last phase is. So that is what I wanted to inspire you with today. Because I think creating an open source programs office is just like riding a bike, right? So I encourage you to go out for the rest of the OSPO con and talk to people about what it means to create an OSPO, what it means to run one. How are we evolving? How are we sharing this knowledge? And how are we making all of these new companies? Because we really are seeing a lot more new companies that aren't in the software industry start to create OSPOs. How are we helping them? So thanks for joining me. And please go learn lots and start great conversations because that's why we're all here.