0:00 On today's episode, we're diving into open source sustainability, which apparently means way more than just please donate to my Ko fi. We got to chat with Hazel, who somehow managed to explain the entire economy of open source in about twenty minutes, well making us question everything, everything we thought we knew about sustainability. I mean, David asked just one rage bait question about whether open source can be sustainable, and Hazel just answered, like comprehensively, with citations to Eleanor Ostrom and everything. Yeah. I may have taken some notes. There were at least eight principles of sustainability communities mentioned,

0:41 and I'm sure that Hazel had them memorized. We covered trust, reciprocity, VC funding models, ego death of authors, and why browsers should basically be treated like public utilities, you know, like light topics. And I'm glad you said because I can't see it. I also learned that if you don't want to be woken up at 3AM by nation state actors, maybe don't maintain critical infrastructure packages in here. David actually managed to avoid asking about Rust for once, but did squeeze in a question about the Chrome DOJ case because apparently we're doing hard mode today. And Hazel's

1:15 answer, we need to scale collective ownership up to humanity. No big deal. Just your average Tuesday conversation about the future of human civilization through the lens of package managers. Enjoy this episode. Thank you for joining us, Hazel. Could you please take a moment to introduce yourself to the CloudHealth Compass. My name is Hazel Weekly. I have thoughts, lots of thoughts. They never stop thinking and they never stop thinking. And I am very much looking forward to being here. I'm on the Deaf and Hard of Hearing group at the CNCF. And I'm a fellow of the Nivoli Foundation.

1:46 And one of the things that I've done a lot of my time is trying to figure out how to help open source communities and ecosystems and people figure out how to do what they enjoy in a way that's sustainable and grows and builds something beautiful that the entire world can benefit from. And how do we teach the world to be better at taking care of our communities and help our communities grow to become more collective and more beneficial, more wholesome and inspiring for everyone? I don't know that we can follow-up with that. I mean, that was just like perfectly encapsulated

2:21 right there. So we just got the podcast right there. Yeah. Thank you all for listening, folks. We'll see y'all later. That was Angel. No. We're really excited to have you on. So I'm looking forward to this conversation. But of course, David and I, we never actually prepare questions because we're great like that. Do you wanna start there? Conversation is not an interview. Right? We're here to talk with people we like, people we aspire to be, and people that are kicking ass. He's a little bit of all of that. But I do love that you started with, say, an

2:52 open source and sustainability in the same sentence, and you meant it. I mean, can open source be sustainable? I mean, we can talk about numerous Oh, jeez. That's harder. That have happened in the last twelve months. But let let's just go straight into the hard question. Like, what how does this work? Yeah. How do you make open source sustainable? Let's talk. Should we start there? So when people talk about sustainability of open source, I think it's important to understand where they're coming from when they talk about sustainability and what they're wanting to get out of

3:27 it. So if you think of open source from the sort of semi impartial global perspective of a common shared resource, then you can think of how do common shared resources become self sustaining, self organizing and become, you know, not exploited and not, you know, drained out. And how do you make them work long term? And you can look at that. And there's some really great research by Eleanor Ostrom, who talks about that and who has about eight to 10 sort of properties and principles of sustainable self governing, self organizing, shared common resource groups, and how to actually build governance structures that

4:11 do that. But a lot of people, it turns out, go, oh, that's neat. But how do I do that? Or what does that mean for me? Or what does that mean for my project? And so for them, open source sustainability often becomes sort of a very personal question of if you have an ever growing pile of work, if you have an ever growing pile of obligations and requests from people, how do you as a maintainer and not feel burned out? Or how do you as a maintainer, give more maintainers? Or how do you grow your project to

4:44 have enough energy in it to continue? Or maybe people go, well, have the energy and I have the motivation. I just can't afford to. And so then the question is, how do you translate this enormous amount of energy and interest in the project that already exists and turn that into something that people are willing to pay for, that people are willing to fund and sustain beyond just, that's great. Here's a PR or that's great. Thumbs up emoji. You're doing good. You're doing good work there. And so for other people, open source sustainability is actually more on the company side of things, some

