 Hello and good morning from the west coast of the US. I'm Sarah Novotny and I am here to speak with Stephen Wally. We'll introduce himself in a moment about minimum viable governance for open source projects. Stephen. Hi, my name is Stephen Wally. I have the pleasure and privilege of working with Sarah. We both work in the Azure office of the CTO at Microsoft and we live in a really interesting time in the industry right now. Open source is clearly one. OSI license projects under nonprofit umbrellas account for tens of billions of dollars of collaboratively developed software. And we know that number is in the ballpark because on the order of five years ago, the Linux foundation did an initial calculation of how much value is sitting in the Linux foundation under that umbrella and they came up with a number that was, you know, getting close to 10 billion. Greg Stein at the Apache Software Foundation, not to be outdone, quickly ran the same calculation across all of the software value inside of the Apache Software Foundation and came out with a number that was a little bit bigger, which I think was Greg's point. But both organizations continue to track those numbers and growth, and together they're comfortably over the $20 billion mark now. And then that doesn't even begin to include when you look at all of the software under the umbrella of the Eclipse Foundation, all the way back through the Free Software Foundation, the Software Conservancy, and all of the language communities, you know, when you think all the software value that's still embedded in the Pearl Foundation, the Python Foundation, the Ruby and PHP worlds. So there's literally tens of billions of dollars of software value that's been captured under OSI licenses in these nonprofits. At the same time, I have to disagree with Andreas and that, you know, software is eating the world. Software has been democratized at this point. I think we're drowning in software, and a lot of it is mediocre, duplicative and bad. And seeing an explosion of nonprofits over this last five to 10 years, you know, it's an acceleration as entire new industries step into this space to try and capture some of that, that valuable collaboration that they're seeing in the open source world with new OSI licensed nonprofits. So we're seeing even over this last couple of years, really interesting things changing in that the software development organizations organizations like the IEEE Standards Association and OASIS are stepping into the space of working to support OSI licensed projects. At the same time, you have organizations in the open source nonprofit world, like the Linux Foundation with the Joint Development Foundation, trying to step back into the world of creating standards and specifications. So this is a really interesting time. Can I have the next slide? The reason though that Sarah and I think this is a really important topic, this idea of governance and minimum viable governance is so many people seem to think that governance is about voting and around voting instead of getting work done. And you can see that in a lot of the stories in the news right now. The CEO has been in the news for almost two years with folks arguing whether or not, you know, what's the governance of the project, and should the project come into a nonprofit so that there's a different governance applied to it. You see it around the K native discussion. And then sometimes bubble out into public discussion in concerns from the technical oversight committee in the CNCF that there's lots of folks that are concerned about voting on things and that feeling of either controlling something or a loss of control of something. So it must be about having a vote. And really it's about getting the work done. We're even starting to see situations where venture backed startups think that the way to an exit is to create an open source project and somehow bring that project to a foundation build an ecosystem around it and then you know, and then money happens. And so we need to get away from that kind of thinking. The next slide. We have two governance spheres that we're talking about here, and they're very different spheres one of them is this idea of project governance and getting work done in the project and the other is how do you, how do you think about nonprofit governance and what's what, what's different about that, and how do you address some of those needs. And so I want to kick it off with projects let's talk about projects first and I have the next slide. So what we are this basic an open source licensed project with its community is the basic unit of work in our space for all of these discussions. And so I want to, you know, Sarah and I kind of have this idea of we're talking about healthy open source projects, kind of the next slide. So what do we mean when we're talking about this, you know, healthy open source projects will really you've got a code base under an OSI approved license. It's the declaration by the originating owners of outbound sharing it for any purpose there's no expectation on a return. The contribution flow is the life blood of a project. Successful projects are always transparent in their decision making and support a diverse community of users and contributors and maintainers. The idea is that you're growing the user base to find developers. And then you want those developers to do selfish things. So that understanding that there's lots of folks that just want to be users of the software they don't really want to contribute back they have nothing to contribute per se. And freeloaders are okay that that's part of the this kind of community build. So you want to grow the user base you want to make it easy to use and deploy and build and contribute. They're really encouraging those selfish developers who've done something to solve their own problems to contribute back so they aren't living on brittle forks. So that's really when we say, let's talk about open source projects and governance. That's what we're looking at trying to enable and build. And I think next slide. Yeah, please. I think it's summarized best. There was this wonderful quote from JFK as he became president of the United States. Now ask not what your country can do for you ask what you can do for your country and I love to paraphrase that in an open source context around a project, because it's really not, you know, don't ask what your community can do for you. It's what can you do for your community you have to be thinking about how you build that community how you enable that community to form, and how you create the governance that supports that growth. And so I think the best thing that helps in all of this is to have a really crisp example. And so Sarah is going to talk about the best crisp example we have in front of us right now. If you all may have heard me talk about Kubernetes in the past so this shouldn't come as a surprise to you that I'll use that as our example. So Kubernetes is a really good example for a number of reasons. One, it was a very fast paced project. It is relatively recent the first public commit was done in 2014. It took about little over six years of history on what happened. And of course, because it was such a nice market fit and and such a great community to begin with at the moment. It took off like a rocket ship. So, one of the big reasons I love talking about Kubernetes, it's easy to reason about this as a human when you look to some of the longer running projects which also achieve this sort of scale maybe the Linux project itself, OpenStack or Cloud Foundry or any number of longer running projects like this. They're harder to reason about because they're over longer time periods and more generations of contributors and participants and leadership within the project in that most cases. So they're harder for an individual to sort of draw out long, long time periods of change because they're too long to think about. So this one being super fast gives us a great way to look at this. So, I know that a lot of a lot of people prefer deep technology talks but as it turns out I find an open source for me the more interesting problems are the problems about people, and the problems about how the groups interact and it's about how decision making happens and how one chooses to engage and build a structure around a project or where that project may live in order to have independent governance or where that project may live to have controlled government. There are all sorts of options in this but it really really comes down in my in my opinion to culture. And as it turns out, I think setting in a good culture in a project is more important than writing out a whole pile of rules. Now all that said, you will need rules, but you will find that those rules evolve over time. And as they evolve, it's because your culture and your community are evolving and requiring this. So let's talk a little bit more about the culture and start with some of the most important pieces. And then we will then move on to how the governance layers in around that. So, first off, empathy is huge. It doesn't matter who you're working with in a project or where you're working with them. You need to be able to put yourself in their shoes for just a moment and imagine how they are experiencing whatever is going on in the project, the world, their community and all that's around them is incredibly important in order to be able to bridge and make some sort of connection to come to a decision or a conclusion. You also need to make sure that there are clear signs and paths that are set out for how you engage within this community. I speak a lot about meantime to dopamine. So the first moment when you're like, Oh, I get this. And that works always for software, you want that first five minutes, you know, when where suddenly someone sees, Oh, I get this. But it also works for communities. You want someone to be able to feel that they know how to participate see a short path to being able to add value and that value doesn't have to be a huge pull request. In fact, it rarely is it could just be asking an interesting question getting a positive response. It could be engaging with a bit of feedback on an open RFP and getting a positive response. But having that way that someone can feel as if they are making an impact in that project immediately and have good signage and guidance to get to that, as well as developing a culture and a community that wants to help and wants to engage with the people who are as interested in the project as they are, but maybe haven't experienced it yet. And then these people who are part of your project already get an opportunity to learn and grow from the people that are new to the project, and also to offer and teach back what engagement they need to participate in the project. You get to share the cultural values you get to set good standards for the project you get to engage with a community that wants to participate and wants to focus on being a learning culture. And that makes a huge amount of space for all the things that you will need to layer in into governance because governance is not a one in done thing. So making a learning culture where it's okay to fail and it's okay to teach and it's okay to learn and it's okay to ask questions that aren't potentially as comfortable as you might want them to be. Those are important. It is very important always to be seeking different opera or different perspectives in order to make sure that your community is looking at things from different views, making sure that they're considering just a customer view and a developer view but perhaps a view of a gender view or a non gendered view or making sure that you are able to engage with that community bringing in new ideas from completely different disciplines or from completely different perspectives. It's incredibly important, especially as you're building out what the culture is in your community and then from that building out governance. So the first thing that I think is incredibly important in building out governance is to make sure that you're documenting your decision making and that can be how do we make decisions today. Anyone who is in a project and doesn't know how decisions are made is going to have some discomfort. There's not an easy way to get to that impact, not an easy way to see how to contribute. So making sure that there's a clear documentation about how decisions are made and how they are documented where someone could look for those decisions is incredibly important to just give everyone a little bit more comfort as to what's happening behind the scenes. I love this picture because it's shadowy power structures and we ran into this problem late in 2016 in Kubernetes. We were struggling because new people were coming to the community at a crazy rate. It was so much fun. There are always new people joining, but no one knew how to get push a thing to a decision how to get an answer from this nebulous Kubernetes community. There were you know the original project founders but were they really still the right people to be answering questions. If they were then should I do this in a bad channel should I do this on a GitHub issue what is the right way to drive something to a decision. And then also as the project sprawled it would became impossible for any one person or any small group of people to track the whole of the project. It started to have so many components that we really focused on how to make decisions in a distributed manner. And that distribution meant that it was pushed down to the groups that were actually developing code. And so it was decentralized and and managed that way but we had to work our way iterating through this from that shadowy I don't know how decisions are made to an actual developed process which first was maybe you should ask one of the Googlers and then at some point we got documented as we want these we want these decisions to be made in special interest groups. And then as that was more documented, we had more ability to move quickly, because we weren't gated on either the unknowns of who to ask, or a single person making a review decision. So that was incredibly important. So document your decision making process, and then also your decisions so that they can be tracked going forward. Measure what matters this is another incredibly important piece in developing your governance and project health. It's a little bit more on the project health side, but I still think that it is an important way to support culture and support governance. Because if what you want is super high velocity pull, you know, and pull requests per time unit, then you change different things than if what you want is long term long standing contributors who maybe stay with the project for a year or two years. But basically when you measure something, you can identify how your changes in the community in the culture and in the governance actually affect that choice affect that measurement. So knowing where you want to go with a project is incredibly important and then having a meaningful way to measure that. This ties directly to making sure that you reward the behaviors you want to see. So while we're measuring what matters, say we see a positive, a positive experience or a positive trend in one of those things that matter. We want to make sure that there is a way for the contributors or the project leads or the people engaging with this issue with this measurements to improve it are being rewarded and being rewarded publicly. So these are sort of the underpinnings for me around what a minimum viable governance structure is. And I find that all of this comes from a super useful tool set, which a lot of people don't like. So let's talk for a minute about values, and I'm not actually talking about things like ethics and respect and honesty and integrity. I think on the whole that we need to believe that everyone is working with those values. I think we have to presume people are good actors. And within the community of Kubernetes at least we spoke a lot about making sure that if we had an agenda, it was an agenda that was clear and public, so that our choices and our ability to work within that community was not potentially restricted by people not being sure about our motives. But when we talk about values, especially in engineering organizations, people seem to get really bifurcated they either love the idea, or they hate the idea. And I think that this is because people equate the values with culture. And I don't think that that is exactly the same. I think they relate to your culture. But again, it's not ethics. It's not integrity. It's not, you know, disruption. Actually disruption could work. But it's not values that are sort of soft and squishy and feel good values. This isn't this isn't the stuff that we all presume from a good actor in a community. So, when I have these conversations with engineers, sometimes I get this very blank look, like, why are we talking about values values are so nebulous, how are they actually even useful to me in these conversations, because I always come to work. Always honest, right, you know, I don't have this honest versus dishonest discussion. Why are we talking about values, Sarah. We're talking about values, because values are actually useful. I love setting up values for communities based on decision making. So what are your values that you can go back to to make decisions. So the Kubernetes community over time as we were evaluating our community and our culture and starting to build little bits of governance with the Kubernetes bootstrap and this would have been in 2016 and a little bit into 17. We decided to build values that could be useful for future decision making and could be useful to change our governance structures when we needed to, because of course we wanted to do the minimum amount for governance from day one, and then give enough information and enough framing for people to be able to make decisions going forward without requiring the founders or the original right, you know, the original Constitution writers to participate in these, these discussions are participating in these changes. So we needed to have a sustainable project that had a clear direction, and that direction came out in our values. So we came up with four values. The community is more important than the company. So within any decision, if you're, if you are trying to make an argument that you need a new feature. And the community is arguing or people from the community are arguing that it doesn't benefit the broader project and it only benefits that company. Then that may not be something that gets into a release, because we want to make sure that if something is happening, and if a new feature is being built, it is as much a value or more a value for the whole community and the whole project, as it is for any single company that's participating. We've seen this in another couple of ways. We've seen this in that we have people from the Kubernetes community who list Kubernetes first on their resume or maintainer of Kubernetes or sing lead of Kubernetes in their LinkedIn profile, say, ahead of their company, and that they've worked for multiple companies working on Kubernetes, but never being tied being tied closer to the project than to a company. And we have people, we find people recruiting for maintainership or leadership within Kubernetes. And that to me makes a healthy strong community focus for a group that is going to be forever changing employers moving around having different needs at different times. We've also agreed that distribution is better than centralization. So this was one that we talked about at great length when we were trying to figure out our decision making process, because we really were getting bottlenecked with a go ask Brian grant model. And that was not reasonable for Brian or for so many other people who are great leaders in the project, or others who didn't have a personal relationship with them and might not have wanted to reach out to him different things like that we wanted to make for. I guess it's Brian Grant Tim honkin there there are lots of the founders, but go ask one of the founders first. And that's not scalable. You know that is that is not something that we can do with 1500 rotating contributors per release. We wanted to push our decision making process to be distributed in the same way that we needed to have our orchestration platform be distributed. And of course there's a whole bunch of information about Conway's law that we can throw in there to make that one important distribution is better than stagnation. So this is a continuous improvement mark for us we really wanted to make sure that the project was continuing to grow was continuing to improve itself. We got to a spot where we had to ask a question of do we take some time to improve this, or do we go try to do something else. We would try to actually model our decision to improve what was broken, make sure that we are always improving the code base and always making things better than when we first started. I've also heard this called the campsite rule do a thing leave leave it better than when you arrive. And then the last value that we teased out in all of this was automation is more important than process. And all of this was to make sure that we could minimize the amount of low glamour work that happened within the project. We were using people and their brains to the best advantage, we were maybe doing a little bit heavier work upfront defining an automation tool, as opposed to just a process on how things happened. But we recouped all of that benefit across many decisions over the long period of the project itself over a longer period of the project. We used the values that we teased out, and we really tried to use them to make decisions within the project. Now there's another thing that you've probably heard me and many others from the community and the DevOps community say, which is chop wouldn't carry water. I think of this as a tagline for the community. It's sort of a best practice, a great way to describe how people engage in the project and how people want to engage in the project. The idea is there is always low glamour work to be done. And that is going to have to be handled across the project by many people. I don't know where to start in a project. Try to find one of the issues that maybe is sitting has been sitting idle for a bit, and looks like it might not be super exciting but important. And, you know, tag it as something that you want to work on and start asking questions because that kind of work, the quiet competence of people doing work that the project means whether it's CICD work, or testing work, or improving the contributor experience or writing bots to go ahead and automate things. All of that is low glamour work, very necessary, and is really what keeps the wheels of the project moving. So all of this gives you sort of a framework for minimum viable governance. And I want to remind everyone, if you're feeling disenfranchised as a contributor or a participant in a community, there is someone else feeling that as well. And if you feel that something is preventing you from participating or doing good work within that community, recognize that we may be running into a governance problem. We can also be running into an empowerment problem, because sometimes people don't feel as if they're empowered to make these choices and make these decisions. But that can be helped with leadership and the leadership can also, as within the Kubernetes community, we would point back to the distribution is better than centralization. We want more people working on this, so that we don't get bottlenecked on a single person. As a leader in a community, please make sure that people feel empowered. But as a contributor, if you feel disenfranchised or if you feel that work is being stymied, have a look at the governance, have a look at what the project is doing compared to what's written down, and then maybe start a discussion around it. It's a pretty straightforward discussion to start. You start by writing down what you're doing right now, write down how the decisions are made, write down what you think the process is, and then recognize you're never going to get it right the first time, or possibly ever, especially as these projects evolve. Maybe stable for a while, but consider it a local area maximum. It'll be stable, and you'll be able to move past that as your unstable equilibrium changes as your community grows or your project evolves. And then once you've realized you'll never get it right, when you find a problem, discuss what your problem is in that community, go ahead and empathize with others' views on it, and then iterate through the work that needs to be done. Projects are long-term investments, and you need to always be looking at the future with how the project is led, how the project is governed, and who will be the next people leading that project. So documentation is critical in all of this. I think we get to go on to the nonprofit parts of this again now. The exciting parts, not the project getting work done parts. And that's actually the fun of it is, everything that Sarah's been talking about with respect to getting work done and governance being focused on how to enable people to do work in a project community really does apply in a nonprofit. But the difference is nonprofits have a very different reason for existing. Nonprofits really are a way to enable projects to grow to the next level. And we can look at them from two different ways. One is from a project-centered perspective. Why would I want to involve myself with a nonprofit? What does a nonprofit bring to me? And the other is from the perspective of sponsors or members of these nonprofits that why would you sponsor such a nonprofit? What does your company get out of it? Why would you become a member? If I could have the next slide please. So where this idea comes from, when you're looking at it from a project growth perspective, well-run OSI licensed project communities. So remember going back to that definition that Sarah and I kind of set up early on of what does a well-run community look like. You get to the point in your growth that you're doing more and doing more publicly. And the liability is going up at a personal level. Who signs for the venue for a meetup? Whose insurance is on the line? If you're buying something, whose bank account did it come out of suddenly? Or if it's just popular enough that people are using it, and even though the license says you've got no legal recourse, what if somebody sued the project? Whose mortgage is on the line for going to court to defend your righteousness? You know, this idea of liability and risk becomes a reality at a certain size. At the same time, companies start to show up when a project is becoming, having a real center of gravity. Companies can start to show up that might want to use that project as a component in a product or service to their customers. And companies have very different risk profiles when they're doing cost-benefit analysis and trying to understand the opportunity. And that risk needs to be managed somehow. Okay, I have the next slide. And so you end up in this idea that the nonprofit as a legal structure exists to limit the risk, limit the liability, and provide a neutral home for holding assets, whether that's the software or the trademarks or some collateral. And in certain cases, it's really important, and we'll talk about it in a little more depth, to actually possibly provide antitrust protections for large companies that are collaborating in this space. Next slide. The really interesting thing becomes around nonprofits is these are legal frameworks, but they're legal frameworks that corporations understand. We, you know, we've been creating these legal frameworks in the open source community and the free software community broadly all the way back to the Free Software Foundation in 1985. So this is a long understood and a growing body of knowledge that corporate lawyers understand. And it doesn't matter whether they're nonprofit lawyers or for profit lawyers, like this is for 35 years now we've been learning about this space and how it applies to free and open source software projects. And so I want to take a step into it from a very corporate perspective for just a minute. If I could have the next slide please. There is a, every once in a while, you will see this idea of Oh, these nonprofits are just paid to play that you know there's there's somehow a loss of purity when you step into the nonprofit space, especially if you step into the technical membership organizations. So things more akin to the Eclipse Foundation or the Linux Foundation, OpenStack Foundation, things like that, rather than something like the Free Software Foundation or the Apache Software Foundation, that there's this loss of purity because money is involved now. That's just not the case. It was really interesting to see a shift up until 1999. Almost all of those foundations, including in the standards world, were nonprofits for the public good under US tax laws of 501 C3. And that idea of that it's there for the public good. These were organizations that had to do their own fundraising. You would, you know, contribute, you'd sponsored one of these organizations, and that that's what enabled them to do the work that we were talking about, you know, holding assets, removing liability. In 1999 though it changes, because at that point in history, the open source development labs, OSDL was the first one in our broad open source community that was a technical member organization. So it's a 501 C6 under US tax law. That's the idea that, okay, so companies are spending money now, but that was really important, because understand in 1999, the Department of Justice was on the scene again, and Microsoft was under the microscope. So we had a real life example of a high tech company under the Microsoft under the microscope from the Department of Justice. And those large OEM based organizations that we're trying to get away from writing large checks to AT&T for their UNIX licenses and we're focused on the growth around Linux were companies like IBM, who had been through the Department of Justice just meet already, Intel, who was very paranoid about ever going through that DOJ meat grinder, and HP who had not yet been through it yet either, you know, these, and they didn't want to step into a space where their collaboration might look like collusion. And so I was going to say we have additional changes that have made it even harder to get open source 501 C3s that have happened in the last five to 10 years as well so open source is much harder to register 501 C3 around. Exactly. And so you end up in this space where that pay to play what they're paying for is antitrust insurance. It's not actually about voting again it's about antitrust insurance and ensuring that those companies can collaborate on supporting a set of projects they care about. And look at even around the OSDL and Linux, Linux had just left trans meta. If if the industry was going to bet on Linux, they needed to make sure that Linux was carrying no personal liability either. So you know that that's how these things arose. And after that you once you've set that model and it's a useful model, we've seen it repeated again and again and eclipse the outer curve foundation and you know open stack foundation things like that so it's not. It has a real purpose, it is not simply companies trying to do something with money. I'm going to have the next slide please. And so, you know you see this in everything you touch in the Linux foundation world. Every presentation will start with the antitrust policy notice if you're in any of these board meetings for any of the directed funds or sub foundations as a Linux foundation. But that's because this is a really important way that things happen out there. I have the next slide. So when you step into the space so broadly, and you have a discussion about so what are these nonprofits doing for us you'll often see lots of folks giving lots of very useful opinions about all the kind of the piecemeal services that are in place. And if you keep going down that path kind of the next slide. It really is about providing a structure for communication structure in which you can build culture and a structure in which that governance can be identified to support that culture that enables those basic things of possibly antitrust protection and certainly reliability risk and holding assets in a neutral way so that the projects have an opportunity to continue to grow. Okay, the next slide. But again of course you fall into the values and ethics discussion again and there's a certain there's a there is a real symmetry here to everything that Sarah was saying around the project, you know, people immediately fall into you know what are our project values and then you can't get stuck there. The next slide. Other way. There we go. You really have to step it up into this idea of your governance enables work to happen. It's not about voting per se it's about enabling the work and again going back to the example that Sarah built out around the values that enabled the Kubernetes project to do work. And then you need to figure out if you're working in a in a nonprofit context either organizationally or as a member of one of these in a participating way. It's how do you identify that culture that you need to get work done. And how do you enable that through a written down captured governance. It's I keep talking about I'm presently the governing board chair for the confidential computing consortium. And I was teasing folks very early on in this set of discussions that you know every members welcome every projects welcome. And I'm sure all of the members are tired of hearing me say that now, but that became this kind of value of, it's very inclusive, everybody's welcome here we are not picking winners of the projects. We want all participants that care about open source licensed projects in the confidential computing space to feel they can come and participate. And nobody should feel that there's somehow they need they need to control aspect and in the governance here. So it's about stamping culture. Next slide please. When you look at it from a company's perspective instead of what does a project get well it gets services for growth, and it removes that liability risk when you actually look at well why would a company sponsor some of these things. You step into this space of, well what's the work in front of you, you know, obviously, the nonprofits mission is, you know, directly, hopefully benefits the company story to its customers. That's the reason you want to sponsor these things and the work that you're doing here all your directly funding services to healthy OSI licensed projects to allow enable them to grow. You can't make an unhealthy project healthy, but you can certainly enable a healthy project to begin to grow faster. You're directly funding the building of the messaging collateral around that so that people have a consistent understanding of the problem domain. You're directly involved in the in the technical discussions that are kind of accelerating innovation in the space. So you're and you're doing this through a shared cost structure. So that's why companies get involved in these things. That's why you would bring a project to one of these nonprofits it's about getting the work done. Next slide. What I what I try and tease people about is if you get it right. Remember, nonprofits worry about the operational side of getting work done. And so, you know, there is a structure. When you start a nonprofit, you know, certainly when you started a nonprofit through the Linux foundation as we just did for the consortium example. One of the things you received was kind of a proto meta. Here's your charter. And of course the charter talks about, you know, who gets to vote and how to votes happen. And what I keep trying to encourage people as we build this operational practice and experience out is voting should be amazingly boring. So voting should be about money and members and voting on the minutes because you have to have minutes on record kind of thing of who attended. If you're going to maintain that antitrust protection, you know, who, who, who, what decisions were made, what action items were captured kind of thing. So voting should be really boring things. Do we have enough money for the programs to support our projects. Do we need to increase membership somehow. That kind of thing. And I'm going to hand it back off to Sarah again to talk about a very explicit example again in the CNCF space carrying on kind of what what happened next with Kubernetes. So in creating the CNCF as a home to land Kubernetes. We had some pretty big visions about what we thought we wanted to do and where the Linux Foundation now has these bylaw templates there was a lot less of that in 2000 late in 2015 when we were starting to build the CNCF so we actually built for very interesting structure inside the CNCF modeled after the US government with the three branches of government that were checks and balances to one another. So the CNCF had three governing bodies as a start and still does today. One is the governing board. So this is the traditional money. Sorry, money minutes members. Is that right. Fantastic. Fantastic. And marketing will throw a fourth one in there. But it's a money. But it's part of money. So we'll so that was that the governing board was built for and then as a countervailing weight was the technical oversight committee and that technical oversight committee was tasked with the technical vision for the foundation. The job is being cloud native look like it started with a cloud native definition that's evolved since then. There have been white papers that have been developed but telling the story of why cloud native and how these projects as a part of the cloud native computing foundation move that story forward. So the technical oversight committee is also responsible for choosing the projects that are allowed into the into the foundation and for documenting the way that those projects are chosen as well. So making sure again transparent trustworthy and able to be audited as decision making processes right at all down. The third leg of this stool or the third check and balance in this was the end user committee and that took about another year to get off the ground in order to make sure that we were getting the voices of end users to participate people who are actually experiencing using Kubernetes and later all the associated projects to give feedback about the project as a whole that isn't maybe technical or potentially is technical but maybe more at a vision level where the users wanted the projects collectively to go relating to this cloud native vision. So with this three bodied organization and governance, I will argue is it was a little complex to implement and at this point we still have some challenges that CNCF is struggles with getting mired around decisions occasionally. And I suspect that some of that is we spent more time figuring out a what a complex structure that projected to how big and how impactful the CNCF would be in three or four years. But when we first began it was by no means a minimal minimum viable governance, and I would argue it might have been a little complex at the beginning. It certainly took us a while to implement, but it's an interesting case, and it's a great one that seems to be finding its rhythm now, especially with more than 30 projects actually I think more than 50 projects inside of it now. And of course, having developed this amazing ecosystem that is changing the industry. So next back to Steven for some other from other nonprofit recommendations or anti patterns, anti patterns, anti patterns, things, things that go wrong in governance that can literally break the nonprofit. I've chosen three examples here, and I'll talk about them each in kind of a light way, the Symbian Foundation. I had early access to the plan, and was trying to explain to folks why the plan was not a good plan. It was basically breaking that trust, and that everybody's equal game, but it also broke the financial model. When the when Symbian Limited was broken apart, and the Symbian Foundation was created the Symbian Foundation was created in early 2009 with 200 employees. I understand that in 2009, the next biggest nonprofit in this space was probably the Eclipse Foundation, and it was an order of magnitude smaller, even if you counted up all of the contractors. And then there was this idea that somehow Nokia's engineering team would do all of the work and then push the project that release into the Symbian Foundation where all of the other members would have access to it so Nokia was always first amongst equals. And so that was that a disenfranchisement baked into the rules and baked into that governance right from the first day, and it quickly fell apart. A year and a half later, the Symbian Foundation and collapsed. The outer curve was a really interesting example now is the technical director at outer curve for three of its four years. And again, the challenge was around getting the money right this time. Microsoft helped sponsor the organization into existence as a nonprofit that would be kind of a more open organization in terms of the projects that could work with. There was some kind of flavor of yes this is something that might run in a in a Microsoft centered set of technologies that wasn't a requirement. So there was no infractions in the license, but it was just trying to encourage an ecosystem there. But we also immediately ran into the membership problem. And even though there was another major sponsor along the way. We could never get the work in front of us balancing that and the money problem with the solving projects problem. And even though we got up to 29 or 30 projects over that three and a half years that I was around it. We could not get the money right on the back end and it eventually collapsed as well. It's an interesting example, only because again there's that sense of disenfranchisement in its early life. It is still a foundation that's with us it's a sub foundation within the Linux foundation, but in its very early governance charter again very heavily subscribed lots of rules about who gets to vote right up front. There was one vendor that was very clearly first amongst equals. So from the get go trying to attract other members. If you picked it up and read the governance it was like well hang on that company gets all the votes. And that that governance challenge wasn't just baked into the organizational structure of the nonprofit it was baked into the project that you know the early cloud foundry project basis, again was so baked around a particular way of doing project governance that if you genuinely wanted to broaden the participation in something other than doing one company's bidding, it would cost another sponsor, millions of dollars to set up that kind of supporting organizational structure within it so it's if you don't get your governance right. You can have severe consequences for the growth of the project. You know the cloud foundry wrestling with those issues ended up in a situation where other technologies passed on by. So getting this rate is is is difficult and so I want to bring it back to the next slide please. In the same way it's Sarah talked about, you know, being disenfranchised as a contributor in a project. If you're feeling disenfranchised as a sponsor in one of these organizations, or again if the rules are preventing people from doing valuable work. There's likely a governance problem that needs to be fixed, and it may not even be deliberate it just might be that you're now overwhelming those that minimum viable governance, you're overwhelming it now and it's time to evolve the governance structure instead of starting with something heavy weight. The next slide. Yeah, so this is my closing thought. I love this quote. It comes from David Clark, all the way back almost 30 years ago. The IETF context the IETF is the group that continues to build standards for the internet that provides us all of our services. And the statement at the time that best summarized their governance and that culture of governance was we reject Kings presidents and voting. And while they meant something slightly different in that expression of running code 30 years ago in an IETF context. I still use this as kind of a quick and easy razor when you're looking at other governance structures because there is that idea of are you are you building a culture of enabling work. Building that culture and the governance to support that culture, setting people's expectations to enable the work to happen. Sarah. And my closing thought is, make sure you set your culture well, because that will be the underpinning for your rough consensus, it will be the way that you're able to collaborate for that running code. And it will be the way that you will have a trust worthy and a trusted environment to evolve your governance as you need to as your project grows. Thanks very much. Thank you for your time today.