 Hi everybody. Thank you all for coming to the talk today or listening virtually on our virtual platforms. My name is Carol Smith and I'm a Program Manager in the open source programs office at Microsoft. I'm here today because I'd like to talk to you about what we call business reviewers in the enterprise compliance space. I will not be leaving time for questions at the end because this talk is only 25 minutes and we've got to talk right after it. But I will be available on Slack and in the chat channels afterwards if you have questions. I'll be here at the conference walking around if you'd like to see me later to ask questions. And I can always be emailed at carolus at microsoft.com or my Twitter handle is at fosseygirl without the I. So what do you think about when you hear the words open source? Maybe community, speed of development, innovation. I'm sure a lot of the speakers today have mentioned a few of these words here at the conference. But maybe you or maybe people in your organization hear open source and they also think risk or maybe security questions, something in that space. So how you and your organization think about risk and open source probably determines a lot about how you also think about your internal compliance systems that are handling your open source use and your open source development at your organization. And maybe your organization thinks open source is very risky. And so it has centralized all of the decision making about open source software development into one organization. Maybe it's called the open source programs office at your organization. Maybe you are the person who is making all of the decisions about the open source use for your developers at your entire company. Maybe you were hired to make those decisions and handle those approvals and rejections. So how you handle and how your organization thinks about open source is an important part of what compliance probably looks like at your organization. Maybe you're a little earlier in your open source journey and your organization has a bunch of policy documents that were written by your legal team that outline what the policies are. And the onus is left on the developers to decide whether or not a particular development scenario with a particular piece of open source is allowed or rejected. Or maybe you have a patchwork of systems. Maybe you have a bunch of teams or departments that are all handling open source in different ways and no one's talking to each other. So this is all a reflection of how you think about risk and how your organization thinks about risk. Or whether it is thinking about open source and risk at all or just maybe burying its head in a little bit in the sand. So what I'd like to talk to you about today could be what might be a change in philosophy for your organization and how you think about risk in your open source organization. And I'd like to talk about moving to a model that focuses firstly on automation around your internal compliance systems. But also much more importantly focuses on applying your most important resource your people your humans who are going your colleagues who are going to apply judgment to the open source that you are using in your organization. To be able to be thoughtful and make the best decisions on behalf of your organization as they can and do it in a coherent and thoughtful process. So this is a bit of a change in philosophy to a model that says let the computers take care of most of the decisions about our open source. So let automation handle many parts of the open source process for our developers and let humans apply judgment to the most important things that we think need to be overseen or need oversight or need review for whatever reason that makes sense to your organization. This is also a model that moves away from the sort of all or nothing idea so all open source has to be approved or no open source is allowed at our organization. Or all open source is centralized to this one body and this one decision maker and much to a much more nuanced process where you as an organization have understood. What things are important to you what licenses what usage scenarios you want to prioritize what things you are able to enable the developers. To just use in any given scenario and to disperse these decisions across the organization and allow many different people in the organization to be responsible for the decisions that are going to make sense for their departments and their teams. So I think everyone in this room is probably somewhere in a different place on your open source journey maybe you are already somewhere along this path to automation and distributed business decisions. Or maybe you are just starting out with those policy documents written by your legal team that I mentioned before. Wherever you are what I'd like to do today is talk to you a little bit about Microsoft's journey and how we've evolved our thinking in this space and share some of the things that that we've learned along the way. And some of these are changes and an evolution that I've overseen so I'd like to tell you a little bit more about those. So the first part of this process and this is a huge piece of the puzzle and I'm actually not going to talk very much about it at all. Is having an internal compliance system in place in your organization that detects and affords your understanding of all of the open source that your developers are using across the organization. This is a key piece of the first step in this process and a key piece of the puzzle and there are a lot of different and complimentary options and pieces of software that are in this space. So you may already be evaluating or having conversations about some of these pieces of software and I would encourage you to continue to have those conversations about moving to an automated internal compliance system and model. Having a proper accounting of all of the open source that your developers are using anywhere in your organization is a really key and important first step in the process. Microsoft has its own internal compliance system that that we use. But regardless the important thing is that it needs to be a system that enables you to make business decisions based on the open source that you're aware that you're using and the information about that open source that you're then getting. The next piece of the puzzle is having good data about that open source that you've now allocated for. So you needed a proper accounting of all of the open source that your developers are pulling in and building on every day every minute that your business is in motion. But you also need to have good data about that open source and you need to have trust in that data. So it's not just a matter of knowing that I have open source component X. It's also knowing that I for sure know that this is MIT or I for sure know that the source location for this component lives here. And if for whatever reason you you or your decision makers don't feel confidence in that data for whatever reason. Maybe you are not quite sure if that thing actually is MIT or there are gaps in your information for whatever reason. And you're not going to be able to make good business decisions based on that information. You're going to have sort of garbage in garbage out in this situation. So it's very important not only that you have the proper accounting for the open source that your developers are are using but also that you know what those things are. So Microsoft depends on a project called clearly defined that provides all of the data about all of the open source that we use in our own internal compliance systems. If you are evaluating data sources for your internal compliance system somewhere in your open source journey I can encourage you to look into clearly defined. It is publicly available. It's free. It's open source. And it has a large community of people who are working on maintaining and keeping all of the data very high quality. Microsoft depends on it and thinks it's a very useful and worthwhile tool for this trustworthy data that I've been talking about. But again no matter what data source you're using whether that data source is integrated with your internal compliance system whatever that is. Again it's very important that you and your colleagues and the decision makers have very high trust in the system because you're going to base all of your businesses decisions on that information. So once you have an automated internal compliance system in place and you have very good data about the open source that all of your developers are using across your organization. Now you can start to make good business decisions about that open source and you can base these decisions on hierarchies of information and on decision trees based on licenses and usage scenarios for that open source. So for example let's say that you know for sure that these five components that developer X in department Y is using are all Mozilla public license. You know this for sure because you have high quality data about the open source your developers are using and you feel very confident that you know that information. Now your internal compliance system can start to apply business logic based on that information and start to make decisions that are based on your own organization's feelings about things that are licensed MPL. Do you for example want to enable your developers to always use things that are MPL and just auto approve it because you have very good trust in all the open source that's licensed under MPL. Or for example do you not trust things that are licensed MPL and you want to send those for extra review for whatever reason that makes sense to your to your business. So this is an important next step in your evolution is having those conversations and understanding how to delineate between those two things. Microsoft of course has its own source sources of business logic based on licenses and usage scenarios as well. But I would encourage you to think of these decisions and this delineation between licenses and business and business and licenses and usage scenarios. Sorry base like a family budget. So for example you might have a monthly expenditure in your budget for biking gear because it's very important to your family that you always spend monthly money on biking gear. And my family might have a monthly expenditure for say lint chocolate because it's very important to my family that we buy lint chocolate every month. And neither of us is right or wrong in having a line item for biking gear or chocolate in our budget. But we as a family have had a discussion about what's important to us and what we think we want to prioritize in our monthly budget. But because we can only spend the money and our resources on so many things in any given month. And so I'd encourage you to also think about these automated decisions this business logic around licenses and usage scenarios in the same way that you would a family budget. I'd also encourage you to think of having the conversations within your organization about what's important to you like having a conversation about a family budget. So it might be a lengthy process. It might be a lot of conversations but you're going to need to come to consensus as an organization about how do you feel about things that are BSD to licensed. Do you want those to be auto approved and be sure that you have come to a consensus as an organization about how you feel about those things. This might be an involved process for you and for your organization because there may be people like your son who feels like you should have a much larger monthly budget for chocolate. Who disagrees with your daughter who thinks that you should have a much larger monthly budget for biking gear. And in the same way you may have people in your organization who feel a particular license is particularly risky where other people don't. So maybe part of your job if you work in that space or you're in the open source programs office might be enabling and empowering having those conversations and coming to consensus about what those are. So now you've got your system in place. You have high quality data and you have trust in that data and you've come to decisions about what things are important to you in terms of licenses and use scenarios. So you've got this bucket of licenses that are called MIT and those always get auto approved whenever an open source developer within your company wants to use any of those things. And you have this other bucket of things called BSD and you want those to go to particular review every single time anyone in your organization wants to use something that's BSD to licensed. Okay, so now you get to make as a business the decision to apply a lot more human judgment and human resources and human time on looking at those things that are the really important decisions. The things that you as an organization have decided we really want the extra review and the extra application of judgment to these particular things and you can start to focus your power on that. This also is going to save you time and money because I hope that as you're having these conversations you're going to discover that there may be lots of things that before in a model where all open source studies used at this company needs to be approved or denied now you might have a large bucket of things that just get auto approved because your organization has decided that those things are not as risky to it. So you're probably going to end up finding out that only a fraction of all of the open source that your company is using or all of the open source that your developers are pulling in on any given day is actually needs review and oversight and judgment applied to it. So now if you're farther along in your open source journey, I'd like to again suggest what another what might be a philosophical change for your company. So if you have developers everywhere in your organization who are building on open source software. I'd also like to suggest that you also are taking on all of the risks and responsibilities and benefits of that open source use across your organization as well. So if you have developers in lots of different parts of your company who are interested in building on an innovating using open source software, which I hope that they are. Your executives and your decision makers should also feel like they are all equally invested in the responsibilities and the benefits and the costs and the risks of using that open source anywhere in their organization wherever that developer might be. And so a bit of a philosophical change might be for your decision makers to start to invest in the people who are going to do these reviews and apply this judgment to these scenarios where you think your open source use is going to need extra review for whatever reason that makes sense to your business. And again, keep in mind if you've decided that there's this whole bucket of things that gets auto approved or is transparent to the developer and they can just use in any scenario. Now we're just talking about applying people power to a very small fraction. And so hopefully this is this eases the conversation with your decision makers a little more because you're not talking about a huge burdensome amount of time for any one person to spend doing these reviews. And you're distributing those decisions and those reviews across your organization. So now we get to what Microsoft calls business reviewers. This is how we refer to the people that we have empowered to do these reviews for the open source that we have determined needs extra review and extra judgment applied to it for whatever reason. And part of Microsoft's open source journey has been re-envisioning how we think about these people and how they're chosen and how they're regarded. So it used to be that even with our own automated systems that handled our internal compliance and we had very good data as well. And we had had the conversations and made the decisions about what things needed extra review and extra judgment applied to them. But it used to be the case that we gave those reviews to people based on organizational chain. So for example, developer X in department Y wants to use this open source thing that we think needs extra review. It probably goes to developer X's manager's manager. And we just hadn't spent time focused on thinking about these people and the importance of their role as business reviewers in our organization quite a lot. So what we learned is that often these were not the people who were best positioned to make the decisions for these reviews. So for example, my manager's manager might not even know that I as an open source as a developer and building on open source. And whenever a review gets to her desk, she might not know why she's being asked to review this thing. And often these were people who just simply didn't feel quite qualified to make these kinds of decisions on behalf of the organization. And also did I mention we hadn't trained them on how to actually do these reviews? So there was some room for improvement in the process. So what I ended up doing is re-envisioning a bit about how we thought about these business reviewers in our own organization. And what we realized is business reviewers are absolutely crucial to this process. We were thinking about the open source compliance systems that we had in place much more around the automation and the data, which are both important, important components, but not around these people who were doing our reviews. And so what we wanted to do is actually put a formal program in place that would assist these reviewers and support them in this process. So the first thing we did is we looked in our old internal compliance system and we found all of the corporate vice presidents from across Microsoft, who in the last six months had had any developer anywhere in their organization who had submitted a request to use any piece of open source that had ever required a review. And then I did the old-fashioned thing, which is I emailed them and let them know that we wanted them to participate in a new program. Who were to choose business reviewers for their organization to do these open source reviews. So these are business reviewers who are specifically chosen by these corporate vice presidents. And then we would inform these business reviewers about their roles and their importance in this process and in the organization. And then we would give them training about the philosophy behind our reviews, as well as literally how to do a review, which was an important and missing step of the process. And then finally, we would provide recognition for their participation in the program and reinforce the fact that these are actually people who are making important decisions on behalf of our business. And we understood that this was time and energy as well as expertise that they were giving to this process. So I oversaw the process change to build this whole system. And once the corporate vice presidents had nominated their business reviewers, we then emailed the business reviewers who had been nominated and let them know that it was very important that they participate in this program and let them know about the importance of the larger business reviewer program as well. And we let them know the process. So we were going to start to give them training and then we were going to start to send reviews to them to make on behalf of our business. The training was another key piece of this whole process. So we built a training module in our internal training systems that actually provided the full picture for these business reviewers of their roles and responsibilities in this process. So it gave them the philosophy about why we were having them do these business reviews. It reminded them of the fact that open source is an incredibly key part of our development workflow and our innovation. And that also we as an organization had particular scenarios, particular licenses, particular kinds of open source that we wanted to have these people apply good judgment to. And then we also made the training a gate for becoming a business reviewer formally. So even if you had been nominated by a CVP to be a business reviewer for your organization, you were still asked to complete the training before you started to actually receive the reviews. So we made sure that you would receive the training. And did I mention we also included how to do a review in the training? So then we solved that gap. And then finally, as part of this program, we also provided provide recognition. Internally, these folks are referred to as deputies in our internal systems because they are deputized to make these decisions on behalf of the organization. So they're recognized in that way internally. And they're thought of as an important and integral part of the process. And we also have a badging system in our internal profiles that gives them recognition. And again, we wanted to acknowledge that this is not something perfunctory that they are doing. This is an important and key role. Finally, finally, we also realized that the business reviewers might potentially have questions or need support around the process. So we gave them access to an existing internal community of open source advocates that we called the Champs, who were people from across our organization, across focus areas, across seniority levels, who were already advocates for open source. And so when business reviewers had questions or needed support in their business reviews for whatever reason, they had access to this internal community of Champs as well. So providing the support to the business reviewers themselves was also important in recognizing their important role. So finally, I would just say maybe give it a try. Microsoft benefited hugely from re-envisioning and rethinking how we thought about business reviewers. And your organization might benefit from that as well, no matter where you are in your open source journey. So like I said, I will not be taking questions, but you're always welcome to email me at carolessatmicrosoft.com. And I'm at Fosse Girl Without the Eye on Twitter. And thank you very much for coming. I really appreciate it.