5:26 more on the government side of things. It's a question of how do you build a economy or an environment or a ecology ecosystem that is understandable and intelligible, and they seem like a state perspective. How does a large organization make sense of this? And how do they understand it? How do they navigate it? And then be able to contribute to it in a way that doesn't over extract the resource and in a way that's still valuable and beneficial for them, but without draining the resource. And so it needs to be profitable. It needs to be understandable. It needs to be

6:06 secure. It needs to be compliant. And that's where you start to get people saying things like, oh, open source community should have SBOM, so they should have these bills and articles to make them able to be consumed by enterprises, hopefully with the goal that the enterprises can then support them. Because it turns out that it's extremely difficult for an enterprise to send someone money because sending money is very difficult. Most people cannot absorb the minimum amount of money that an enterprise can meaningfully send. Enterprises can't send the maximum amount of money that an individual can afford.

6:44 So there's a weird balance going on there. And so when people talk about sustainability in that sense, they might talk about incorporating, they might talk about governance structures and legality structures and ways to make it to where the money relationship and the power relationship can fit into existing structures in a way that lets people take advantage of a mutually beneficial agreement. But can open source be sustainable? It depends on a perspective. I think in every different perspective, there's an avenue that can be approached, and there's a way to make it happen. The primary challenge that I see is

7:25 when you have so many different people, so many different collectives, so many different groups with different perspectives on what sustainability means for them, some of which are mutually exclusive or hostilely exclusive. And then you end up in a situation where no one's going to be happy and maybe everyone will be unhappy. And it's hard to find where to start approaching this and where to start solving the problem and where to start trying to tackle things. But I think giving people a sort of the landscape and helping them identify solutions that aren't mutually exclusive or that aren't to the detriment of other

8:06 solutions is a really good way forward to start making progress. Makes sense. There's a lot there, obviously. I guess one thing I throw out a rage ba question, and then you just rattle that right off the top of your head. I mean, fantastic answer. I mean, even the questions I was thinking of along the way you were answering as you progress through that, you know, sustainability does have much more to it than what a lot of people think off the top of their heads. And you just delivered a lot of context there as well as opening

8:42 some questions and closing a few others at the same time. So it was like, yeah, it's this this is a hard thing. There's a lot of different things, and I'm gonna say a thing like 12 more things, but it's fine. You know, I was gonna be really flippant right at the start of it when you started talking about sustainability and say, I know the answer to this one is I changed the license and then I make a lot of money. But, you know, you then brought it into the realm of serious chat, and then I'm out. Like, okay. Maybe I should

9:07 just go to the pub. I mean, if we wanna talk about that, we can talk about that too. Well, I I actually I wanna start kind of digging in on some of the stuff you said more with, if I am an open source maintainer, how do I make that decision of which like, what way do I get to a sustainable project? Like, a lot of the open source maintainers I know, they're burnout, they're tired, they're trying to figure out what to do. Some of them though can't let go. They don't know how to kind of let somebody else take a leadership

9:42 role in a project and start to build out that leadership group because they know how it works. They're that single point of failure. Do you have like advice on how how do you make a decision about your best governance structure, your best way of getting to that sustainability where you bring in new people for especially for those folks who are burnt out and they don't have a ton of spoons to build up a community that way? I'm kind of curious. So when I think of these open source maintainers, I think my first bit of advice for

10:14 them is they need to do personal reflection and understand a couple different things. The first and foremost thing that you really need to understand is what are you looking for? And what are you getting out of this? And so if you're looking for, you know, a funding source that changes what you need to approach. If you're looking for, you know, the fame or the acclaim or the personal people valuing you as a person because you have built this thing. If you're looking for recognition, that's another thing, which is not a bad thing. That's fine. But you should understand that because it changes

10:57 what you mean by sustainable. If you're looking for your projects to be a cornerstone or foundational project for a certain domain, that changes your approach. If you're looking to build a thing and just build it, then that changes your approach as well. And so when I think of classifying these into sort of different kind of approaches and sort of different difficulties, there's the funding difficulty, there's the direction of the project difficulty, and then there's the personal stewardship and your personal relationship with the project. And you can go into different areas, but those are kind of three big ones.

