oh,

Alright. Thank you for the intro. Let me see if I can get this Zoom thing working. Alright. How does that look? I can't see you, so an audible thumbs up, Seohyun?

Excellent. Alright. Hello, Medigov. I'm Kelly Champion, PhD candidate at the University of Washington, Department of Communication, sort of pre proposal phase, getting there. Benjamin Mako Hill is my advisor, and thanks so much for the invitation to present here. Many of your names are familiar to me through your work, so I'm just super honored to be here. What I wanna do today is offer you two governance challenges that have come up through some different angles of approach I've been taking, doing empirical work in the realm of information public goods, including work done by some colleagues. And what I hope to do is kinda give you that full overview, maybe fifteen minutes, and then open up to reflections and discussion. Alright. So public goods in a kinda classic two by two formulation here from Elinor Ostrom, nonexcludable, nonrivalrous goods like security, the environment, public health, and infrastructure. Information public goods, if we kinda turn our attention there, I'm particularly concerned about those that have come to act as infrastructure in our society. So those in thing include things like Wikipedia as a knowledge base, and software like GNU Linux. And Wikipedia and, Ganoo Linux were both created through commons based pure production, an innovative process developed by production communities as Yohai Binkler observed, kinda characterized by decentralization, a variety of governance models, diverse motivations from participants, and kind of orienting their interactions around creating a a commons. And I mentioned the concept of infrastructure. Yeah. I laid out here some expectations that we might have of infrastructure, serving needs, available for use, reliable, maybe invisible. And I would argue that Wikipedia and Linux play this role. They're an information public good in the form of digital infrastructure. So what happens when pure production meets infrastructure, peer production of infrastructure? What we observe in practice is that is a combination of these two bundles of ideas. Peer production is a powerful way to produce infrastructure, but there's some disconnect between these two bundles. And one such disconnect falls under the category of decision making and governance broadly defined. And the on the ground reality of these projects is that although they incorporate some, like, kind of government sponsored effort, or they may have kinda internal governing councils, they're built by a mix of devoted volunteers, firms, people passing by, entrepreneurs, and their governance is generally not subject to the public in general. This picture takes a moment to load, but it'll load. It's a rough analogy to be sure, but imagine, if you will, that every morning, all across the world, every road construction worker wakes up and decides whether they feel like building or repairing or tearing up the road with what tools, whether they'll cooperate with some kind of shared design, or if they'll fight and so on. In physical space, that sounds like total chaos. But in cyberspace, totally normal. That's just Wednesday. And yet despite that, it seems to work. We have incredible technologies to communicate, transact, and learn about the world. So through the hard work of volunteers, self assigning tasks, self organizing, these communities have unlocked an incredible amount of creativity and energy in their participants, so much so that these information public goods have become essential to modern life, but there are some gaps between how these goods get made and how these goods get used. And I wanna focus on just a few pieces of this overall map that I've sketched out here in red and blue, exploring what happens when pure production creates information public goods that become infrastructure. And given this map, you might ask any number of questions about how this left side kind of relates to this right side, but I'm just gonna focus on a couple of spots. On the left side, this work is kinda oriented to two aspects of peer production. On the sort of governance model side, the openness of the organization, reliance on process, not individuals. This refers to what sometimes gets called meritocracy or duocracy, where participation, though, is being judged on merits rather than, say, the identity of the contributor or so we would hope. And from the kind of diverse motivations zone here, I wanna focus on self selection of tasks. On the right side, two aspects of infrastructure, serving public needs and reliability. Alright. So in purple here, I've kinda dropped in some typical governance questions that are implicated as we take up some of these different pairs, who's involved, what gets made, who is served, how are decisions being made. Just a little bit more framing on the information public good side. There's two interesting qualities of information public goods that not all public goods have, and I'm pulling from Fulk et al here. So they're connective in that they materially connect people and actually increase in value when more people are connected to them. Therefore, leaving people out diminishes the value of the good, represented here in my little photo collage is kind of networks. Information public goods are also communal, so they're built through participation, exchange. The benefit for participating is, in some ways, indirect. So what you get out is not what you put in. What you get out is what someone else put in, and, therefore, there's some kind of uncertainty about motivations, benefits, risks, reliability. I've added in the kind of communal dimension here with kind humble potluck as well as a rowing team. Alright. So that's my framing information public goods produced through peer production, serving as infrastructure, connective, communal, nonrivalrous, nonexcludable. Alright. So that's a framing overall, and here we are. We're gonna I mentioned two angles of approach I've been using and that this effort has some implications for folks thinking about online governance, and that's where I'm gonna go next. So one line of work is with respect to the value of anonymity. Online environments have some powerful affordances to support privacy and surveillance both, together with colleagues at Drexel and NYU. We've been taking this kind of value of anonymity angle on information public goods, and our work has revealed a couple of interesting observations. Certainly, minoritized and vulnerable individuals use privacy tools to protect themselves and engage online. But for some folks, being less identifiable is a vital way to protect themselves so they can simply live their lives, and for others, privacy is a personal choice. Less identifiable folks need not be people taking strong intentional measures to hide their identity. They might be new or very casual or in whatever way less engaged or less forthcoming with information. In general, we find that people using stronger forms of anonymity online participate in ways that are comparable to newcomers and casual participants. However, we also find some evidence for unique value that anonymity seekers bring, particularly with respect to engaging with marginalized or taboo topics, engaging in activism, and critique of the status quo. Service providers, platforms, communities, etcetera, often focus on avoiding negative interactions, and the needs and interests of the anonymity seekers are often not articulated in governance discussions. The sort of long tail characterizes online communities in many ways, but that's not where governance generally lives. Community governance often lives in the hands of the top contributors and the highly identifiable. I have some references here, and I'm sure folks can just kind of pull that off of the slides later. There's no need to kind of peer at the eye chart part. So, the problem statement overall, anonymity seekers are valuable, yet anonymity seems to always be under attack from surveillance capitalism, from government regulation, from the march of technology to identify people, and from within communities seeking to protect themselves from bad actors. So I argue that it's vital that we understand what is lost when we push for greater identifiability, that we seek solutions and approaches that respect anonymity as itself a public good. So I have kind of an overall question here. How can communities make decisions that attend to the needs of anonymity seekers? But just to make it a little bit more detailed, I wanna add back in a couple details from the framing that I sketched out. Let's consider that these are information public goods. So, excluding people harms everyone. The target of the empirical work has been articulating the value and experiences of anonymity seekers, but how might we do so even if their value is not quantifiable? As Ty Nguyen expressed in this forum previously, quantification can drive conversations in ways that ultimately run counter to our values, and the best response may not be better quantification, but rather to accept that justice may challenge us to embrace even those populations whose value we cannot quantify. So I hope that gives folks, something to mull over, but as I mentioned, I have two angles to talk about. The other might sound really different, but the relationship, I think, will be clear by the end. So, let's talk about maintenance. Second angle on challenges posed by information public goods, digital infrastructure, and how to sustain it. So this line of work has been conducted together with colleagues as well as with marvelous support from development communities themselves, And my work here is built on a basic expectation of infrastructure. It seems very reasonable to expect that the most important pieces of infrastructure will also be the highest quality. We hope that the bridges that carry the most traffic will also be the strongest and that they'll be regularly inspected and so on. So here's a model of that expectation. We have quality along the y axis and importance along the x. And in the upper left, where quality is high and importance is low, we've labeled that overproduction. Maybe it's wasted effort. In the lower right here, importance is high, but quality is low. And we've labeled that over we've labeled that underproduction, because that's an area of of risk for communities, where we'd like to see the world, perhaps, is lined up through the middle, given kind of scarce resources. Let's all be proportionate in how we allocate them, so that high importance and high quality go together. But what I found in testing this expectation, highest quality for the most important components against a body of digital infrastructure is that it is violated to a very worrying extent. The project that I did here, was focused on Debian Linux, which is the backbone of the web and the cloud. And of the about 22,000 components that comprise Debian, I found more than 4,000 that violate this standard. About one in six components were strikingly low quality given their relatively high importance, which means that they are underproduced. Low quality, high importance packages. This is a source of risk to our shared digital infrastructure. This is a heat map of those packages. You can see the problem area here, highly important, low quality packages. But this same type of analysis could be applied to any information public good. I was inspired here by work from Morton Wernicke Wong on Wikipedia, where he and his colleagues found that such topics as mental health are underproduced. Again, top line result is that we see substantial cause for concern in terms of risk to digital infrastructure. And in the conceptual map slide, I kind of emphasize self selection of tasks. It's not quite as bad as the construction chaos photo, but, again, we see a peer production process, volunteers doing their best, corporations pursuing self interest, government may be oriented to security, scientific productivity, NGOs trying to find and fill those gaps. There's no central planning office or shared decision making mechanisms for importance, although the Linux Foundation is kinda seeking to build some consensus there. So how is quality measured? There is a movement called evidence driven software engineering, but it turns out it's far from reaching any consensus about how to measure quality in the first place despite two decades of work at least. And those measures that are in use, such as in analytical tools and metrics platforms are often not validated empirically or give contradictory results. And for this finding here, I conducted a a tertiary literature review of software quality measurement studies. That's currently under review, but you can pick it up on the archive. Alright. So, my target in future work is to identify how information public goods come to be neglected and how we can mitigate and prevent neglect. But the open question from a Medigap perspective is how can online production communities maintain digital infrastructure in ways that better engage with the needs of the public? And, as before, I'm gonna make the picture just a little bit worse by adding in some more of the framing from before. Information public goods are communal. There's this beautiful complex social process. Creative freedom has really helped these projects to grow and flourish. So how might we engage with the needs of the public without threatening the kind of self determination of creators that enabled these goods to be produced in the first place? So in conclusion, information public goods pose vital governance challenges with respect to what gets created, for whom, and by whom. And although I described two really different angles on information public goods, one oriented to anonymity seeking, the other oriented to digital infrastructure. I think that there's a kind of underlying question here that stretches between the two cases. How can online production communities engage with a public good? Oops. Not that. Alright. Thank you so much for your attention. I'm really eager for questions and discussion about these kinda open questions that I posed, or with respect to the empirical findings. I know I flipped through things really quickly. It's like four years work and fifteen minutes. So thank you so much for your attention. And this is me.

