 All right, welcome everybody to our presentation on minimum Bible governance. We're sorry we couldn't be there in person, but we're excited to share some work we've been doing on lightweight rules for collaboration with me on the legal side at GitHub and Ashley on the OSPO side. Very excited to be here virtually as well. If you have any questions throughout the presentation, feel free to drop them in Slack and we'll try to get to them. If we don't during the talk, we'll get to them at the end. We'll set aside some time for Q&A. So just a quick description of who we are. I'm Justin Colonino. I'm a director of developer policy here at GitHub and also an open source lawyer, both I'm on the GitHub side and I also dabble from time to time over on the Microsoft side as well. And I'm Ashley Wolf. I joined GitHub a few months ago to lead our open source program office. I help staff here with their open source engagements and I also work with companies that are building out and growing their open source program offices. So we'll get started today by talking a little bit about OSPO's, not necessarily what an OSPO is, but I do want to share what the OSPO does at GitHub. At the core, our OSPO helps developers to reduce friction points. We're a resource for engineers that have questions about any of their open source engagements like contributing to open source projects if they have a question about signing CLAs, bringing third party code into the company as well as releasing new code out there to GitHub. And we help with company open source strategy and policy as well. Our OSPO really relies on our internal and external partners to be successful and set up those policies and processes around open source at GitHub. And what we found that we're really great at is creating simple processes for our engineers to help them with open source. And as developers, you know, when you want to do something with open source or you go to someone for help, you don't want it to be a heavyweight process. You want it to be something lightweight and efficient for you. And at GitHub, open source is in our DNA. We know people, we know the open source community inside and out here. And like many organizations, it's really easy for us to work with open source when we have total control of projects. But when we want to collaborate outside of this organization and outside of these partnerships, it gets challenging. Working in OSPOS at other companies, I've experienced this firsthand. Engineers come to us and ask about creating an open source project, wanting to work with others and third parties. And we start going to all those internal partners to get the conversation started, figure out what it will look like and how it's going to work. We ask questions like, do we need to go to a foundation? Do we need funding? Should it be in private repos? Do we need NDAs signed across the board? And it takes time with all the responses. And a lot of back and forth happens. And that's even before the lawyers get involved. Sorry, Justin. And all the while, the developers are halting work on this project or not even able to get started until they get an answer from us and all of the folks involved. So when I heard Justin was working on NBG, I was super excited and wanted to learn more about it. So here's what NBG is solving. Everything starts out well and good when it's just one maintainer on a project. When you have that total control and direction, things operate fairly smoothly. The problems start when the project moves from having one maintainer to expanding. We've called this the one plus N problem. Things get complicated when you move from one maintainer to one plus N maintainers of your open source projects. So for example, you might want to work with another company or organization on a project together. A bunch of questions come up around where to host it, questions about governance and decision making. Suddenly, you need to figure out how to address all of these things before you can get started. And that's where NBG comes into play. And I'll pass it over to Justin to talk about that. Thanks, Ashley. And I want to echo some of the things that Ashley said earlier around the idea of driving efficiency and processes and partnerships. In the legal department at Microsoft and at GitHub, one of the things we try to do is to cut through red tape to make the process as simple and efficient as possible. But also so that it's done in a responsible legal manner. And so NBG is an outcropping of that philosophy for solving that one plus N problem. And I'm very happy to have such a great partner and Ashley to kind of drive these solutions home. So what NBG is its essence is really just encapsulating the way that communities work in a lightweight way done well once so that lawyers don't need to be involved again. And you don't need to go around and reinvent the wheel if you want to stand up a lightweight collaboration that doesn't need, for example, a lot of funding or funding, a whole money, that kind of thing. You just want to sit down and collaborate with some third party on an open source project in a way that's safe and responsible in a way that you can co-maintain that project or an affiliated suite of projects. And so we already have that on GitHub. You may have heard of it. It's called an organization. A lot of people will stand up organizations with friends to do particular things. A question arises, you know, not often, but sometimes, like what happens to the ownership of that organization if somebody leaves or, you know, somebody wants to join, etc. And so what NBG does is it provides that organizational structure for the organization and the projects underneath. So at the top level, there's what we'll call a technical steering committee. That steering committee makes decision about the overall direction of the organization and the collaboration and touch points between the organization's projects. And that's governed in a consensus-based way, but you can fall back to a vote. A critical piece of this is, you know, negotiating who's going to be on the steering committee. You have a bunch of folks, maybe companies, maybe independent developers, getting together, you need to think to yourself, okay, who are the right set of people so that we can have a good conversation in that steering committee? Who do we want to add to that steering committee? And how are we going to, how does that steering committee set up the power dynamics inside our organization based on its makeup and who's there? And so that's at the top level of that organization. Then underneath, you have individual projects, each with a lightweight consensus-based governance model. And frankly, consensus-based governments, it's, you know, it's how a lot of open source projects already operate. Again, we're just trying to encapsulate and capture the way that most open source projects and organizations work today so that we don't need to rewrite it every time we create a new organization or project. Next slide, please. So let's get a little bit deeper into that structure. So MBG is an agreement and it lived, the agreement lives in the organization's repository and it's signed there and, you know, the signatories are public for, you know, who is on the steering committee and who are the maintainers. And the agreement essentially covers, you know, five things. The first is a decision-making process I just described. The second is a trademark policy. So if you're getting together with a bunch of folks to build an open source project, those people should control how the trademark works. And if you have a bunch of companies or independent developers all working on a project, the hallmark of a true open source project is that the trademark is used by anybody under the same terms. And typically what those terms look like, and as we're capturing the trademark policy, is that you can't call your product, your commercial product, like what our project name is. You can't trade on the project's goodwill in your commercial project and that's capturing the trademark policy. All the participants agree to be bound by that project, that policy, so there really is a neutral trademark ownership and people can kind of trust that project moving forward and trust that people won't be trading off its goodwill. There's an antitrust policy. A lot of people think that this feels a little bit heavyweight. The antitrust policy is designed, you know, again, so that we don't need to reinvent the wheel. This is designed to work both for, the big heavyweight companies collaborating together, the same way it would if Ashley and I wanted to get together and start our own project on the side, not affiliated with any of our companies. Would Ashley and I need an antitrust policy? Maybe not, but it's there and it's a good reminder if we hit it big in our competitors that we shouldn't be collaborating on the project in violation of antitrust laws. There's a code of conduct and again, we're not trying to reinvent the wheel. We chose the code of conduct that is the most popular one on GitHub, which is the contributor covenant, and then there's project selection criteria around kind of like licensing, you know, except for various types of projects, open source, open data, you know, et cetera. And so we launched MBG about a month ago with a blog post. It's live in the repo. It's in beta. We are really excited to get more feedback on it. The feedback so far has been around, you know, what about Singleton projects? You have this two-tier structure. Is that really minimum viable governance? You know, should that be collapsed in certain scenarios? I think it's a good question. There's an issue tracking that. Come, tell me what you think. Tell us what you think and we really want to hear it. Again, the antitrust point I just addressed and, you know, why do you need a trademark policy? Again, the idea is so that others don't trade off of the goodwill of the project that the group has, you know, collaborated on and people can trust that origin of source that is the community that's been sprung up around the project. So in the links there, it's pretty easy to remember and type in if you want to visit us. Awesome. Thanks, Justin. And thank you, everyone, who's been with us throughout the talk and to the folks behind the scene that set this all up for us so we could present during OsvoCon. We'd love to hear your thoughts about MVG. So if you're still here, drop in a note in Slack. We're happy to answer any questions, take comments and feedback. And thank you all for being with us here today. That's right. And if you want to reach out, if you're watching this, you know, async and we're not in the Slack channel, you know, our contact information, our GitHub handles are at the beginning of this presentation. Feel free to reach out directly. We'd love to hear from you. Definitely. Thanks all.