11:43 For the funding one, if that's your biggest problem, then you really need to start looking at what are successful projects that are funded. How do you get funded? And what does that funding mean for you? And you have to start diving very deep into trademarks and legal structures, governance structures that make this possible. Building models, funding models. And basically, have to become okay with the fact that you are going to be a business and sales and marketing person first. And then a programmer at this and forth. Right. You're not really building a program anymore. You're taking your program and you're making it

12:29 sustainable fiscally. You're making intelligible fiscally, you're building that. And at some point you might get to program it. Right. And people go, well, I don't want that. I'm like, so you don't care about financial stability. Right? Like, no, no, no. I'm like, well, is it the most important thing? Yeah, you have to know that. You have to know it. Is it the most important thing to where you're going? I don't care if I write code for two years until I figure out the funding pipeline. Amazing. Now you're ready and you're prepared for what that's going to look like.

13:02 If you are on the other hand, looking for and struggling with this personal identity thing of how do they share maintainership? How do they share the vision of the project? With that one, that one can be tricky because I think a lot of people are much worse at collaboration than they think, because it feels like something that comes very naturally. We do it our entire life, but it's not natural. And we're all bad at it until we practice it a lot. Right. And so with the collaboration, one of the things that I really look at is this notion of

13:44 trust and reciprocacity. And so with that, you have the trust element. Can you trust each other? Can you trust the team? Can you touch people? You can't build a foundation and a vision for them. When you trust the decision that they make, when you trust where they're going to take the project. They shouldn't be in the project or you need some therapy. Maybe both. But you have to get to the point where you can trust them, hands off, and really, really lean into that trust. And so if you're not to a point emotionally, where you have a collective group of people

14:21 building the project with you, and they want to take it in a different direction, and you don't like that, you don't touch them. So you need to go back into the testing part, figure out how to test them. Figure out how to build that. And the second element of that, the reciprocal ness. That's the idea of if I do something, you do something in return. A lot of the times when we talk about trust, we also mean that but they're actually different. Right? When I talk about trust, it's more do I trust you? Do I trust that you have your

14:56 my best intention hard and your best intention hard? Like, do I trust that we can work together? Do I believe in decisions that you made, but there's no obligation of return. And if you're going to build a open source project or an open source community, the community itself needs to shift into this mode of communal caretaking. A communal caretaking means that when people give to the project and they take, or without to always happen. If I take, then I give. If I give, then I also take. I can't just keep giving, giving, giving without taking. That's not

15:34 reciprocalness. That's me dropping off a PR for a new feature and saying, hey, here, maintain this forever. Right. That's given without taking. If I give Anna a take, I might say, hey, I'm going to give you this feature. I'm going to do a lot of work for you. And it's part of this reciprobleness. I want to trust that you will maintain this. And they say, absolutely. But I want to trust that you will be there with me to help me. Right. And you have that reciprocal notion and that drives and generates that. But the ego death of the author has

16:10 to happen first. If you can't shift from an individualistic United States from a perspective of it's my software. If you can't shift out of that mindset, you're never going to get to communal caretaking, which is the heart of sustainable ecosystems and sustainable communities. Makes sense. Alright. So now that you've covered the entire economy of open source, and let's cast aside the people that are doing it for the ego. Right? Because I'm not interested in in that kind of conversation. But we're in this world now where even if money isn't their motivation for why someone builds an open source project and then

16:52 potentially a company around it. It's always a motivation because we all have homes, we all have bills, we all have families and friends and activities and hobbies, etcetera. So money is always on a conversation, which means that at some point, someone does a really cool open source project. They then want to have trust, which you've covered, but money for both aspects of the sustainability there or at least two prongs of that sustainability model you kind of discussed already. Now for the money thing, they can do what most people do, and they go raise a VC round because they've got, you know,