Alright. Let me get the chat going here, and, yeah, I can kinda reshare things.

So that's interesting. I think that the framing of this in kind of terms of networks dates back a little bit before network science discussion was quite as, like, focused as what you articulate. But you think about something like a phone network, there's value in everyone having a phone and being callable even if you never call them. So there's value in the edges, but there's also value in the nodes. There's a there's value in letters being delivered to everyone's home even if people certain people rarely get letters.

Great. Yeah. That's a great observation. Alright. I see Parker asking about anonymity and privacy. So I didn't dig as deeply into kind of the con the concepts there. I think that privacy refers to a multiple states that people can be in. They can be in a private state even when they're with someone else. There's different kinds of privacy or privacy states. On the other hand, anonymity refers, I think, to a certain state of identifiability in a given context. So there's many dimensions of identifiability, and the sort of diminishing of any of those dimensions does make someone sort of less identifiable. But I think of it more as a continuum than a binary here. I don't know if that's helpful, except to say that, some of the framing that we pull here is from Marx, and that the multiple dimensions of identifiability are really significant online when you think about, if you speak of someone as anonymous because they're identified only by their IP address. Sadly, I would like to inform you that your IP address does not typically make you anonymous. But in some communities, referring to someone as their IP is makes them a non, Wikipedia, for example. On the other hand, you could give your real name and still be quite unidentifiable if there are many John Smiths in the world. Elizabeth asks, are there different online governance cultures that are more friendly to anonymity seekers? So, here, I would say that, in some environments, anonymity seekers built that community, and they're extremely friendly. And anonymity is baked in from kind of the it's in the bones of the community itself. In other places, especially as a shared sort of store of value accumulates and is sometimes under attack either by hackers or crackers or vandals or, you know, misinformation people, misinformation like bots and agents, People can start to say, hey. We wanna know who these folks are, who are tampering with our software supply chain or who are, shaping the articles that we write and that we put out there for the world. So I think that, definitely, cultures differ, and we you might find also, like, when people are seeking psychological support or social support, their, anonymity seeking, is sort of a, also, like, baked into the the culture of the community from the very beginning. Let's see. Saffron comments on crypto communities. Yes. Definitely. Elizabeth is sort of throwing things in here. I'm sorry. I didn't follow the chat as I was speaking because I have to do one.

