 And thank you all for being here. This is actually, I'm not used to being biked up in a small room. It's late in the afternoon, late in your day, and I'm sure everybody can't wait to get out to their evenings. So I'll try to at least be entertaining. Hopefully I can reframe your thinking about some of this work that we're doing right now in the nonprofit space. This gentleman, this is Mr. Maslow. Abraham Maslow was an American psychologist from early 20th century, died in 1970. He is the one that gave us the Maslow's hierarchy of needs. And he is the one that famously gave us the idea of if all you have is a hammer, everything looks like a nail. The reference to the Birmingham screwdriver is people from Birmingham, I have been assured, are tend to be rather forceful in the way they approach problems. And this is also a Birmingham screwdriver. So I'm worried, and I joke that I'm worried, maybe I'm tired, maybe I'm just old. But we're at a point in the industry where I've been doing this stuff for a long time. I've touched a lot of nonprofits in the standards and open source space, going all the way back into the 80s. And I've had lots of different roles in them. In turn, I have been staff in a nonprofit kind of thing. And I've been a volunteer in lots of places. I've almost always done this engagement from a product management perspective. This is kind of why is this standard important in our product space or to our customers? Why is this open source project strategic for us to enable or in which to participate or to create all of those kinds of questions? And over the last few years, there's been a definite feeling of acceleration. It's coming faster and faster and faster. And a lot of that has to do with lots of new vertical industries that have seen the success of open source in the traditional software infrastructure spaces are starting to go, I want some of that. And so there's this idea that if we just start an on-profit, we'll have Kubernetes. And it's an uncomfortable feeling because we're starting to actually see cracks in the foundation. That's the closest to a dad joke I can come to. And we're seeing it across the foundations. It doesn't matter whether we're talking about Eclipse working groups or Linux Foundation directed funds or the Apache Software Foundation was having lots of board problems for a while. There's this acceleration of new nonprofits, new projects, new sub foundations and they're all struggling to establish governance. They all think, I need a charter and somebody has to tell me how to vote. And that struggle along those lines as well because it has to be fair, right? So we have to care about voting. And there's also this conflation of specifications work and open source community project work. And I'm really uncomfortable here. And for the gentlemen in the nice suit, I have to work the P word into this talk at least once. So I was involved in the POSIX standards for 10 years. So I know what big heavy duty de jure standard building looks like. And lots of folks tend to, there was a period of history going back about 10 years ago where it was like, ah, we don't need standards anymore. We have open source now. And collaboration, it's engineers collaborating. These two things look the same. And so you see this actually this race to the middle where all of the traditional standards building organizations think, I need to have an open source message. And all of the open source organizations are going, how hard can this be? We already have collaborating engineers. We'll just set up a specifications org. And these are very different tools economically. And they don't necessarily go to well together. That doesn't mean they don't compliment each other nicely. There's lots of going all the way back into the internet foundational standards. And the rise of patchy, the rise of W3C, these standards being reflected into open source projects, these things do relate to one another. But you have to be careful about how you think about it. And they don't use the same processes. Of course, what that means is there's a small group of us that invariably get asked to talk at these things. We all have a set of slides. We all bring out the trust and transparency slide at some point to have a discussion about that. Likewise, we all have to, I think this is Denise's slide. We all have the chop, wooden carry, water slide. I work for Sarah Novotny. This is one of Sarah's slides. We will invariably have a discussion about richness and diversity in building inclusive communities. This was the slide I added. I'm probably in copyright violation on this one. I always bring in that idea in paraphrase JFK and his, so I always go after this idea of ask not what your community can do for you, but what can you do for your community? And what I'm really actually thinking of changing the text on this slide because I am tired of the magic thinking around this amorphous, vague community. And I've started insisting, especially to product teams, especially to product teams at Microsoft, perhaps, that there is no community except for the one that you build. That is the only way you can conceive of this. And that doesn't mean that there aren't people that aren't willing if you build the on ramps to engage, that you never planned on engaging, that people will come if you build it, but you actually have to do work and build it. And so I wanna come back to kind of a couple of questions to start to set a model in place to how do we think about some of these challenges in front of us? And one is, how does an open source project work? What is that kind of economic unit? And then what's the purpose of an open source nonprofit? Because that's a question that people really need to ask. And most people come in with the kind of the simple connection of if I go do a nonprofit, I'll get a Kubernetes. And that's not the way these things work. And especially if you look at the history of the Linux Foundation, a lot of people kind of go, Linux, Linux Foundation. And you have to, if you go all the way back through the history of the open source development lab, that was the original nonprofit before it got rebranded and recreated into the Linux Foundation. It was a messaging platform and an antitrust safe place for the big computer OEMs to actually protect the liability and do risk management around the Linux operating system and this merry band of folks that were helping create it. So again, there's this, what are these things for? And it's important to ask these questions because a nonprofit can't fix a broken project. Just taking it to a nonprofit's not gonna do what you think it's gonna do for you. And likewise, nonprofit governance isn't project culture and isn't project governance. Again, these are different units with a different way to think about things. So when we look at projects, the core of a project, there are some maintainers, probably very few in number. And they are sharing innovation outbound. That's the economics of what's happening here. There can be no expectation of anything in return. The license says so. And likewise, projects tend to have a culture. They can have a governance, but the initial governance is really just documenting that the engineering practices of this small group of people. If you build a community, remember you have to build the community you want, then you're actually looking at capturing inbound innovation. There still can be no expectation of anything, but at least you're now building the on ramps to enable and encourage that inbound contribution flow. That's the point of building these things. And communities can involve governance, but again, it's a documentation of the practices and processes. One of the best examples out there is the Kubernetes governance. That was something that was deliberately put in place in a very short period of time and put in place in such a way that as itself organized, it could grow and evolve so that it is a very well documented project governance that captures the culture. But if I said point to the same level of governance around the Linux project right now, I bet you'd all be hard pressed to find out, be able to point to a single website that captures what that is. The Linux project, equally vibrant, equally huge and important, is more of a culture than a governance. And if you do it all right, the magic happens, you get an ecosystem. If you genuinely have this flywheel spinning up where people are selfishly pulling from the bucket, realizing the economics of living on a fork is a horrible place to be and contributing back and you've made it easy to contribute value back to the bucket. Now these people are doing things for a reason. They're building products, they're building services. There could be books, consultants, contractors, all kinds of things. You end up in a rich ecosystem if you spin this up. But this is actually a bit of a lie because there's another step along the way. Now we know that foundations are important. Non-profits have a role. And we know this because a dozen years ago, Henrik Engo did a big number crunch back when the numbers were simpler and there wasn't 200 million repos on GitHub. He took the data, he did the number crunch and you end up in a space where the nine largest most vibrant communities were all hubbed inside of non-profits. The tenth in terms of code base and vibrancy inbound contribution flow was an order of magnitude smaller than the ninth and hubbed inside of a company. Henrik's a really good engineer. He did not claim causality here. But there's clear correlation, something's going on here. And so somehow non-profits have a purpose. A slide I used to use was this one. This is kind of this idealized, stylized, you start with some maintainers, you get some contributors, you're building a community and then you end up with magic at the end of it all. But what actually happens is two problems come along. One is personal liability starts to get in the way. Maintainers want to hold a meetup and it requires a hall. Whose name went on the hall? Whose insurance is covering that? If they had somebody that wanted to contribute to it, whose bank account is holding the money? And if there's a problem in any of that chain, whose liability is it? The other problem you end up with is the corporate contributor problem. Companies want more stability and that idea of stable ownership, stable maintainability, sustainability, all of these words start to creep in. And so corporate contributors, before they really commit to being a part of this community, they want to see some stability. And so what actually happens is you end up with the growth stops. And it can't get past these. Except the joy of it is a non-profit is actually the solution to this problem. The non-profit as a legal structure takes on all of that liability. And it becomes the holder of assets, the holder of the bank account. The non-profit provides IP neutrality and stability from an ownership perspective for the assets as well. And it doesn't need to be a big one. There's just a legal entity now in place that can absorb this. This is, for my German colleagues at the back of the room, it's the farine. There's this idea, there's this really lightweight legal structure in Germany called a farine. And every sports club has one because it's trivial paperwork to spin up and it now means that you have a place to park a bank account that's a legal structure instead of it being somebody's pocket. But we also have a problem with this rush of industry into the room of, okay, so we've got corporatoned open source projects. Now, this is a bit of an oversimplification. I've kind of thrown all of the kinds of software projects that you could invent into one bucket and there are three kinds of projects. And which kinds of projects aren't really important right now. But again, you have this messiness of all of these people that have business relations with you now falling into this debate as well. And the real reality is nothing looks like this. It really looks more like this. You have a company with maybe a strategic open source project looking to find partners to maybe do something interesting in this space. And it really is about partner engagement at this point. You know, hopefully some customer co-creation, but it's about partner engagement. And so, you know, you're wrestling with this strategic open source project. And it gets a little messier than this because, you know, at the end of the day your competitors are in the room as well as your partners. And if you're not careful you can easily turn partners into competitors in a product space or a service space if they start trying to do things with your project that you weren't prepared for. So again, this project growth hits a ceiling if you're trying to do it by yourself. So we've got the idea that, you know, we're building the software, sharing innovation outbound, we're building a community, we're capturing innovation inbound. But now we've got these two cases. One for an open source project in the wild and one for, you know, kind of things that occur with corporate open source projects where it's a really nice solution to use in non-profits. So that's what we're seeing a lot of this race to non-profits about because it solves for these things. On the corporate side, it's a different pair of problems. Corporations can absorb their own liability. They don't have the liability problem. But as soon as you get too many partners in a room you do have to deal with the antitrust problem. You have to demonstrate that there are rules and we are not colluding. You know, likewise, when you start looking at signaling a certain amount of neutrality to your partners, taking the asset and parking it in a non-profit so that they are no longer working on your assets for your products, it is a strong signal into the marketplace. But that's now added, you know, a new set of skills that we have to worry about, right? Because all of these skill sets are different skill sets. The software engineering that goes into sharing outbound innovation and anchoring the project creativity, that's a set of skills. When you step into that space of how do I build a community? You're starting to step more into the people management skills and more into the program management. You know, program managers do a better job of this. Developers tend to do a better job of building the software. But it's still a separate skill set and you're doing separate activities and you're different activities. But when you step into the non-profit space, we're into a different space again and I'm finding there that's the other speaker that I'm hooking up. Now you're into a different place and building the non-profit requires different skills again. And so you need to start worrying about the stability of the non-profit, how do you manage a non-profit? What are the rules around non-profit? So there's a whole lot of extra work that goes into this. And it becomes kind of this collection of different cultures and practices. When you're building the software, so that core maintainer culture, we're talking about a culture of enabling work. You're trying to find ways to say yes to people that want to give you things. When you step up a level into building the community, well there's a whole lot more that goes into this. This is now in a place where you want to start figuring on how to build adequate on-ramps to encourage those contributions in. And to encourage contributions in, you need to be expanding your area of use because that's where you're gonna find developers that do selfish things and you need to make it easy for them to give you stuff. And as you expand that area of use, you also find other users that want to contribute everything from bug fixes to tutorials to all of the things that make their life better that they're happy to share, but you gotta make it easy. So that's a different culture. You're enabling a cultural contribution. But you also need to be enabling a mentoring because one of the harsh lessons being learned in the Kubernetes community right now is despite the fact that it was done in a brilliant way to enable massive rapid growth, that idea that we have to train up the next group didn't really stick. And they're now in their third generation of kind of project management. And again, we're starting to see fractures in the foundations where things aren't as smooth as they were through some other accelerated growth. And so that's really different too. Works better now? Thank you. And then lastly, when you step into that nonprofit space, we're talking about a culture of promoting stability. And we're also talking about a culture of organizational responsibility. I had a really shocking discussion because there's a lot of chaotic discussions about organizational responsibility. That's not what we say we're talking about, but you run into these things. Why is it this way when I was doing things in one nonprofit, it was very hard to understand why suddenly there was a lawyer from the nonprofit telling us why we had to do things differently. And that was a little bewildering. And I get along with lawyers, I work with them a lot. I was surprised at why a lawyer thought this was something to get involved in. But that's because I was misunderstanding something in the structure. And at the same time, I've had a very different, very direct conversation in a different nonprofit where they were very direct and blunt with this is how it works here. And this is how it works here was based on the fact that it is the governing board of that overarching community that is responsible, that they have a fiduciary responsibility to be able to tell me where every penny went. And so they structure things to ensure that that is completely transparent and completely auditable at all times. You still have that culture of mentoring new members, though. Now, as you build these things, you still have to think about the next generation's coming, we all don't wanna do this. Some of us might retire one day. This really is the money slide. This is the one that is kind of the anchor of all of us. There's a complexity to how you think about the structures and the models for what we do when we talk about these rich spaces of nonprofits and open source projects that it involves being able to break these things apart so you understand that this activity I'm doing for this reason. Because if you don't understand why you're doing it, then you're just aping it. And when you get into trouble because something needs to evolve because you didn't understand what you were trying to accomplish at the time, you're not gonna have an easy time finding the solution. Invariably, we all get forced to either fail. There are lots of nonprofits that are no longer with us or they get into trouble and they have to completely reshape themselves and then they're possibly still a nonprofit but not the same nonprofit that they were. And depending on how we as a membership might treat that thing, it becomes awkward because the reason you gave the money has changed. And part of this is also understanding that the two columns on the left really are about project community. This is about people. Whereas that column on the right, that's about a legal structure. And you have to think about those things differently in that perspective as well. The shocking thing about the discussion I had that was so blunt and direct, it was actually with the executive director of the Eclipse Foundation. And I had asked a question like why do working groups work in this way that we the members have put a pot of money in front of you? But kind of as the working board of this working group, we don't get to say what the budget is. And the thing is, I have to stop you right there. He said, you're a steering committee, you're not a board. Now I happen to be the Microsoft Strategic Board Member at Eclipse, so I know what he means. Like I'm down here in the steering committee. I'm also a board member, but as a board member of Eclipse, I have a fiduciary responsibility and they have a director's and officer's insurance policy that covers me if something goes terribly wrong. Down here in the steering committee, do you know insurance does not come down to our level? And so we don't have a, and my co-members of this working group are actually in the back of the room, we don't have a fiduciary responsibility here. We as members representing our companies have put some money in the bucket. And we, as the steering committee said, here's our program plan of work. This is what we want to accomplish this year. And then the Eclipse staff say, thank you, and they take the pot of money and they take the program plan and they align these things and present the budget to us. And then they start delivering work against that and giving us quarterly report, because that's the level of fiduciary responsibility they believe they have to us to manage the money we gave them well against the thing that we as a steering committee approved that we wanted them to accomplish as members. That's a very clean, crisp, the first time you see it, it's a little awkward, but it's very crisp and it's very transparent and it allows good things to happen. Some of the hardest cultural discussions though that I have with people is making sure that they understand that all of these non-profit things, just like project communities, these are infinite games. You have to behave differently in an infinite game than you do in a competitive finite game. And so it's all about building trust and collaborating and cooperating, even when you're in a room with your competitors, but the competition happens outside of that room. You are still vicious competitors in a marketplace and the marketplace behaves according to finite game rules. But in this space, you have to build trust together and there's ways to do that. It's kind of the obvious ways because it's just communities of people, right? It's being good neighbors. All the stuff we know about being good neighbors applies. If you see competitive behavior show up in one of these non-profits, it breaks trust and it breaks trust very quickly. Absolute transparency and avoiding these competitive conflicts that builds integrity and it builds trust in the organization. So you have to think differently when you step into the room to make these things successful. Of course, none of it's this easy because the money slide that I just showed you is actually infinitely more complex at this point in reality because we have these umbrella organizations. We have the Eclipse Foundation. We have the Linux Foundation. And so, again, when you have that upper level, this is exactly the kind of Eclipse working group discussion that I was just giving you the example. All of a sudden you now have, no, no, we have lots of projects. And it makes sense that you could, for efficiency reasons, we could park it underneath the existing non-profit structure. But even that starts to shape the shape of the non-profit. And so you end up in this space where, okay, so I'm building project communities under here and then I'm building many non-profits underneath the non-profit and it's this race around of complexity and you start having to take that next level up of how do you instantiate the culture so that these things can be successful as well. Because, again, the rules are changing because you're doing slightly different things in this group. It's nice and clean doing things at Eclipse. I swear to God, as a person who works at Microsoft and does this strategically with projects for a living, I will be bringing work to Eclipse because it's nice and transparent and there's lots of predictability. A lot of people get worried. They go, well, I really like things in some of the other organizations where they don't tell me what to do. But that now means it's chaotic. If you have the right people in the room, you can have a lot of success. If you don't have the right people in the room or you have a bad actor trying to do competitive things in the room, you have chaos. If you step into an Eclipse working group, I now have a working example in front of me of the stability that all of those rules provide. And the joy of it is the other thing about the culture transference here is Eclipse immediately wrapped staff around the group of us as early partners to tell us how to succeed in partnership together in their structured world. So there was a transference of culture immediately. We could have gone and read the very deep pile, if we printed it, it would have been feet of paper to try and understand all the rules but still wouldn't have given us culture. Whereas what they did is they immediately wrapped staff around us to give us the cultural transference to understand why the rules work. The other piece, I'm doing a piece of work right now within the IEEE, I've gone back to the IEEE to do a standard again. And again, it was that exact same reality check of the IEEE's been doing standards for decades and decades and decades. It's feet of paper, of rules on how you build a healthy standard. And the first thing they told me was, well, you'll have to take this course to be a working group chair. And it was a 12-hour course. And even though I've done this kind of work before, that was 20 years ago and maybe I'm a little rusty, maybe there's some new stuff. It was an amazingly useful 12-hour course. And it's free, I would highly encourage all of you to go take it, even if you aren't doing IEEE things. But the next thing they did is they assigned an IEEE staff program manager to me. And this program manager has been an enormous help at anchoring the first couple of meetings for us, again, doing the cultural transference so that the group of us can be successful together building this recommended practice. So it's this idea, and you see it in other places. The IETF, the Dow of the IETF is an enormous document and they have even more rules printed behind it for the actual rules of how to build an IETF standard. But the first thing you get when you show up at an IETF event three times a year is they wrap, they lovingly wrap a Day Zero event around you to tell you how to be successful here with us in our process. For all the things that OpenStack got wrong, their Day Zero cultural event for developers and program managers is letter perfect to this day. They wrap a Day Zero, oh, you're new here. Please come and let us show you how to succeed here. So this idea of culture rather than just a set of rules and that cultural transference and the stability that comes with that is a pretty amazing thing. And the kicker with this is we've always known this. We live with our neighbors, we live with homeownership, societies, we have clubs, like this is just the way human community functions. And having it written down and having some rules with that engaged understanding that part of your responsibility as being a member of this community is helping transfer the culture to the new generation of people that are going to join this community. At no time have I been talking about growth because right now I think there is another set of problems that are occurring in our space and that's everybody thinks they have to grow. We need more members faster. We need more projects faster. And I'm sorry, I call bullshit on that. You need in a project community, you need the community that wants to build the software. 20 years ago, I stood in a usenix audience, the person presenting at the front of the room was talking about building the video drivers on Linux community. Roll the clock back 20 years. You know how small that community was. And the presenter said the nine people on the planet that deeply understand this technological problem are in the community already. And then they said magic. For every thousand users, we get about a hundred bug reports of which 10 people give us a patch of which one read our contribution guidelines. And that was kind of this magical idea that you could have a very small dedicated community of specialists around a particular project. But that didn't mean you didn't still have a growing user base out there that still identify with your community but aren't necessarily active. For those that have seen me talk in other venues, it's like I'm a big one for saying freeloaders means you're doing it right. You know what that person said at the front of the room is for every 900 freeloaders, we get about a hundred bug reports of which 10 people give us patches. And in that hundred bug reports, I mean that's a lot of triage to do and there'll be a lot of overlap and such that they have to triage out of the way. But that's the kind of way this works. It's not about growth. The reason I say that back in the heyday of the growth of OpenStack, this is what their landscape looks like. Look at all of our projects. Look at all of our members. It's all thrown in a bucket together. There's lots of us. We are important. Not to be outdone. Cloud Native Computing Foundation started the landscape. And now there's many landscapes within the Linux Foundation community. Indeed, this landscape grew up to be something that is completely unreadable at this point in history. The horrible, horrible of this is it gets even stranger. I can't actually read it on this diagram. I don't even think I can find it blowing up this big. But somewhere around this landscape, if you go online, you will find a statement like this. The 1,100 cards it's referring to are artifacts within the thing. It could be projects, could be products, could be members. Three million GitHub stars. Okay, we've been arguing in our industry for at least 25 years. Does downloads mean anything in an open source project? Does it tell you anything meaningful? You had a million downloads. Does that mean you have a million users? Well, we could have the software phone home and then we all go, that would be wrong. But that idea is there, that downloads are useless. They always have been. We've known that forever. Stars are even further. Like that's one step removed from downloads. At least downloads, they did something. A star is like, I don't know. Somebody clicked on a button on my webpage. Is it meaningful in a sense of we're trying to have a discussion here about how we organize ourselves and do work? Market cap of $20 trillion. Now this one I take great offense to because that's how many dots on the landscape it took to get to $20 trillion. Okay, so I am the governing board chair of the Confidential Computing Consortium. We're 30 members and we already have a market cap. So I must be doing it better than those folks in CNCF. Market cap is irrelevant here because as soon as, you know, the reason we're at that market cap is, well, Google and Microsoft are members of the CCC. And by the time you add Facebook and Apple and AWS to CNCF, okay, five members makes up half the $20 trillion. Maybe even more than half. So it's an irrelevant number when you're talking about what's the value. It's an interesting number though if you're trying to drive membership. And the same thing with the funding. We have all of these startups, 53 billion dollars in startup funding in the CNCF landscape. Okay, so we all know the rule of thumb. One out of 10 startups will hit the home run. Three of them will have a mediocre existence and maybe an exit of some kind and six will fail. Okay, so which $5 billion or the $50 billion is the meaningful bit? That's my question. And so these numbers aren't helpful numbers. Saying we have a landscape and it's got all of these things in it and these are the big numbers. These aren't helpful numbers to guide us as a community on a project and they certainly aren't gonna guide us as a non-profit unless the only metric we care about is inbound membership. I didn't say it out loud. So I just wanna come back to the money slide. To me, a lot of this problem is being able to develop a model that is actually a useful model so we can build healthy communities. We can get past those harsh boundaries of liability, corporate stability, signaling to partners that we really do wanna work together and we're willing to give up ownership of an asset so that we can do partner engagement in a more of an equals setting rather than a whole lot of bilateral agreements. And I think it's important though that it's not just understanding it but it's breaking it apart to understand these different cultures that have to apply and knowing when you're having which discussion. Because if you know when you're having which discussion that's when you can step into the space of actually being able to solve real problems because there'll always be real problems because these are people systems and as villages become cities you suddenly have the societal problem of the old Dunbar number, we all knew each other suddenly it becomes something different and you start to have to put practices in place for how you have certain conversations and how you manage that natural growth of human communities. How are we doing for time? Ow, I hit the mark that cleanly which gives us the Q and A slide. Questions, where am I wrong? Please. So first thanks for talking about this important topic. I gave a talk earlier today on the same topic with a slightly different angle coming from the non-profit side. Guess my question is you have this slide that shows the SRO to success or N. The stylized error. Do you think every project needs to get to that ecosystem success? And the other complementary question is do you think every project that needs to get to that point needs a non-profit to get there today? It definitely needs the non-profit. If the goal is to build an actual ecosystem and so this is where it falls into more of these important spaces. This is the Open Infrastructure Foundation building an ecosystem. And even though that ecosystem mutated from the OpenStack Foundation into Open Infrastructure and it became more of a telco focused thing it's still for those members it's important that there's a real healthy ecosystem here and a richness to that ecosystem. And I don't believe you can get past the problems in growth to get to that ecosystem without having the non-profit there to provide a stable place for antitrust discussion or antitrust protected discussions. A stable place for ownership of assets. A stable place to have all of these discussions. But that's why like I really I push that into that right hand column. We're having a different set of discussions about the success of that ecosystem rather than a set of discussions about how does this project behave well. And it's a challenging problem. I can be very frustrated wearing any of my Linux foundation hats because certain projects go really well. Some of them can make lots of money with trade shows and some of them are catastrophically disorganized. A lot of my job at Microsoft I do a lot of this. So the way Microsoft divides and conquers our open source programs office is inward focused engineering practice and process license compliance tooling all those things. The open source ecosystem team that I work for Sarah and we're outward focused. So we're helping product teams. We're helping do all of the outbound foundation work. But I keep stepping into these things where a product team helped start a foundation and now they're all sitting in a room looking at each other saying, now what do we do? And because they started it in a place that didn't have prescriptive guidance and didn't have cultural transference, they have no place to start. And they flounder and they could flounder in bad ways. There's one that I've been party to for the past year and we're just now a year in starting to get it onto an even keel and there's still no promise that it will. So I think the nonprofits are absolutely urgent to get to that successful ecosystem. Thanks, Stephen. If I'm getting you right, your call is governance is a good thing. And we need governance to be successful in ecosystem building. And I can relate to many of those things you were saying. I'd like to be interested in understanding is there also a chance of having too much governance and what would it be? That's a great question because if you had of asked me that five years ago, I would have easily answered yes, you can have too much governance. And I would have looked at something like the IEEE as something that I would have said, that's a lot of process to build a standard. Or I would have looked at Eclipse and said, that's a lot of process to run an open source project. But when you stand back, I mean this is the joke between Jeff and I all the time about me always talking about my POSIX experience of 30 years ago. The reason the container format is what the container format is today is because it has a tar archive inside and we got the standard right 32 years ago. Because that was a weighty process with rules and that standard still stands today. The evolution of Wi-Fi standards are all IEEE 802 standards. They have kept pace with technology as it's advanced, but there's a separate organization that deals with the trademark and the branding and the patent pools and all that other stuff out there. But the standards process is clean. When you step into the Eclipse process at this point in history, the Eclipse IDE is still relevant in some groups. But it's that process I've come over this last five years to realize when you look at it brand new, you come to the website and you say, oh my God, all of this documentation and it looks painful. But when you step back and realize the experiences I've had in those two places over the last year of no, no, there's a pile of documentation that is there for a reason. And the next thing they do is hand you a program manager that will walk you through it. And allow the culture of that documented process to succeed. You start to realize it's actually the culture that's more important. The documentation is just the documentation. And that becomes the aha moment for you, realizing actually the stability that comes with all of this process, as long as you have a mentored way into it, is actually very powerful. So there could be, there could not be too much governance. I don't think so. I haven't encountered it yet. And the reason I'm, like I said, this is an evolving opinion because two things that I thought were too heavy. And I can throw in the IETF in there as well. I remember trying to get myself through the Dow or the IETF the first time. I was like, oh my God, this is painful. And then I started working with somebody. I work in one organization with somebody who's had 30 years of running IETF working groups. And I've watched how they behave in the work that I'm working with them closely right now. And it's amazing to see the engagement that they are able to drive based on the cultural experience they had in the IETF. And then you look at these, the Day Zero at an IETF event where the first thing they're doing is teaching you how to be a good participant in the IETF so you can succeed. I was like, okay, that's the secret here. So I haven't seen a case yet where there's too much governance. But I'm rapidly, like I've rapidly evolved this opinion. Thanks. Don't give the microphone to him. That's it for one more. It's kind of a weird question. So since I last talked to you, I'm working now for Open Source Collective, which is a fiscal host for 3,500 different open source projects. Which is great, but fiscal hosting is only half of what we kind of do because we're technically a 501C6. And so we'll take on branding for you. We'll do accounting for you. We'll figure out how to get a sponsor as a major funder. That seems to me kind of weird in your model. Like I'm curious about what your thoughts are for them. Not at all. You were doing exactly the thing that's required for all of those smaller projects in the long tail that are in the wild that suddenly hit this point of what do we do with the bank account? Like the next thing out of their mouth is going to be like, how do we hold the asset? Well, a brand is an asset. So you did the perfect thing to solve the liability problem of taking on the bank account and providing legal structure. But as soon as you start doing the asset ownership, you've removed the rest of the risk problem for those small projects so that they can figure out the next steps. So now that's, Open Collective does a great job. I have a problem with companies that think they're funded to do that kind of thing. But Open Collective, as a non-profit, I think does a brilliant job. So well done, thank you. Okay, cool, great. Yeah, that's pretty much answers my question. I mean, I was just curious what your thoughts were about that in the long term. But I see like as a project will grow, it'll need a different space, which is great. Yeah, and this is the thing. You give the project the tools for growth. There may come a point where somebody's going to ask Open Collective to take on something that's a little bit different. And folks will have to be very careful in how you choose to evolve at that point. Thank you, everybody, for staying so late today. It's been really helpful. Thanks. Thank you.