17:29 32 GitHub stars and a few 100 users or whatever the requirement is these days, putting AI in the title. Again, I'll try not to be too flippant because, you know, there's some serious conversations and topics here. So they raised their money and now they've got that. They've got their runway. They've got their open source project. They're happy as MIT licensed, but they don't have trust. And a lot of ways companies go for trust is the foundation model. And I think what we're seeing in recent years, again, I won't go into specific examples, is that they're maybe not the best of

17:57 friends having your open source project be part of a foundation and having VC funding, but it is very, very prominent. And I'm curious to understand your thoughts on whether, you know, is this the right model? Is there a better model? Like, let's understand how how can we fix this in a way that it's sustainable across all motivations without leading to burnout or without leading to rug pulls and without leading to well, I don't really care about the VC. It's very but, you know, someone's gotta make money to pay my bills or their bills, etcetera. So

18:29 I know there's a couple of questions in there, but I definitely would love to hear your thoughts. So that one is a fun topic to dive into. I would say that going back to the fundamentals and the basics, that notion of reciprocity, that reciprocal behavior has to be the underlying foundation of how you build an ecosystem that is resistant and resilient in the face of multiple people interacting with it, and multiple people behaving with it and consuming or taking so on. When you look at a VC funding model, one of the problems with it is that

19:11 there's no notion of this reciprocal nature. The VC funding model injects an artificial amount of money into a situation in order to create a flywheel effect. And sort of that the notion of a flywheel is that you have this cumulative exponential growth of a product or growth of a solution, of a brand, then that becomes an organic capture of the market. And sort of VC idea is, if you artificially grow the flywheel really, really big, very fast, and then you roll it down the hill, then that momentum kick starts and you can shave off, you

19:49 know, the first fifteen years of the normal organic flywheel effect. And it works sometimes. And the reason why it's only cannabis sometimes is because it's inherently about market capture, and capturing the value of an ecosystem, which is inherently unsustainable. And so if it works in a situation, typically that situation is one where there was no existing ecosystem to integrate with. There is no other market to capture and you're able to fill the space of the market very quickly. So a good example of VC's SaaS in that regard would be something like Uber or Lyft, where you have a

20:34 existing model of taxis, but you didn't have a rideshare style application thing. And so they're able to find a new market and artificially expand into it twenty years ahead of schedule. There's no way they could have done it without that massive amount of inflation, but they needed a large amount of momentum for it to work. So the VC money fits just a bootstrapping problem. But for something like most open source projects, there's an existing ecosystem. There are existing products. There are existing open source projects. There are things that already happen, things that already exist, And typically you're not

21:11 needed to solve a bootstrapping effect. So what ends up happening is people take the VC money, and then the funding works. If you have this exponential growth, what ends up meaning is you build this trust of the community and you say, hey, we're not going to screw you over. And the only way to pay the bills is to get that $1,000 revenue. And the only way that happens is if every single market might capture or person using a product converts into a high paying customer. It does not work economically otherwise. And so you end up with the inevitable

21:46 rug pull because they had to make the finances work. The only other option is to get acquired by another company for an average sum of money. And then they will do the same thing, but with less of a dramatic rep pool because they can spread and amortize the finances out. The VC people won't, But it's the same rep pool. And it's not. I don't like to think of it as a rep pool because it's them operating under an economic model that's incompatible with how open source culturally views itself. That's really all that's happening. And it's the conflict between those communities

22:21 and those economies that causes the cultural clash. It's not a rough pool when you expect it. But people come in not expecting the rough pool and they feel personally betrayed. But that's because they assume that open source communities are there for the taking for unlimited consumption. And they can just take and take and take and grab and grab and grab and use and consume npm install everything, just use everything. And that doesn't work. The VC fits into that expectation for the first five years or so. So it's a natural fit for adoption. In terms of

23:03 one of the other mistakes that people make when VC funding or projects in general when they're looking for financing is the foundation model and the MIT license or permissive licenses in general. The reason for that is because both of those, that foundation model does not make your project resistant to certain types of economic and political and corporate capture. MIT license and permissive licensees also make it easier for those types of capture to happen and don't protect against it. So if you look at a shared resource, and you think of the project as a shared resource in a larger ecosystem