No. That was just in case I could thank you for making your comments. That's just courtesy.

But I appreciate that.

Oh, so so, Tianna, you you were asking a desire to be brought into the fold of community governance decisions or they take it as a result of their anonymity and not care. So, I think that especially when governance decisions affect them, there's absolutely some advocacy, some protests, some pushback from anonymity seekers at their exclusion. But, also, there's a I think that, you know, folks understand that there's sort of maybe some kind of limit. But, in general, if you're seeking anonymity for human rights purposes, for example, you might indeed want to be quite engaged and wanna be a deep participant. You just simply can't disclose things in a way that that community desires or expects. So, absolutely, I think that that folks wanna be brought into the fold. There's many, I'm sure, who don't, but then again, that's the case with any community. And I I think in general, our work finds so many places where anonymity seekers are so similar to so many other kinds of users, this idea of treating them as in a sort of exotic, strange, bad actors. You know, any of these, like, kind of ways they get characterized turn out to just be not sustained by the data. It may be sustained in our feelings about them, but it's not sustained in the data that we see. Alright. Kinda scanning through here.

Sure. Should I rephrase?

Well, you you mentioned the well, first of all, thank you. And I really liked your talk, and I appreciated the visuals that helped see your points quickly and clearly. The the heat map felt as I tried to reason about what would it feel like to be in a community that contributes that way, I found myself wondering if in fact that contribution pattern is natural and even desirable. Like, I I I I was wondering how you feel about pushback to the story that there's a problem here. What about the possibility that discerning what's important comes first? And then once people have learned to see what they want to have improved in the community, they begin to climb the the quality hierarchy of contributions, and they make their way into that other cluster in the heat map of high quality, high importance.

