 This is the risks of single maintainer dependencies. Bear with me, still dealing with the jet lag, but in this talk we are gonna chat about the lottery factor, contributor communities, and the secure software supply chain. So one of the things I always ask myself whenever I show up to one of these talks is, okay, well, who the heck are you? And yes, I promise it is relevant for this talk. So my name is John McBride. I'm a senior software engineer at VMware, and I work on our open source Kubernetes platform, which is Tanzu Community Edition, along with a bunch of ancillary open source projects around that, Kubernetes, Kind, and one of those projects is SPF 13 Cobra. Now if you don't know what Cobra is, it's a CLI bootstrapping library for Go that gives you a bunch of really nice APIs for creating commands and a really modern CLI application. Tons of stuff uses it, all over the CNCF, all over Kubernetes. So just some quick statistics here on Cobra itself. It has over 26,000 stars on GitHub. It has over 900 commits. And again, it is a key dependency in the CNCF Kubernetes ecosystem. Just to touch on a few projects that use it, Kubernetes itself, CubeCuttle, Helm, Tanzu at VMware, Docker, SED, Istio, Lingardee, the GitHub CLI, I mean, it's everywhere. If it was written in Go, it probably uses Cobra. Let's touch on a brief history of Cobra here. Cobra's first commit was in 2013. And it came out of sort of that same group at Google that was doing Core Go. So it sat right at home within Kubernetes and with CubeCuttle and a lot of the stuff that came out of Kubernetes in the early days of Go. For example, here is the default CubeCuttle command that returns us a Cobra command. It really is the entry point for your actual implementation of your actual features and all the stuff you're actually trying to do. Cobra wraps around all of that stuff. Let's fast forward to today. And this is the 1.4.0 release that I cut in March. And something interesting to, I guess, realize about where we're at today with Cobra is that I more or less maintain Cobra by myself. Now, before I go any further, let's define what maintaining means here. I have admin privileges on the repository. I can merge code, so merge pull requests. I can triage issues, close issues, and I can cut releases there, sending those packages, sending those APIs into Kubernetes, into VMware, into Red Hat, into Google, all over. And again, before I continue here, huge shout out to the Cobra community. It's actually gotten much better recently. Some other maintainers have stepped up. There's people doing code contributions and still a part of the community. But one of the questions that I get asked pretty frequently about the last few years is, okay, how did I get here? What happened? Well, I was at Pivotal, which was acquired by VMware. And there were a number of people who were also doing Cobra Dev that left, attrition, that sort of normal thing, and then the pandemic. And I often ask myself this question, how the hell did I get here? But I found myself as the solo maintainer for Cobra. I am a solo maintainer for Cobra. Let's define what solo maintainer is. A solo maintainer is an individual or a small group of individuals maintaining a project with little to no support. These are people on their nights and weekends. They're not getting paid. Just a passion project. It's not really part of their job. Those are those solo single maintainers of these projects. A quick show of hands. Who would define themselves as a single or solo maintainer if you have a project like that? Okay, that's like 20% of the room. Okay, there's a flip side to that. There are people who consume those projects. Now raise your hand if you would consider yourself a consumer of one of these. Should literally be everybody. Because everybody at Kubernetes, CloudNativeCon, consumes Kubernetes or one of these projects in some way, which consumes Cobra. And here we are. So I think a lot about my experience maintaining Cobra. There it is. And this talk is really philosophical. It's not a deep dive on the Cobra technology or really how the technology integrates into the Kubernetes and CNCF ecosystem. It's really a deep dive on the solo maintainer experience. And a lot of the pitfalls that you solo maintainers may find yourself in. And some of the things that you can do to mitigate risks that are associated with these kind of projects and challenges. The flip side of that are the consumers of these projects. And what you can do to sort of analyze these risks and approach these risks and hopefully make things a little better. So first I want to talk about contributor communities. And I'm not the first person to talk about how important contributor communities are. I definitely won't be the last person. But contributor communities, as I define them, are a group dedicated to the success of an idea. And I think you can almost look at all of us and this contributor community. People in Kubernetes and the CNCF are really dedicated to the group of ideas around a distributed containerized workflow world. That is a contributor community. More generally in the open source this might be people contributing back code, contributing to the discussion in some way, contributing issues, feature requests, bugs or security reports. So why are contributor communities so important? Well they really are the lifeblood of success and longevity and stability in your projects. From a solo maintainer perspective, I think anybody who's doing this kind of passion project would want to see their thing get used and be successful. Communities give you that kind of support to give your project legs. One person, two people, three people really could never scale to make something like Kubernetes or any of the CNCF projects as successful as they are today. From a consumer perspective, through providing that support and through being a part of the contributor community, you sort of give away to give those projects longevity, stability and support. So I want to tell a story. And I think this story illustrates really, really well just how powerful contributor communities can be. This is Java and the first browser wars. So let's date ourselves way back to 1995. There was a quite contentious war for the browser and the early web. At the time the internet wasn't programmable, it was just static content being served. And Microsoft internet explorer was sort of in this fight with Netscape Navigator. And Netscape Navigator wanted to bring programmability into the web. The way they envisioned this was through bringing the Java VM into the browser to enable Java applets to run right on your webpage. And one of my favorites back in the day was RuneScape. I played this so much when I was a kid, but yes, this ran on the Java VM in your browser. So the idea was that Netscape was gonna partner with Sun Microsystems to bring Java in. Enter Brandon Ike. This is a screenshot from the Lex Friedman podcast, number 160, really, really good episode. It's like three hours long, so buckle up, but highly recommend this. But Brandon Ike was a early employee to Netscape and was tasked with sort of having this happen by bringing Java into the Netscape Navigator browser. He said they, Netscape, started to deal with Sun Microsystems. The idea was to put the Java VM right in the browser. The opportunity was for a companion language. So sort of what he was tasked with was creating this sort of glue duct tape language that maybe designers or product people could use that wasn't too low level at the actual Java VM level. At the time it was called Mocha, and today it has become JavaScript. Brandon and I created this thing in 10 days. He said the internet meant there was a huge first mover advantage being fast. Getting out first, it mattered a lot. So they got something out really fast in 10 days and it had a ton of sharp edges. It was almost unusable. He also said worse is better. I don't know what that says about JavaScript, but there you go. But JavaScript really took off and people loved it. Frameworks and snippets and different libraries and it grew fast beyond Brandon Ike and the people at Netscape. Today JavaScript is the most popular programming language in the world. This is the Stack Overflow 2021 Developer Survey. Java on the web is basically no more. There's a lot we could dive into this story, but the contributor communities were so important in making this happen. Without a community, you risk success. Without a community, you risk longevity. So the lesson learned here, communities are a necessary unstoppable force. For solo maintainers, you need to invest in your communities and I would argue you need to invest in your communities almost as much as you invest in code. That way you can build a system of support around you to give you that longevity, to give you that support that you need in your project. For consumers of these single maintainer dependencies, be a part of the community. That's it, be a part of the community. Giving that support to the maintainers, being there for them when they need reviews or any of the number of things within the community, you become a part of that system of support. All right, next, let's talk about the secure software supply chain. And the secure software supply chain always makes me chuckle a little bit. Because I never really know what it is. But the way I define it in this talk is it's a dedicated automatic process for consistent replication of deliverables. And I think this is actually best illustrated by some animations I made here. Oh, whoops, nope. Before I talk about that, we also need to talk about the maintainers of these projects. I think oftentimes we forget about the people, the people as part of the secure software supply chain. There's a lot of really interesting things happening with Sigstore and S-bombs within Kubernetes and CNCF. But we forget about the people sometimes. Okay, why? Why are the people so important? Well, really, in my opinion, maintainers are the secure software supply chain. Without maintainers, it all falls apart. You don't have people maintaining your S-bombs. You don't have people maintaining your CICD systems. Okay, here's the animations. So let's illustrate this with some of these animations I made here. These are some packages, maybe a product, maybe a library like Cobra. And let's look inside of these packages that we're shipping to our consumers, to our customers. Everything's good. Everything is as expected. And we can ship that away. And all is good. Now let's say we come to the next release. Some more packages. These are gonna go out to people, consumers, whoever we look inside and there's some bad middleware or something. That gets shipped out to people. Maybe it's a CVE or a hack that happened and people are not happy. Maybe we have to make a statement or do a nasty patch release or something. It gets messy. What if we had some dedicated automatic system that could detect these things and stop them from happening? We detected some bad middleware, something got injected. We can stop it there. All is good. Now again, I think oftentimes we forget about the actual people. These people have to maintain these CI CD systems, the S-bombs, SigStore itself. And in this case, it's being maintained all as well. But unfortunately, people fall asleep. People leave projects. Sometimes people just completely abandon projects left to dust. In this case, this person is gone. They've fallen asleep. We have another release. But our whole secure software supply chain system has gone into disarray. We have another bad middleware. We can't catch it. Things are not right. It gets shipped off to people. And I want to illustrate this with another story here. And I think this really illustrates well how important the single maintainer, the solo maintainers, are within the broader secure software supply chain. So this is MPM event stream and the crypto bandit. A number of years ago on this project event stream, which was a popular JavaScript MPM streaming library, had this issue opened up. And a quick note on this library in MPM, it was used everywhere, but not necessarily on purpose. It was one of those transitive dependencies that got kind of pulled into everything. The issue says, I don't know what to say. And the user opened this up and is basically asking the owner, why was this new person given ownership access to the repository? And why were they also given MPM publishing access? So essentially, this person was publishing new packages to MPM as part of their new ownership of the repository. That person had also made a very, very, very strange commit. It was decoding and encoding a bunch of random stuff and then getting injected into the actual module. So clearly, something very weird was happening. The owner came back and said, he emailed me and said he wanted to maintain this module. So I gave it to him. I don't get anything for maintaining this module and I don't even use it anymore and haven't for years. Then next, he said, note, I no longer have publishing rights to this module on MPM. Yes, hackers of the world, it's that easy. You just ask and then you have it. What this thing ended up being was a crypto wallet stealer. So if it was running alongside a crypto wallet, it would attempt to steal all that crypto within there. And it got shipped out as part of an MPM package that then was consumed by a bunch of other MPM packages. And some people thought that maybe this affected hundreds of thousands of people, developers, companies. It was all over. I think about this story a lot all the time. Trust is so hard within this ecosystem, especially as a solo maintainer. Code is hard to trust. The packages you consume are hard to trust, but oftentimes I find it's the people. It's really hard at the people level as well. So the lesson learned here, invest engineering resources. First, solo maintainers, please ensure your own security. If you don't have a physical security key yet to do two-factor authentication to GitHub or whatever, please. Please go get a physical security key. You have to first ensure your own security so you're not being pride to some of these hacks or attacks. Also, don't be the lone hero riding off into the sunset. You need to bring other people into the inner circle. You need to bring other people into the maintainer track so that you can start handing off responsibilities, that there are other people there to help along the way so that it's not the one person giving up the package, abandoning the package like we saw in the NPM story. For consumers, the same goes for that. You need to get on the maintainer track, invest some of your engineering resources, those people, into these important projects. Look at your stack and look where there might be these projects that are at this kind of risk, because this happens and it unfortunately happens all the time. All right, next. Let's chat about the lottery factor. The way I define the lottery factor in this talk is it is a spectrum of risk correlated with the personnel on a team. More anecdotally what it is is what would happen if I or some really important person on your team, your product team, your open source team, what if they won the $100 million Big Buck bonus or something and they never touched a keyboard again in their life. They were just gone. They did not care. They didn't want to work anymore. That's the lottery factor. And it really is a spectrum. I don't think anything falls too far on one way or another. Sometimes you end up with solos here or there. But in the solo maintainer perspective, that really is the highest level of the lottery factor. Like we saw in that last story, if people leave, that is catastrophic. So why is this important? Well, attrition is normal. It happens everywhere. Attrition of critical people is scary. Attrition of solo maintainers can be absolutely catastrophic. These are the people maintaining projects all by themselves that have these massive projects underneath them. NPM, the NPM event stream, Cobra. So let's tell another story. And this one is a little bit more hypothetical. It's about Cobra and how Cloud Native could fall apart and really from my perspective. Cobra is just, it's a library. It's a bunch of APIs that we ship out, important APIs that wrap around a bunch of really important stuff. But what if I just won the lottery one day and then my account got compromised or something else got injected somehow? Those things then would end up getting shipped out into Kubernetes, Istio, Linkerd, Tanzu, Helm, all of these. And this actually came up recently. The most recent 1.4.0 release of Cobra had some people from Kubernetes. And I was actually talking to people from SIG CLI yesterday about this. This was huge. We noticed that there were all of these dependencies getting dragged along into Kubernetes and kubectl that really were completely unnecessary. So we were able to remove a ton of dependencies to sort of reduce the surface area of potential attacks, of potential CVEs coming in from those other libraries. This was really, really big. But a question I think everyone needs to ask themselves, especially you solo maintainers, is what if I won the lottery? Really ask yourself that question. Would you work another day in your life? Is your project ready for something like that? And it's hard. It's really, really hard. I don't think there is a hard solution to this at all. Even on product teams, they deal with this. There's silos everywhere. You really have to look at it from a spectrum perspective. But I do think that there are some valid strategies. The lesson learned here is create processes to mitigate the lottery factor. For solo maintainers, you need to create that pathway to maintainership, that pathway to the inner circle. And I'm really talking about process here. Like, yes, you can bring people in, but there should be a process that people can start on your project to become a maintainer. Two is documentation. Documentation is really huge. Again, I'm not the first person to talk about how important documentation is. I won't be the last. But documentation, even of the minutiae, even of the little things that you think don't matter or aren't a big deal, can become absolutely huge as soon as you're gone, maybe you've abandoned the project, who knows. Consumers, the same goes. Consumers of these projects, you need to get on those tracks to becoming a maintainer, to getting some kind of access right. And contribute back to docs as well. You can look at the docs. You can read the docs and see where there are problems and start contributing those back. All right, last thing I wanna talk about is incentive models. And this really could have been its own talk in itself. Incentive models are systems to encourage desired behavior. And you can look at this from your own perspective in the way that you do work. If one day at your job, you just weren't getting paid anymore, I seriously doubt you'd continue working. These are incentive models, but they get really, really tricky in open source. For me, personally, it's about personal satisfaction. It's about seeing something get used at this high level and seeing something that I create, or PRs or issues that I'm a part of get kind of brought into the bigger good. I think about this sometimes from the perspective of game theory. Game theory is sort of the study and the idea of how n different number of factors could be a lot affect a very complex system. And open source, if not the Kubernetes CNCF ecosystem is incredibly complex. So those incentive models are really complex. You not only have individuals, but also groups of individuals, small companies, huge companies. These incentives really are anything and all over the place. Why is this important? Well, really in my opinion, without incentives, no one would do anything. So you really have to look at the incentives of the important projects that you are consuming and also that you are creating. Let's tell another story. This is about Faker.js and the dark side of open source. I realized yesterday that I was taking a pretty big dunk on JavaScript, love JavaScript, but these are very relevant stories. So Faker.js is a testing library within the NPM ecosystem that you can use to generate all of this testing data. It's really useful for front end when you have forms or a lot of different data with names, dates, all kinds of stuff. It's really, really useful. But one day back in January of this year, the owner of this project just blasted it away. They removed the get commit history. It was just one commit with basically an empty repository. The NPM packages disappeared as well. And we could go into what the heck was going on here, but a lot of speculation popped up and one interesting thing from years back that this person had said was no more free work from Merrick, pay me or fork this. People did fork it and it continues on to this day without the involvement of this person. But I think a deep analysis of these important projects and a deep analysis of the incentives of the important people in these important projects should have led some people to this kind of conclusion that, hey, this is risk, this is pure risk right here. So the lesson learned is without these incentive models, without looking at these incentive models, everything else risks falling apart. You risk your collaborator community falling apart, you risk your secure software supply chain falling apart, everything, those critical people and their incentives should align. So solo maintainers, you need to identify your own incentives. Maybe it is getting paid, start a Patreon, there are GitHub sponsors, you need to start working towards those things. It's critical that you identify your own incentives and that you start working towards those. For consumers of these projects, I think this is especially key here, this is especially key. You also need to identify your own incentives and that gets very complicated from big companies, small companies, they're all consuming these projects for different reasons, different products, all sorts of things. But you need to identify your own incentives, how those align with the important people in those projects and then also identify those important players within these projects and start to identify their incentives and you can start to see sort of the ecosystem of incentives and where you might be at risk. All right, I wanna leave you with really one thought. If you come away from this talk with one thing, it's this, any solo maintainer dependency is a risky dependency. Just look at the high level logistics of it. One person, one person that is having that thing plopped into your product, plopped into your project, that's super scary, it's super risky. So, invest, invest, invest. You need to invest engineering resources. If you are blindly consuming these projects, blindly just pulling them down without being a part of the contributor community, without looking at the important players and what their incentives are, you're not helping. You need to be a part of those communities and bring engineering resources into the inner fold so that they can start getting on the maintainer track. With that, Cobra needs help. So, if you're interested, I would love to chat with people after or you can find me there on Twitter, but I'd love to take some questions as well. So, thank you very, very much. I think there's a mic here in the center. If you would like to ask a question, please use the mic. One question I have is, I think you've made a pretty good point that this is a risk we should be aware of, but how do we best do that? So, just for example, go dependencies you mostly pull from GitHub and you cannot just see on the GitHub page that this is a risky dependency, something that's just bound by one maintainer. I'm not sure for security, things that are websites that collect security, CVEs, et cetera, that you can use to assess risk of dependencies. Is there some similar mechanism for maintainer risk or do you have suggestions on how to approach that? Yeah, that's a great question. There are automatic things that can start to pick up these things like Dependabot on GitHub. You can use Dependabot to start picking up CVEs within packages that those things consume and on down the line. But a lot of what I ended up talking about was really people processes and people. And I don't think that there's automatic processes for picking up on those things. It really means that you have to be a part of those communities in some way, even if it's looking at the issues and seeing what's the tone of some of these people. Anecdotally, a lot of people don't really seem very happy with me, within Cobra, within the issues. And you can pick up on that in just looking at the issues, partly because I just don't have a lot of time to actually dedicate into the project. Somebody could look at that and say, it seems like there's something going on here. Maybe I need to get involved, reach out to me on Twitter, just ask, hey, is this project okay? Yeah, so it's really, really hard. I don't know if there's a good solution from the people side of it beyond getting involved in the community. Yeah, great question. I had the same question about how to actually identify dependencies. So thank you for answering that. And it's really insightful. Thank you. Thank you, thank you. Yeah, great talk. So do you believe that open source projects should be owned by companies or sort of organizations instead of individual maintainers? That's a great question. It probably also could have been its own talk. I don't know. Cobra is really hard because it's been around for so long at that import path. So github.com slash spf13 slash Cobra has been around for almost 10 years now. So what happens when we try to move that into a GitHub org and it destroys everybody's import path? I know there's different systems and things and we've talked about this and I don't think there's an easy solution for that. So the history of a project I think is really important, like for Cobra, it's been around forever. So moving it into an org would be really challenging. I don't know. Yeah, I wish I had a better answer for that, but orgs are great and I think that orgs with good governance, like we heard in the keynote this morning, can be really critical to ensuring the success of a project. I honestly should add to that as part of my contributor community part, but yeah, having something in an org with good governance and good contributor guidelines and getting on the maintainer track is well defined. That can be really, really powerful. Yeah. Thank you. So how do you deal with kind of being the single maintainer? I mean, doesn't that stress you out? I know it would stress me out totally, like being responsible and I'm on vacation, but suddenly something comes up. Yeah, it's not a good time. I do think about the weight of it and I think about the responsibility of it, which was part of that effort to bring a few more people in and actually get them also maintainer access, but in the end today it's really three of us. Even that is scary and even that I would say is a huge risk for such a big project. For me personally, it comes down to personal productivity things. I time box Cobra pretty hard, so I'm not gonna dedicate much more time to it than I can, like I'm not getting paid to work on Cobra. So I can only give it so much time so that my incentive models continue to align with it. Like I do get a lot of personal satisfaction from it, but I'm only gonna work on it so much as my personal satisfaction and my incentive models continue to align. It is stressful, yeah, I want to deny that and please come chat with me about getting on our maintainer track and contributing back to Cobra. Yeah, no problem. Thanks, John, it was a wonderful talk. The question I had was around the maintainer circle and how you bring people closer in that circle. Do you have sort of a litmus test on trust and when you decide to give someone certain access rights and what sort of tears do you have, just a singular tier, or do you think about multiple ways to come closer? That's a great question, yeah. I do think multiple tiers can make sense. Like still today, I don't actually have ownership access over Cobra, SPF 13 is Steve Francis, he is the product lead of Go at Google. So he, I think by himself maintains or has the ownership access over that repository. Again, I would say maybe that's a risk, but I individually would not be able to go up that level to the admin level and blow the repository off of GitHub. That's only Steve and he's kept this thing around for that long. I do think levels make sense. As far as the litmus test, it really is people that, I don't know, even that's so hard. Again, that's a people question. Like how do you judge somebody's character by their pull requests, their issues, your interactions on Slack? That can be really hard. There's been hacks in the past where people have gained somebody's trust and then kind of worked their way into the inner circle before you know it, they're pushing bad code or something. So I would even say within your inner circles, there need to be systems. Like there shouldn't be people pushing directly to your main branch. I think that's just a good practice, but you should also have multiple people reviewing PRs. There's good processes around the inner circles that I think can be powerful to mitigate those things. But for me personally, it is sort of a gut check, sort of a gut feeling. I've interacted with a lot of people within Cobra. One person caught my eye pretty clearly, his name is Mark, and he did a lot of the completion work within Cobra recently. So today within the newest releases of Cobra, you can do PowerShell, ZShell, Fish, Bash completions, and it's really, really good work. I don't think somebody would dedicate that much time and that much energy into this project if they weren't at least somewhat trustworthy. So that was a big mis-test for me with Mark, and he actually has come into that inner circle of maintainers, so it's really hard. Yeah, no problem. Hey, great talk. So I learned something about my code base today. It depends on Cobra. And I don't know what package brings it in, but I don't use it directly. And auditing hundreds of packages that are brought in by other packages that are brought in by other packages, how do you fix that? How do you fix that? So you're asking how do you fix the transitive dependencies? Yeah. That's... Because that's nasty. I mean, the entire community needs to do their auditing, starting with everything, or I don't know. Yeah, that's an excellent question. I don't really know if that's a solved, I don't know if there's a really good solution to that. I'd love to talk to you afterwards because even at VMware within Tanzu Community Edition, we've had problems with all these transitive dependencies coming over from some other package that's importing some other thing. And then Dependabot is alerting and we're like, oh my gosh, what is this? We don't use this, right? I don't know if there's a good solution within Go itself or if there's work that needs to be done up in the upstream within Go Mod. But I think the model that we saw with Kubernetes coming to Cobra and saying, hey, we see all these dependencies coming in from Viper. Can we remove these? And I looked at it and I said, yes, it'll be a huge effort, but we can. So finding where that's getting drawn in, using Go Mod Graph or whatever it is, finding where that dependency is getting pulled in, maybe going into that project saying why? Can we remove this? Do we need it? Finding out what is necessary, right? Thank you. Follow up question if I may? Sure, I'll go as late as you like. Okay, I didn't even know I was using Cobra before today. So what about all the other hundred packages that I don't know about that are single maintainer? Yeah, I mean, even more philosophically, I would say this is a very big problem, not just Cobra, not just Kubernetes, but there are hundreds of thousands of these throughout the internet and just the software industry as a whole. I don't know. I wish I had a better answer beyond like, hey, get involved, like, hey, we need to be better about this. It's really about trust. I think about that event stream package story all the time, because it was one person. It was one person that just said, yeah, I don't use this anymore, give it away. I wish there was a better system beyond being vigilant, creating those automatic systems to maybe detect when there's inconsistencies in your deliverables or something weird is happening. That's the best we can do from an automatic software standpoint. And then, yeah, getting involved in important projects that live in your upstream. Yeah. Super, thank you very much. No problem. Thanks for the great talk. I was going to actually ask what the gentleman earlier asked around how you would vet a new maintainer when they joined the project. But I was also gonna ask clearly coming here today is a sort of call for help in part. Have you tried other techniques to try and get more maintainers and have they been successful? What have you? Haven't you tried? Yeah, yeah, you know, I've tried a number of different things. It's, hmm. You know, it sort of is the game of thrones of open source sometimes where, you know, you don't want to step on this person's toes by doing this and that. Like, I think it would be a mistake to just go and fork Cobra. Again, it's all the import paths. It's like how many things it touches across the CNCF and Kubernetes ecosystem. I mean, that would just be like a herculean effort to just be like, we're gonna fork this into our own organization without, you know, first chatting with Steve Francis, chatting with me, chatting with people in Kubernetes and throughout the CNCF. Yeah, again, I wish I had a better answer, but yeah, I don't know. That's fine, thank you. No problem. Hi, thank you for your talk. And so I would like to share maybe an idealist opinion, but rather than having a single maintainer, which is a single point of failure, do you think that it is possible to say to people, for example, that, okay, you contributed this to my project and so for future modification of this part that you contributed, you will be the maintainer of this part only. And so it will really use some pain because you will still have to click the Merge button for sure, but you will have someone that already contributed and that will just do the code review for you, for example. I know that some projects do this, for example, in Big Root when you add a Recype, you are sort of maintainer of the Recype, so you are not falsely, you have not to maintain it, but it is appreciated from the main maintainer if you do it. So what's your opinion? I think that's a really interesting idea and I do think it's something that's been tried. Unfortunately, I go back to that chunk upon the lottery factor. I mean, I think you'd be pretty hard pressed to get anybody to stick around, say they contributed 200 lines of code, that person's gone more often than not. And that's a useful, maybe that's a very useful chunk of code that's being committed in. I don't know if you would want to hold off on a merge just because this person's like, maybe I don't have the time, maybe I don't have the bandwidth, but this would be really useful to me. I think being accessible is really important within a contributor community. So I don't think I would personally do that. It would keep, I think, a lot of people out and in the end you would almost end up with just an extreme silo of just a few people willing to stick around to do that, you know what I'm saying? Yeah, it really is sort of a, like you're really fishing for those people, the really dedicated people like I brought up Mark. Mark is great and I noticed pretty early on that he was showing up and he was contributing to the discussion not only in Slack but issues and PRs and doing reviews. It was clear to me that this person was sticking around. I think it'd be a lot harder to just tell somebody, like no, I'm not merging this until you dedicate yourself or dedicate some time or something. Again, incentive models, like why would anybody? Like it gets really hard to say like, no, I'm not gonna merge this until you stick around. People are still gonna leave even if they agree. They're gonna tell you, yeah, sure, I'll stick around. They'll stick around for a month or two and then wash away essentially, right? It's super hard. I think that's an interesting idea and I do think it's been tried before but I don't know if that's the approach I would take. Okay, thank you. Yeah, no problem. All right, we're a bit over time. Thank you everybody, I'll hang out here. Thank you.