23:45 of shared resources, if everybody consumes it, then you know, cannot sustain itself. It runs out of any energy that it had to keep itself going and then it dies. It's like if everybody picks all the fruit off of a tree to the point where the tree is no longer going reproduce because all of the fruit that was breeding the seeds got taken away. Eventually the orchard will die. And you see the same thing with open source projects that have these permissive licensees for these foundation models that are building things. They make it very easy for certain types

24:23 of value capture to happen. Because they're not playing in the same model and mental understanding of like the culture values, the economic values, the governance values and everything else. If you're inside the open source sphere, the cultural values of open source, the cultural values of how the communities work, how things work, works, it all works. If you can ignore the real world economy for twenty years, it all works out great. The problem is, previously you could. But now, even if you decide to try and ignore the real world economy, the real world economy, the other companies out there, the other governments

25:10 out there, the other organizations out there will find your project, and will use it and will consume it and will operate with it. And you don't get to build a sustainable ecosystem before it gets essentially looted for spare change. And this looting takes all the sustainability mechanisms out of the project. And that's what a lot of people run into. And so if they're looking for how do I make a VC funded thing sustainable? That's a very different question. And that one typically comes down to how do you take an unnatural and unrealistic expectation of value delivery

25:49 and set the expectations for the community before the community gets, you know, or feels betrayed by you. For open source projects in general, what you're looking for is understanding that they exist in a market, or that they exist in economy, and they don't get to pick the economy or the market or the governance, they exist in the world. And so there's multiple players, multiple other economies, multiple competing understandings of everything. And if they want to be resistant, or resilient to certain types of value capture, or to certain types of draining of the life of that community,

26:34 then they need to build that resilience and that immune system into the fabric of the project itself. Interesting. I mean, David, you started down this path. Do you have any more? I could ask. I could ask more too. But I'll let you go first. I mean, I'm tempted to take a bit of a segue. I mean, honestly, you've covered everything I would even want to consider asking. Now I feel like, you know, as far as the economy, the VC funding aspect of it. I mean, I don't have anything else. I've learned a ton just from listening to you

27:05 over the last twenty minutes. You know? But as we said at the start, there's many things we could talk about with regards to open source and and your skill set. And I wanna push the VC state away now and, like, talk about just your I know an open source maintainer who has a project that's seen exponential growth. And, you know, I know you like to talk about leadership within these communities and fostering the communities and such, but I'm curious. Like, when I've got a project that's being used by a 100,000 people, millions of downloads, I've got hundreds, if not thousands of contributors,

27:42 You know, what is the how do you keep these projects safe from toxic behavior, from corruption, from burnout, you know, sustainable from all the other aspects that we haven't really covered so far? I mean, you've touched on some of them, right? But, you know, the successful projects that on the outside as a a consumer setting here, MPM install and or, you know, using Pac Man or whatever, right? You don't really think about it. But behind the scenes, there is a lot of activity. There's a lot of momentum. There's a lot of changes. There's a lot

28:13 of security risk from bringing on new maintainers and contributors. Like, you know, what advice do you have for the people that and that I mean, it doesn't have to be hundreds of thousands of millions of downloads. Right? Even tens of thousands of downloads. It's a successful source project. So what advice do you have for these people? Like, just to get more sleep and not have to worry about a lot of the potential bad cases. And I know that's a big question, but, I mean, I don't have any doubts you won't be able to give some great tips

28:37 and advice for people. So when it comes to things like this for a project, you can break it into, I think, the value capture resilience for that. And then you can break it into the governance side of the project and how do you keep the governance in the community sustainable. And then there's sort of the project overhead and the organization of the project, like the security risk or burnout of people and things like that. And so if you break into those sorts of things, you can approach it from a couple of different angles. For capture,

29:14 you need to understand what types of capture you're looking to be resilient at and how do you structure the governance of the project, the legal structure of the project and other things of that nature to make the capture harder. Andrew Lilly Baker actually works a meter and has a really fantastic article on governance and open source and ways to think about this and approach it and some strategies you're trying to defend it. I'm forgetting the name of the article, but I it's on the Internet. Works. People can find it. That works. There is another article that will be coming