So I can share that back up just real quick here. Yeah. So this refers in particular to software packages. So this is not just contribution quality, which is sort of a separate line of analysis, but actually package quality within Debian itself. So the situation here is not just a matter of, like, finding bugs that are good for newcomers, but rather patterns of systemic neglect of certain packages. The same with Wikipedia, patterns of systemic neglect of certain topics, articles, etcetera. There's definitely opportunities for people to say, oh, well, this is really highly needed by the community. Let me jump in there and do that. There are many mechanisms in Wikipedia or in in source forges that people use to try to direct attention, but naturally sort of expecting people to, on their own, find the most important things and find the most neglected pieces does not seem to happen kind of spontaneously. And there might be really good reasons why these items, are low quality. They might be, packages that are simply very hard to maintain where a high level of skill is needed. They might be ugly and painful and difficult and problematic in various ways. Or with respect to articles, it may simply be that high quality information is not readily available, or the kind that's available is not in line with what Wikipedia say expects from people when they contribute to that topic. So I think that there's it it may be that this is a natural behavior of these systems, but my guess is that in terms of a kind of broad public good kind of perspective, in terms of good of the public, it's probably not a desired behavior in most cases, at least when the the system is relatively mature. Early on, sure, people might, you know, be pretty excited to find neglected corners and jump right in there. But as a a system matures in particular, I think that these are these neglected areas become real causes for concern.

