 Hi everyone, thanks for coming to my talk building teams for the upstream. So hi my name is Emma, I work on Microsoft's open source programs office. You can find me on Twitter and lots of other places if there's questions that you have after this I'd love to chat with you. I'm happily coming to you from Souk, British Columbia on Vancouver Island in Canada and the land of the Souk First Nation. I am sadly not in Dublin for this event, which I was really looking forward to. I really hope that 2023 is the year that I get to see you all again. So this track is part of OspoCon. So I'm not going to spend any time talking about open source programs office, although of course that's a great conversation. I'm going to focus more on how we build teams, as I said, for the upstream and the opening. But through our mission to enable individuals and organizations to achieve more through open source. As part of this talk, I was using the word good open source citizen. And so just to be respectful of the many ways that other people have described good open source citizenship, I went out and read a number of blogs and other writing about what that meant. And then I kind of thought about how I felt that fit into the Ospo and how I'm thinking of good open source citizenship, especially from my history, which before Microsoft, I was with Mozilla and worked with a lot of open source projects over I think the 20 years that I've been working in open source. And this is where I landed. A good open source citizen is someone who personalizes and prioritizes the success of their community in their individual goals and actions. And so what this means for me is just kind of the knowledge that everyone that turns up at an open source project has a personal reason for being there. It might be that they need to get something patched, a feature added. It might be that they're trying to change the world through someone's mission. It might be that they just want to learn from others. But when they leave that contribution or the day ends, they have left that community a better place. That may be something as simple as having follow the documentation and use templates and follow the code of conduct or maybe a deeper investment, sort of running events and chopping wood and carrying water, sometimes talk about those non-glamorous things that help a community move forward. So that's how I think of a good open source citizen informed by many of my peers in the industry over the years. And I think this is what informs open source community building. So I think, especially from my time at Mozilla, working with community building, the main goal is to attract and inspire folks like this, right? These are the people that make your community a great place to be. They are the people that make your project sustainable, rewarding, and successful over time. So I think that is what all community builders are focused on for open source anyways. And so then I also step back again two more steps and ask myself, what does it mean for a company to be a good open source citizen? Especially from the perspective of an Ospo, where we're not really responsible for any one upstream project or participating in any one open source community, but rather helping others do that. And so I think that a good open source citizen in a company is really good at attracting, inspiring, training, and rewarding employees to turn up as good open source citizenship. And this is what I call or I'll refer to in this talk is building teams for the upstream or building community for the upstream. And obviously the difference between building community and an individual open source citizen and building community for the upstream, made of multiple good open sources, citizens that were successful, is scale. But that's not all. So I think the fundamental difference between building open source communities and building for community for the upstream is the incentivization design. They're both building groups of people, but fundamentally how you do it is a lot different. Fundamentally where you find people is a lot different. Let me say a bit more about that. So in my experience of building open source communities, you know, what you're really trying to do is get that inspiration right, that that North Star shines so brightly that people are drawn to it. People self-select. They join because they intuitively understand the value of their participation, how they might belong, and maybe even looking for such an opportunity for quite some time. So I love the view of these magnets that people are drawn towards. For people working in their day jobs, so, you know, engineering, design accessibility, the draw is maybe magnetic, but the incentivization is different. The incentivization looks more like fridge magnets. So in that the value of being a good open source citizen means that those magnets need to be carefully placed in front of or alongside things that are already drawing their attention. These are the same people that might also join open source communities for all the reasons that we've mentioned, but in the context of their role and their job, it's just a different experience for them. And so we need to think about that as an OSPO. The design, the incentivization for employees to be good open source citizens and to understand the value for them requires a lot more intention. Community, community can't just come from anywhere, it needs to come from our employees. You are given a set of people to work with and it can't just come from anywhere. You can't, for example, decide you're going to try and, you know, work with universities one day or, you know, think about a specific region, your pool is finite in a way. I'm pretty lucky that my pool, Microsoft, is really quite large and talented, but still this is about scale, not about, you know, opportunity. And with that said, and maybe you're already thinking this, the other hard thing is that you're dealing with a fire hose all the time inside of a company. You know, people, especially as they're coming into a company or thinking about the culture, you know, they're working with their manager, they have deadlines, they're trying to ship things, they're trying to get promotions, they're trying to, you know, get through some life activities on top of that. And this is a really important consideration. So I tried to boil this down into what I think the three areas of investment to consider are and that we're working on at Microsoft to get in front of people and to combat that fire hose. So the three categories that are, that the work that I'll share with you is, I would fall under is connection of purpose, a clear value exchange and meeting people where they are, kind of at this fridge door. And so I'll walk you through some of these. So first of all, meeting people where they are. I am literally in front of them. Meeting people where they are. I literally mean this. In training programs, they're already taking. In development workflows, they're already using. In existing communications and places, people are already looking. This is your best chance. So one of the ways we do this is as far as training people are already taking. We try to embed like a very brief Microsoft 101. We have self-training and live versions of a workshop that introduce people. To what it means to work on and with open source at Microsoft. Super high level. Letting people kind of know some of the very small details. But we also supplement that with a GitHub project onboarding tool, which breaks down the steps that people can get involved with open source at Microsoft, but in a way that matches their pace. But which also matches what we see as the logical steps to becoming like that excellent open source citizen. So the first steps are usually around things like joining the internal community, joining channels and distribution lists where our newsletter goes out and that kind of thing. The second steps are about making sure people have the training that is important for their success in open source. So that's things like training, understanding the compliance needs of GitHub and so on. And then as they start to get settled, each category further breaks down ways to get involved and to, you know, join networks of people. That's something they can also track with their managers. Open source is also very much in engineering workflows. The first example is component governance, which detects open source at build time, giving inventory to a central company-wide database, connecting vulnerability data sources and helping alert manager risk. So this is all squarely around open source security risk and compliance, but to be successful in getting folks to take the actions we need, it's embedded in the engineering workflow. It's more opportunity to think about that as well for other things. We also recently invested in a communication strategy. Once we realized that we were communicating in a lot of different places and maybe not with a set of unified language. So with our communication strategy now, we're clear about how, when, and where we communicate topics of open source. And specifically the locations of things like documentation, blog posts and a unified deck for presenting. This is a big part of fire hose management. If people can't recognize that open source and the Ospo is a specific entity at Microsoft, then it's very easy to get lost in the noise. And part of that was also having a design mark. We use this design, this little pull request design, which is really cute, I think, on all of our assets. So ideally folks start to connect open source, compliance, community and other efforts back to the Ospo's resources. And then it just becomes easier for people to find those resources and each other. The second category, the second fridge magnet, is providing a clear value exchange. So this is things like promotional language, building on the work of others tied to like rewards and promotions, using the language of engineering excellence, making open source feel and ensuring that people personalize it as central to engineering excellence. As well as opportunities for mentorship and networking. So those are, you know, very tactical, practical and emotional value exchanges. We often use storytelling for inspiration. So especially with regard to others at Microsoft and have all they've accomplished through open source. One of those stories is Babylon JS. We started it as an idea of one engineer inside of Microsoft and which they pitched their manager and which had a pilot launched as an open source project, which has since grown to a really thriving open source project, which originally for 3D rendering found its place with 2D rendering and other innovative potential, which would have not happened if it was left as an internal project. There's also great inspiration here in how to be a great open source citizen. So Microsoft and this team very much work as part of the community and not as a leader of the community, which is really important. I'm going to change the slide, but my mouse isn't moving. Great. We also again around storytelling, tell stories of people they work with who might not have met yet. And one of those is now Shamrell Harrington, who actually was a colleague of mine at Mozilla came over at a similar time as I did and who now represents Microsoft on Russ Board of Directors and is a principal engineer in the office of the CTO. Super inspiring person and you know someone that they can look up to. We tied all this inspiration together into a really short but concise course that helps people work through their personal goals, their professional goals with their manager and using HR specific language and templates. Ideally a manager and their direct walkthrough and mapping exercise and leave that discussion completely aligned on how open source is important in that person's goals, which in reward time will be very rewarding. Hopefully we also invest a lot and help people connect with other enthusiasts, experts and leaders in open source and extend to their specific ways they want to help others. So we have a program at Microsoft called the open source chance program. It brings together people who want to help others basically but who each individually have very different ways they want to help. So for example, some people want to help mentor those who are new to open source. Some want to, some really want nothing to do with mentoring new people to open source but would rather want to help teams with strategy. There's things that they have learned and they really want to save people from similar challenges. And then there's just folks that want to help in the context of a community. Bringing up NEL again in the Rust community now would be a great person to talk to. You get questions about being successful in the Rust community and of course that extends to many, many others. So the idea is that everyone is unique and offers unique perspective and expertise to the company and that folks can find them around those things. So that network is really important and inspiring. And finally the category of connection and purpose. We've already touched a little bit on purpose. People's careers and their goals are really important when they're spending their paytime at work. They want to make sure those things are connected. But when I speak about specifically here is kind of connecting to what's already on people's radar. So for example, people care deeply about open source sustainability. They know how important security is. Diversity and inclusion is a core priority at Microsoft. Being a good maintainer is important and a great skill for building someone's career and just being regarded as that expert. So first of all we have from the top this inspiration that open source matters. And this is really, really important. We can't build inspiration if our leaders don't provide that. And so I often use this quote to get people thinking about building on the ideas of others. And so one of the ways that we do that, this is really getting to the teams part of the upstream is through something called open working groups. It's a fairly kind of new structure, but we have groups working on open source metrics in collaboration with the chaos project, diversity and inclusion in open source, open source maintainer, skill sets and excellence and security. So these are just the first set of working groups, but the idea is that all of the work of these groups is pushed up to the upstream and contributed, which is really, really exciting. We've also recently made it easier to find some of those open source champs I mentioned. We have a search functionality where people can search for champs by those expertise, by communities and other attributes including language and region to find people that they can talk to. And meet one other really great team for the upstream is the Microsoft Fund. We've been running this for a couple of years now as I'm writing and we're speaking. We have another, we're almost at our 25th award of $10,000 each month to an open source project. In order to participate and vote on a project, employees are asked to have contributed to open source in the last 30 days, or last 60 days, last 60 days. And all nominations also come from employees. So this is a great program that gets people thinking about who needs support as well as how they contribute to themselves, thinking about what they can do to qualify. So that's another kind of team. And so as I said, this is kind of wrap it up again. The fundamental and interesting difference, and I'd love to have conversations with people about this who've worked in building open source communities and inside of OSPOS, is this incentivization design. It's not the same thing in that how we incentivize is different. The goal is the same, that we end up with more great open source citizens. And that's something that we'll need to work on and hopefully collaborate with you if you're interested. So thanks so much for coming to my talk. And I hope that you've learned something today. Thank you.