29:58 out soonest at some point that we'll go into more detail that I'm looking forward to. And I've read Simone as well and have a little talk on that. But when it comes to governance for the community and the health of the community, the health of the community and the health of individuals is at the same time, the same thing, but also kind of not. So for the health of the community, I really, really look into Eleanor Ostrom's self organizing principles of like healthy and long term communities. Because at that point, the community itself is working on a project and the collective energy

30:36 of the humans is the resource that you need to make sure you don't over exhaust. And so she has eight principles of healthy sustaining communities. And if you look at these principles, they're actually very lovely. So one of them is user boundaries. Do you have a clear boundary between a legitimate user and a non legitimate user or a non user? Do you have a resource boundary? A clear set of boundaries define what is in the resource of the system and what is not in the resource of the system. So for an open source project, that would

31:10 be who are the committers, who are not the committers, who are the people that can make requests, who can't make requests, code of conduct. Do you have an understanding of how much time people have, how much money the project has? And can you separate that and make sure that you can understand it? Do you have a congruent environment where the actual setup of how the open source project runs matches the larger environment. If it's trying to be a foundation, does it look like a foundation? If it's trying to be a little hobby side project, is it clear that it's a hobby side

31:51 project? Or is it trying to set up all these weird things and then go, oh, but we don't have to secure about the legal setup. And then I go, well, if you don't care about the legal setup, then why do you have legal covenants? Or for example, the MIT license means anybody can use a project, including people using a project that may make it a target for, you know, state actors and state violence. So for example, as the utility package was maintained by some random person, and they became a target of a three year attack by a nation state

32:32 in order to gain a vulnerability to the system because their packets just ended up in basically every district on the planet because it was used by SSH. If you don't want to be woken up someday at three in the morning by a nation state doctor, you should make sure your project is very clear. Do not ever use this in anything important. And then people won't. Before, we could pretend that we didn't need to do that. But now we do need to do that. By going back into some of these other principles, I think one of the

33:02 most important ones is proper translation mechanisms and also collective choice arrangements. So there's others in there as well. But for the collective choice arrangements, that one is can people and groups, subgroups of people within the project make their own rules? Can the project self organize? Can the project say, you know what? This is how we've done it, but we shouldn't be doing it right here. Right now, in this way, should change thrones in the game. We should change thrones in a project. We should change the values of the project, or we should change the shape of the project. Different

33:39 groups of users can't do that without needing full consensus and buy in from the entire project. It won't be so sustainable. And you can look at that very clearly when you see like Kubernetes as an example. How many people in Kubernetes agree with everything about the project? How many sub projects of Kubernetes have started when the subprojects operate differently than other subprojects. That's not, you know, undesirable. That's actually desirable. That is a sign that the Kubernetes project has figured out a self organizing structure. And the culture conflict resolution mechanisms are probably the most important part. So that one is how do you

34:17 surface conflict? How do you recognize it? How do you understand it? And then how do you solve it? If you don't know how to solve it and you're just going to figure it out, you're going to do it wrong. Something's going to happen. And this is where a huge amount of drama in the open source open source community comes from. People say, I don't need to worry about this. I don't need to think about this. Emotions are emotions are for other people. And then they throw a hissy spin or they absolutely legit or they drag on for

34:45 pages and pages on piling disagreements and the whole budget bridge part. And none of that needed to happen. You need conflict resolution agreements. You need to understand them deeply and you need to put them into the fabric of the project itself. Going back into the personal element, the individual element, keeping project safe from burnout and security risk. So for burnout, one of the things that I think is interesting there is burnout comes typically from when people are investing into a project with the expectation that they're going to get something out of it and then they don't. If you're over

35:20 investing with the expectation that you get something back and then you don't get something back, you're gaslighting yourself. And then you're just overworking yourself with expectations that nobody promised. And that's where the reciprocacity comes from, which I won't learn how to pronounce that one date. But that's where that comes from in the trust. Right. And so if you're putting something in and you're not getting something out, you need to know that. And you need be clear and upfront with what you want out of it. And if you're not getting nothing out of it, you need to change something until you are. Or