Yeah. That clarification was very helpful. I I see what you were illustrating better now. Thank you.

Thank you for the question. Alright. And some water.

Well, corporations are often heavily engaged in pure production. That's what, like, most of the web and cloud is produced on. So they're also engaged in this process, but I I take your point that in house, there may be a little bit of a different picture going. That that said, if you talk to the system administrator of and I only have kind of anecdotal evidence. I have not analyzed a commercial operating system. But I would say that if you talk to any system administrator or any IT department anywhere about neglected corners, about the dirty things they don't wanna talk about, they will say, oh, yeah. Let me tell you about this one server. Everything relies on it. It runs our licensing. It runs our timing. You know, it runs this. It runs this. It runs that. Don't touch it. Never maintain it. Don't reboot it. The guy that set it up left ten years ago. When it crashes, we're all here for the weekend. You know, everyone has those of neglected corners that often become point pain points because they're not maintained. And we see in some of the vulnerabilities that have emerged in software that these these neglected components come back to bite us again and again. So I think that, neglect of key components is probably, far beyond pair production, and extends to the corporate world as well, but it's true that the analysis is really scoped just to Debian in in this case. Oh, and then Mako says he has an answer, so maybe, Mako probably has a different answer.

Well, I mean, this is a much more, like it's just a direct sort of personal experience. So I so, so full disclosure, I'm so I I've worked particularly on that paper, so I'm in so I know a little bit about the that one. But I also I think more relevant to this point is that I, before becoming an academic, helped start a company which was building an operating system built on Debian. It was Ubuntu.

tell you what we did then, which is that we literally made a list of packages that we thought were important, and we and we paid people to work on them. So we just we we used money, in this case, resources from some eccentric South African billionaire, to, like, you know, pay attention to the things that we cared about. So we just divided Debit into two pieces, and we allocated resources and attention towards the stuff that we thought were important. Now to what extent are the things that we think are important, are those the things that are underproduced in this analysis? We could look I mean, we could look at this, and I don't I don't know. Like, I don't think we have. We did pay a lot of people to work on things that are sorta towards the top of the list of underproduced packages in deviance, stuff like, you know, like, integrative sort of, like, key desktop components that are used by lots of people and are hard to maintain because they require in some sense, it's a different governance challenge. Like so, I mean, I don't know. The the least was Gnome Power Manager is, like, the worst one. Right, Kaylee?

That's true. In the in in the more detailed, gory detailed version of this talk, I highlight some of the neglected component. And Gnome Power Manager, the poor maintainer. That one's at the very top of my list of the least maintained. And and every time my laptop shuts down without warning me, I I shake my fist at Gnome Power Manager. But, you know, that is indeed the the worst and most neglected package in w.

A lot of the packages are kind of like can own power manager in the sense that they are these really kind of, like, complex sort of integrative things. So can own power manager is the you know, it's a it's your power manager applet. Right? And it's this, like, kind of like there's a there's a there's a set of specific governor challenge governance challenges related to modularity in the context of something like Debian because Gnome Power Manager involves, like, you know, you have to reach all the way down into the the kernel and the, like, the the the most sort of, like, fundamental aspects of the system, and you've got a desktop application running on the person's, like, you know, graphical user interface and translation and localization problems. You have, like, the full range of problems, and fixing problems in good empowerment manager often involve reaching into lots of different other parts of the distribution, which generally speaking are maintained by different people. So, I think that that, that in Ubuntu, we solve that problem by essentially getting rid of individual package ownership. We pay every these are the thousand packages that we're gonna take care of, and everyone has a 100% access to everyone. There's no name on anybody's package. And so there's, like, a different governance arrangement and a different sort of, like, funding arrangement, which allows people to address problems in a really different way.