35:58 you need to change your approach to it and your expectations. A lot of people burn themselves out because they go, I want this to be the best project for this. And I go, okay, that's like two million human hours worth of work. Where are you going to get that? And they go, well, people are just going to buy it. I'm like, nobody's going to buy it. Yeah. Well, what if they don't? You haven't said anywhere that you want people to buy it. You haven't said anywhere that you need that to happen. You haven't said anywhere what your needs are.

36:33 And you're just burning away, burning your entire life force down to the ground for something that you want, that you are not even naming and articulating. So of course, the burnout. You need to articulate your needs and desires and need to understand them and make sure that the project is harmonious with them. Otherwise, they're going to end up as looking like an irrational, you know, benevolent dictator for life who is sort of being wishy washy with the project. And they're looking for those unmet needs that are unarticulated and then they get burned out. And so

37:07 you really need to understand that about yourself. And as for a security risk from the individual perspective, that one is pretty interesting. So it turns out security risks don't exist for the individual or for the project. They exist for the consumers of the project. The project itself has no notion of a security risk. The people using the project, the companies using the project, people consuming it have that notion of a security risk. And by that, you know, reciprocal sort of give and take notion, it means the project should reflect them trusting the project and addressing the security

37:44 risk. But the project does not actually inherently have the notion of a security risk. So when maintainers come in, let them. And the people using the project have a problem with that. That they need to be involved in the project and contributing to the project and sustaining it sufficiently to where they're able to get their needs met in a way that everything is harmonious. So as a very concrete example, actually, as a less concrete example, I was going go too spicy. As a less concrete example, if you have a project that has a core set of maintainers

38:23 that live in one country with economic sanctions, That might mean that that project cannot be used by certain large companies or certain large corporations or certain governments. Is that a problem? Not for the project. Is that a security risk? Not as far as the project is concerned. Is that a security risk for the company using it or the enterprise using it? Absolutely. What are they gonna do about it? Typically, they go into the project, they open up an issue, they say, blah blah blah blah, do a bunch of work about snake spy. And they hit, you know, open issue.

38:55 And then the project maintainer says, no. So that kind of situation is unproductive for everybody. The maintainer is not going to win. They're going to look like an asshole. The, you know, corporations not going to win. They're going to look like, you know, a greedy resource stealing, you know, communities trying to take advantage of the community. Nobody wins. But if people say, hey, why don't we hate this economic sanction concern? And if someone says this is a concern for me, how do we build this type of trust? If they all work together collectively, you can manage things and set things up

39:30 in a way where that happens. One possible solution might be that you have multiple groups of maintainers in the project, each from different economic or political areas. And if someone submits a patch, someone from a different political region needs to approve it. That could be one possible solution. But no one is going to get to that solution if they all just start rage spading each other on issues on the Internet and saying, you should just do all this work for me for nothing because I want you to. Because security risks don't really exist until they

40:04 do, but they only really, really exist with people consuming them. So if you don't have that notion of reciprocal behavior of that trust that extends beyond the boundaries of the in group, it's just not going to work. In which case, put upon it, if they don't care about that, feel free to drop it. State it very clearly. Make your expectations very plain, and then sleep at night knowing if anybody cares, it's their problem. Not yours. I have one more question. Now I think we've been very careful not to use any concrete conversations so far, even if some people can work

40:42 out some of the situations. But there's something very topical right now, and I definitely love your take on it. And that is, obviously, there's the DOJ case against Google being a monopoly with search and Chrome. And, you know, the answer seems to be, well, they have to get rid of Chrome because it drives a monopoly on search and advertising. But I'm looking at this. I mean, that's a Firefox user too, which is why I can sit here and see whatever I want. Right? But I'm not sure any company in the world can successfully take on the burden of Chrome