think that, like, my sense is that's also what other organizations that were working in this space would do as well. But, I mean, I my my my knowledge is more limited to that to Ubuntu and, really, Ubuntu in, like, the first eighteen months. I left pretty early.

Yeah. I would be super interested to see what the results look like, with respect to Python. So we should talk if you are also super super interested in what a production analysis of Python might look like. My first suspicion is to think about, okay. So what about when Python libraries reach into kinda under maintained c libraries? And I'm speaking in part from my own, like, compilation hell from, like, trying to get Python modules installed that rely on out of date c libraries. But those even what seems like modularity or may seem like independence can ultimately come to kind of run into these under maintained components.

Sort of a an eat your vegetables before dessert kind of a kind of approach?

I have a feeling that most software devs would see right through that. But, it's true that that if you have a conversation around in in the community around, like, hey. We know this is unfun, but we need to do it, and here's how we're gonna altogether, as a group, kind of make it a little bit more fun for the rest of us. We're gonna do it at a hackathon at our next, you know, big meetup or what have you. You can gerrymander the community in in ways that attends to these types of neglect, instead of making it just a matter of, like, guilt and punishment. When I presented this work to back to the Debian community, most folks were excited, but some folks were like, oh, great. Someone else reminded me about something that I didn't do. So I think that shaping the community around kind of releasing that kind of neglect guilt and tackling it in ways that are positive, I think, would indeed be be really productive.

So I think that the kind of history of peer production definitely pushes toward that, like, notion of modularity and trying to make pieces, at least to some extent, independent. I also think that the ability to refactor, rework, throw away pieces without throwing other things away can be pretty powerful as well as kinda ease of documentation when things are turned over. So it seems like you're on a a good track there. Let's see if there's other kind of implications I can think of kind of vamping here. I would say having conversations about what's valued, about importance, about neglect in an overt way in terms of, like, surfacing those needs, making sure that that information is in front of people, and thinking about how the voice of the public, how the voice of usage can be articulated back into the community in in signals that folks will sort of attend to would also be really valuable. Something that I noticed in the Debian analysis, when we were analyzing the rate of bug fixing was that the the system for triaging bugs divides bugs into release critical and non release critical, and that's a sort of an emic signal that comes from that community and from their priorities. And I'll tell you that release critical bugs got fixed much more quickly than non release critical, and this was born out over a very long history. So the community is responding to its own signals of importance and prioritization, and I think building in the kinds of signals that you think make the most sense that folks can then orient their kind of cultural choices around, I think is also just kind of that this this work kinda speaks to that as well. And folks are putting you into relevant work. That's great. There's definitely some of that.

Types of information, public goods. Well, I think that there's definitely enough of an analogy to public goods as we've identified them in the sort of physical realm that you can think by analogy there as a basis for ontology. Certainly, Yochai Binkler's exploration of pure production is full of examples and typologies and so on. So that, I guess, would be, like, if someone at wanted to ask me to put a typology in a paper, that would be where I would reach, and I would look I would read through wealth of networks one more time and think about what categories things fall into. So that would, I think, be my my first go to. What do you think, Mako?

Sounds like a good answer to me.

Well, I mean, I think that there's a lot of different I mean, we were talking I mean, Kayla and I have been talking about this, even just in terms of thinking prepping for this talk, and I think that, you know, there's a range of kinds of information public goods that are not pure produced. Right? Like, I mean, we're talking about the, you know, food competition data, like like, the from The U USDA or whatever. Right? Like, important sort of, like, example of an information public goods, not pure produced. Right? Like, maybe involves many contributions from various places. Maybe we could think of pure produced way of ways of making it, but I think that, yeah, there's a there's a there's a huge range, and there's even, like I mean, I I mean, I think for me, it's like, let's let's let's try to enumerate dimensions upon which we might categorize them, not just the not just the way in which we would group them. So