41:12 without having their motivations not being too dissimilar from Google. As much as I would love to see Firefox have more money and more attention, but at the same time, Google are also the 90% of Mozilla's revenue, which is actually keeping the lights on at Firefox right now. So this one's an interesting one. I think to take a step back, looking at operating systems is actually kind of an interesting one. So if we look at operating systems, we have Linux as an operating system, and then you have miscellaneous. And that is a huge historical fluke. But it has turned out to be a

41:56 very advantageous one because the Linux Foundation for Linux has ended up being the closest thing we've ever had in open source to a international public utility that is maintained by something approaching the political neutrality of the United Nations. Sidestepping entirely from the fact that the United Nations is not politically neutral. But so you have that kind of situation that Linux has ended up in and that has prevented, you know, Windows and macOS and Android and iOS and other different operating systems from being in the same type of position of being able to have a monopoly effect on

42:39 the market and then using it to outwardly influence and outwardly shape the trajectory of how people interact with it. But then you might argue that there's a lot of telemetry in modern operating systems. And so is this telemetry sort of issue? It is not an issue. And I think ironically, it would be more of an issue if browsers had not become the true operating system that most people use. So if you think of a computer that you use and how you interface with the computer, you turn it on, you open up your web browser and maybe

43:17 you have your other applications that you download, which are web browsers in a different box. And that application runs in that web browser, but it's called something else. So 90% of people, 90% of the time, basically just use a web browser. That doesn't mean it's not. It's true though. It's probably not When you run into that, when you run into that situation, I think a lot of the reason why operating systems have avoided this need to split and these antitrust things is because of the web browser. And even when Microsoft got these huge lawsuits levied against them in the nineties and the

43:57 early thousands, it was on Internet Explorer. Was how they baked the operating system and the web browser together. It wasn't necessarily the operating system. It was the combination. And so for Chrome, it's now the de facto operating system for the world. And that is where I think most of the anti trust the issues stem from. So if I think of the shape of the problem or the shape of the solution that might sufficiently address this, I do agree with David. I don't think a single company can ever actually host Chrome and keep Chrome open and funded and

44:43 do things of that nature. What I think would actually end up needing to happen is I don't know if the Linux Foundation can hold Chrome, but something in that shape. You would need an international, global, neutral party to hold on to Chrome and Mozilla. RQP Safari two and essentially any operating system or any browser in the future, probably any operating system, but any browser. And essentially what we will need to do as a human nation, as a human species, is invent and formalize the notion of a public good. We've been able to, by and large,

45:31 make public goods a thing informally by having a very diversified and disaggregated supply chain. When we invented steel or when we invented certain types of materials and raw resources and computer chips and all these other fun things, They're enormously expensive, but everybody can manufacture them. And so we're able to split that up, aggregate it, separate it out and make it to where people can still innovate their silhouette market. But web browsers. Web browsers are one of the few things that now we've decided due to how complex they are, how deeply integrated they are to how we

46:10 live our life. We access our banks through them. We access our email through them. We access our jobs. You can't apply to a job without a web manager anymore. You can't apply to government funding. You can't apply to government benefits. You can't interoperate with your local governance or your local, how you get any thing that you need for modern life without a web browser. Which means to me that the web browser needs to be this public good utility. And due to the scale and the size of it, the public good utility is not something that every nation could independently recreate.

46:49 And so therefore it needs to be an international public good utility. It needs to be something that we collectively as a species to say, yeah, we need one of these and nobody should be in charge of it, but everybody should be in charge of it. And we need to scale that collective ownership up to humanity. Well, you so much for joining us. I think everyone really enjoyed the conversation and hopefully we'll maybe, who knows, maybe we'll get to do this again some other time in the future, but we really appreciate you That'd joining great. I'll keep my answers choice so we

47:20 can actually have a conversation too. That's perfectly fine. Thanks for joining us. If you want to keep up with us, consider subscribing to the podcast on your favorite podcasting app or even go to cloudnativecompass.fm. And if you want us to talk with someone specific or cover a specific topic, reach out to us on any social media platform. Until next time when Exploring the Cloud Native Landscape on three. One, two, three. Don't forget your Don't forget your compass.