Yeah. I I think that grappling with maintenance is a is a key part and an a neglected part of of creating a a project. I was reading a study that talked about how from a a corporate perspective, creation of a new software package or an app or what have you is maybe 20% of the cost, and that the remaining 80% of the cost is often in the maintenance and support. But that the emphasis, as always, kind of goes to the initial creation. Anybody who's been involved in budgeting around, say, a university, I think, you know, the capital cost of a building versus the ongoing maintenance cost of the building. It's easy to get funding for the capital building. It's very hard to get funding for the ongoing operations.

So sometimes, if something is badly maintained enough, peep a community will swell up around it and and decide to maintain it, and sometimes it will be allowed to die. I think that we perhaps don't always recognize when it's time to let something go. How do how do you kill off a digital a piece of digital infrastructure? How do you kill off it is very hard. How do you get rid of a digital or information public good? How do you quiesce those things? And how do you recognize when it's time? I think that we're not as good about, knowing when it's time. But the some of the work that I was doing about software quality based on public datasets, those public datasets were written by NASA in the seventies and eighties, and they're used for modern machine learning today for assessing how to write good quality code. Do you want the NASA engineers of the eighties telling you about how to write great quote code in twenty twenty one? Probably not. And yet, that's where the public datasets come from, that are used for for building some of these, some of these tools. So maybe it's time to let the the NASA datasets die.

I think that's a good question. I also think it's an open, like, it's an open area of research. The both the links that I sort of put in the chat are sort of about this in some sense. They're both involve analyses of examples of pieces of software that were released that were originally written in a proprietary form and then were released publicly afterwards.

think of, like, Mozilla or something which are of his Netscape demonstrations. I think that's, like, one of the examples. But they have a bunch of these things. There's some other work by Abhishek Nagaraj on seeding in the context of OpenStreetMap. So they look at tiger data, for example, and how that is released into OpenStreetMap. And the finding is pretty interesting. What is it's the generally speaking, the places that get the better tiger data end up with less active community contributions around them. People come in and they are engaged in maintenance in ways that cause them to, in the long term, to participate more. It's a pretty cool paper. I'll try to find that one and link that one in there too.

At Kaylee? So I think that, the success of peer production to date has been with respect to decentralization. But I do think that the the question is what do you centralize and what do you decentralize? And I think shared values, shared data, shared understandings of importance is much more powerful than, like, any kind of command and control. We've seen just a flourishing of creativity, when people were kinda united around some shared vision or at least a loosely shared vision around what they're creating. So I think that distributed, maintenance is absolutely possible, but the building of kinda shared understanding and shared prioritization is is critical to making the the maintenance then succeed in that mode, if that answers your question. Oh, there's a question in here too from Christina. Regenerative organization.

Yeah. I'm just, familiar with I'm an ecologist and I'm familiar with, organizations and approaches to teaming, teamwork, and organizational design that are from communities very much, not technology based, who are really leaning into and trying to apply in a in a very, you know, scientifically grounded kind of way, the principles of living systems design and making, health the metric by which they they look at that. I know that, like like you just said, what do you decentralize? What do you decentralize? Like, the structural approach is much more common in the software world, and I'm wondering if there's anybody doing interesting work on looking at indicators of community health in software.

There has been a lot of work on measuring what people take to be a metric of community health in terms of participation, engagement, diversity, inclusion, etcetera. So there's a lot of work on community health from that perspective, but it's typically oriented to, I guess, observed ideas of what we think a healthy community looks like rather than being outcome oriented in terms of if a community is healthy, then it will look like this. Do these things actually indicate health in that respect? So it it's folks saying, okay. We think that a really healthy community will have people who are using really cooperative language rather than contentious language, and we're gonna run a sentiment out analyzer against the the way that they're articulating in their commit messages or what have you. But then does that actually lead to better software, say? Does it lead to happier engineers? I think that the the pieces have not been kind of all plugged together there in terms of of how that analysis has been done. I'm sure many of those factors do matter. But what how do they matter and and what do they drive versus what do they not drive, I think is less clear. Alright.

I'll just