Latest / The MonkCast / Vlad Miricioiu on the Software Stewardship Lab: Binary Dependencies, Burnout, & the Bernies

Transcript

Vlad Miricioiu on the Software Stewardship Lab: Binary Dependencies, Burnout, & the Bernies · The MonkCast

• speaker-0: Hello and welcome to this Red Monk Conversation. My name is Kate Holderhoff. I am a senior analyst at Red Monk. And with me today, my guest is Vlad Harbus. He's the director of the Software Stewardship Lab. Vlad, thanks so much for joining me here on the MonkCast. speaker-1: Thanks so much for having me. I'm excited to to talk. speaker-0: All right. Well, ⁓ I I suspect many folks would be interested in your background and how you arrived at your current role. So would you talk to us about who you are and and ⁓ what you're up to these days? speaker-1: Sure. So I started working on a thing called the open source pledge around two years ago. So this is an initiative by Sentry. And the idea is that we ask companies to pay the open source maintainers that they depend on, or really just any open source maintainers or foundations that they think are important. And yeah, so we ask for $2,000 per developer employed at the company per year. And we've raised $7.2 million so far. And I'm I'm really happy about that. And I think All of the money that companies have put into this through the open source pledge ⁓ does a lot of good to maintainers. We don't touch any of the money at all. So we just send or the companies send it directly to maintainers. But we ran into a problem, right? So talking to companies about their payments to maintainers led me to discover a lot of software supply chain issues, such as, you know, companies would ask, well, who should I pay? The the people that I depend on, who are who are they? Right. So ⁓ I got into scanning supply chain sorts, scanning dependency graphs for companies to figure out who they depend on. And that, you know, went well for a little bit. And then I realized, wait, there's so many holes in these graphs. We don't even know all the people that we depend on. Because you have stuff like binary dependencies. So sometimes your code might include a compiled form of some other code. But that's not recorded anywhere on in any of the manifests. So that's one thing. And then, you know, we ran into so many issues. Like, okay, well, which projects are still maintained? It's not easy to tell, right? So you might have all sorts of issues with all the software that you depend on. You might have security issues where this thing that you don't even know you depend on is end of life. And there's barely any signals to discover that. And so I was like, ⁓ my God, this is such a big problem. And I was working at the time with ⁓ Andrew Nesbid, who is maybe the most experienced person in package management anywhere in the world. and also Miranda Heath, who ⁓ works on burnout in open source. So she wrote this report, this excellent report, where she she interviewed some people. She also compiled a bunch of online sources ⁓ that talk about people's experience with burnout. And it was really Touching. There was a lot of stuff in there that was really dramatic. And when she released it, a lot of people said, Wow, you know, it's not just me. And this really resonates with me. And this is so important to address. And so it sort of emerged that it would make sense to start some kind of institution where people can get together and do research on open source sustainability topics. And that's the software stewardship lab. So we have six directors. It's me and Andrew and Miranda. And then we have Daniel Rowe, who's the leader of next, ⁓ Mathias Capaleto, ⁓ who is a community leader in NPMX and and V and so on. And we also have Don Foster, who's an expert in metrics, and we are advised by Mike McQuaid, who's the leader of Homebrew. So I'm really grateful to work with with everyone. And yeah, so we have our main focuses right now are software supply chain stuff where there's a lot of problems to address and maintain our mental health. speaker-0: Okay. So ⁓ that makes sense in terms of what you're like researching. So do you have like a mission? Like how do you frame that? Like improve software supply chain stuff, ⁓ decrease mental health issues, ⁓ you know, burnout? speaker-1: So the way that I look at it is, you know, I love open source software for a lot of different reasons. ⁓ I also just love developing open source software, I love the community, but I think it's important to also keep in mind that a lot of the cr you know, critical open software that we rely on, is stuff that our critical infrastructure depends on, right? So transportation, healthcare. A lot of really serious industries that we rely on for our well-being are underpinned by open source software. And so our aim at the stewardship lab is to try to make sure that the software that ⁓ underpins that infrastructure doesn't break. So that's our general mission. Whatever we need to do to make sure that we can improve things in that respect, to improve the stability of critical software, ⁓ is something that we're interested in. Right now, just because of our you know, current issues that are popping up. And, you know, we've seen all of these supply chain issues, especially with ⁓ you know, LLMs right now and and all of this stuff, ⁓ be a current topic. And also it's just what we're currently researching. Right now, those are sort of research focus points, but we're broadly interested in just making sure that the world's open source infrastructure is stable. So really important stuff doesn't break. speaker-0: That's fantastic. And I I love the idea of calling it a lab as an academic myself, and I understand you are also ⁓ pursuing a PhD. It sounds very academic, very, you know, like I got my mortarboard on. I love that. ⁓ did you consider calling it like a foundation or or going with some other way of framing it? Like how did you end up with a lab? Is it is it purely because you you love ⁓ the Ivory Tower? Is that what's going on? speaker-1: Well, no, and you know, I I have very mixed feelings about the Ivory Tower, to be honest. But ⁓ the the f the lab framing comes from ⁓ the fact that you know, I think there's so many foundations that do a lot of really important stuff. We just saw an announcement from the Python Software Foundation recently about how their infrastructure costs are going up th and you know they're n you know, they they they don't get enough money to pay for all that stuff despite the fact that they are one of the most critical at least, you know Pypei and so on is one of the most critical pieces of software there is, right? but ⁓ for various reasons, foundations have not always paid people to do research and to develop software to sort of to contribute to open source software specifically. There are sort of caveats there. So there are people that that manage, there are foundations that manage. So for just as an example, going back to the PSF, Steph Larson at the PSF does incredible security work. So That's one example. But overwhelmingly, from what I've seen, partly also because of the US tax code, historically, it's been difficult to convince the IRS that it is within the scope of f of a 501c3 to develop open source software, to contribute to open source software, to maintain it, to you know, justifying that that's in the public benefit has been difficult. And I think that for ⁓ that reason and some other reasons when people think foundation. There's sort of all this other stuff that foundations do that they associate with that. Whereas I really wanted it to be clear that we do research, right? So we create software, we want to find places. Like for example, package managers are a crucial point where security improvements can be made. We seek those places out, we make improvements that ⁓ benefit everyone. So that's actually creating software. We write research reports like Miranda Heap SparNet report. And then we also ⁓ are working on services. So for example, Andrew Nesbitt ⁓ is the creator of ecosystems, which is the biggest open source intelligence platform. Let's just can I pull that up real quick? So he's yeah, so ecosystems index is 14.4 million packages and 293 million repositories and counts speaker-0: Absolutely. speaker-1: 24.6 billion dependency relationships. And that's all ⁓ intended as a public benefit service, right? So there are rate limits for large companies that hit the service very hard, but it's intended to be made available to to researchers and and the public. And you know, ecosystems, I know that a lot of companies rely on ecosystems for their for profit stuff, but it just doesn't get enough money. for the volume of traffic that it's seeing and for all of the stuff that we could add to it. So yeah, that's I g this is all to say we work on sort of very practical applied software and research, ⁓ which is why I I, you know, hopefully like we thought that the word lab might convey that a bit better than some other terms. speaker-0: Yeah. Okay. Okay. ⁓ all right. Well, so looking forward to talking about the security issues, but let's start by talking about the money because I I thought that was an interesting point in your ⁓ sort of launch blog post. and ⁓ and I also feel like it's it's a little controversial, the idea of paying maintainers. ⁓ there's so many different models for it. So I'm interested in and of course this comes from your own work with ⁓ the open source pledge. so Talk to me about your commitment to paying maintainers, because just to lay out some of the things that I've heard, th in the 2010s, it used to be more of like ⁓ companies would hire somebody who's dedicated to working on certain open source projects. And that was one model. ⁓ another model that always comes top of mind is like Vercell for a while was giving like $5,000 a month or something to certain frameworks that they used. I mean, the it the it runs the gamut, right? So there's all these different ways to compensate folks. And my understanding of the underlying rationale behind this is because so many companies can't ⁓ their their employees can't contribute upstream. And that creates huge huge problems that lead to burnout and and just make open source unsustainable. Talk to me about your model and why you think that this is the best way to go about supporting open source. speaker-1: Well, I don't think it's the only way, certainly. I think companies do a lot of important things. ⁓ I think employing open source maintainers in a way that lets them continue to work on their open source stuff, I think, is is a model that works for a lot of companies and a lot of maintainers. But I think it's worth keeping in mind that, you know, so there was some research from I think just yeah, around two years ago from Andrew Nesbut where he scanned some of the most critical packages and various ecosystems and he found out that I think it was eighty percent of so the the packages that account for eighty percent of all downloads are maintained by around five thousand people. So there's around five thousand open source maintainers that maintain the the vast majority of important packages. Now those people often maintain multiple projects and have a lot of specific knowledge about what work needs to be done and so on. Some of those people might find a good place in the company that that works for both the company and also allows them to continue doing the work. But that's not always true. And I think that, you know, there's many solutions to this problem. And I think probably paying maintainers directly or paying specific maintainers might not even be the best long-term solution. Right. Maybe this is sort of a ⁓ in the long term is an unreliable thing. I know, you know, there's other models like the sovereign tech agency. Doing so much to fund open source projects using tax money. So I'm very open to there other be to there being other solutions in the long term. That being said, at the end of the day, we have people that are working independently, independently of any specific company, with a great deal of knowledge about stuff that's really critical. We really need their work. And it's very difficult for them to get paid for this work. ⁓ without a tremendous amount of effort, even though so many of us rely on the stuff that you do. And so a very straightforward solution there, especially when you have companies that make millions or billions of dollars using this open source software that's sort of a key part of their product, ⁓ a a very straightforward solution is to give back to those people, especially when companies can definitely afford it and allow them to keep doing their work in the way that they know is best. ⁓ And yeah, letting them make those decisions and sort of letting it be an open-ended thing for these maintainers. And you know, I think another thing there is one issue that I've personally run into is a lot of this work is not very well understood. So just to give you my own personal example, I work on the supply chain stuff that I just talked about. I'm very grateful that Sentry pays me to work on the open source pledge. And I think that's a tremendously good thing that they're doing to support that initiative. but working on the open source pledge for me is when it comes to the proportion of time, is you know, ⁓ a relatively small proportion of my work in terms of time. Doing this ⁓ software supply chain research ⁓ and working on the stewardship lab takes up the majority of my time. I know that companies use for their for profit products work that we do at the stewardship lab. And we basically the search up lab right now has next to no funding. It actually we have negative funding because I paid for a lot of the ⁓ administrative costs out of my own pocket. And so I have companies saying, hey, the supply chain stuff you're doing, you know, particularly ecosystems that Andrew built that is extremely important. You know, companies say, Wow, these product these services and this technology is so important. We need more of this, we need more of this research. This impacts our business. And then when we say, Hey, are you able to to pay for this so that we can continue doing this work that you yourself say is important? ⁓ you know, it's mostly crickets, right? ⁓ speaker-0: Yeah. Yeah. Okay. ⁓ and so is the stewardship lab incorporated like a nonprofit in the UK? is that right? speaker-1: Yes. So we're incorporated as a Scottish nonprofit and our articles of incorporation legally bind us to using all of the money that we get to further our mission, which is ensuring the stability of the world's open source infrastructure. and we have this ⁓ board of directors. So three of the directors are all also do this actual research, whereas three of the directors are more independent. And so together we are you know, are legally bound to ensuring that the money is used for these purposes. speaker-0: Got it. Okay. And so I'm not sure how the tax system works in the UK, but ⁓ I know in the US, if ⁓ a maintainer receives that money, a lot of times they're not able to have a different job and they've gotta like do all kinds of, you know, stuffs to set up becoming a contractor, and then they gotta pay for health insurance and stuff that a lot of maintainers that I know don't wanna mess around with. Is that the case ⁓ for the maintainers that you're working with? Like how are they grappling with ⁓ I don't know, you know, all all the stuff that goes with accepting the money, all the baggage that comes with that? speaker-1: I think it's that's difficult to say because I think it varies so much by jurisdiction, right? I think as far as the people that I work with, there's certainly ⁓ limitations in terms of ⁓ doing mostly contract work, right? So you don't have the security that a job that that comes with a job. Yeah. Which is why again, I think for the people that can do their open source work as part of a company, I think that's a great thing because they have that job security as well. ⁓ at the same time, I think a lot of people, even if they have to do it as contract work, they will very happily take that additional bit of admin that they have to do if it means that they're they're they're able to have the freedom to direct their own work. ⁓ but I think that's just, you know, I can tell you about my experience and people that I directly work with, but I think actually that would be a really great topic for some type of survey or study. Because I don't know, you know, about people in France and Germany and the US and Japan, right? Like I don't know what the jurisdiction what what those jurisdictions sort of would require. So I I I on a global scale, I really don't know. Maybe we should find that out. speaker-0: Yeah. Yeah. I I think that'd be worthwhile. Another project for the lab, that sounds like. ⁓ potentially. Okay. Yeah. No, it's ⁓ that's good. Do I mean just ⁓ anecdotally, do the maintainers that you have distributed money to do they have day jobs in addition to working on open source or are they doing this as a a full time ⁓ gig? I I don't speaker-1: I don't feel that I I don't have the data on that that I feel like confident saying, right, to be honest. In my experience, it's it's mostly ⁓ people that are working independently. Or it might be people that have a job that is software related, but does not necessarily allow them to work on open source. So my experience is that a lot of the time these maintainers are doing this work in their free time. Yeah. And I think a lot of this comes through in Miranda's burnout report where you get these quotes from people saying, ⁓ well, actually let me let me I have I have a couple of quotes that I think are really powerful here. So we have Ashley Williams saying, I was doing nights and weekends, it was wrecking my health and I was just devastated. So after a while, enough issue follow ups like, Is this maintained? Are you gonna fix my issue? I had to say that I have to give up. And then we have Jacob Kaplan Moss saying, I wasn't getting paid to do the work that I felt I had to do. So that's the open source work. And I had to do the work that I was getting paid to do. That's the ⁓ employment. Because like mortgages and bills and car payments and that sort of stuff. So I had to do like double work, one out of one out of a feeling of obligation and one out of a feeling of like we live in a capitalist society and I need money. Yeah. So I d I'm not comfortable s making a statistical statement. I I don't really ⁓ have a a sort of n numerical overview of how common that is, but I have heard these kinds of stories from ⁓ people that work on really important stuff. And I think that we should try our best to support these people, you know, when they find themselves in these situations. speaker-0: For sure, for sure. Well, it seems like that you've already got a list of folks that you could ask if they are allowed to accept money for their open source work, ⁓ by virtue of their their other jobs. ⁓ and you have mentioned Sentry a couple of times. Like what is the nature of ⁓ that economic relationship? Like are they just like like partners or yeah, what what does that look like? speaker-1: Yeah, so I basically am a contractor for Century. I specifically work on the open source pledge. The open source pledge used to be led by Chad Whitaker, who I care about very much, who has done so much work for open source. But Chad recently retired not only from his job, but also from computers. So he's living offline. He is ⁓ he's not touching computers anymore. He's actually writing a Christian magazine about how to live offline. And I get the issues and it's very touching and very sweet. and ⁓ but you know after Chad retired, I became the main person working on the pledge. and Sentry pays for my work, which I'm extremely grateful for. And in addition to that, Sentry is also giving. So last year Sentry gave ⁓ $750,000 to maintainers that will continue this year. Yeah. And you know, then you hit the obvious problem who Should I give that money to? And so I'm helping Sentry do that kind of supply chain analysis where I look at what projects does Sentry depend on immediately? What are some invisible dependencies that Sentry depends on? So, for example, those binary dependencies that I spoke about earlier. And also, what are some bits of open source infrastructure that even though Sentry might not necessarily depend on it, like a software package or something like that? It might be, you know, something like package management infrastructure or ecosystem cleanup initiatives that, if supported, ⁓ are going to directly ⁓ help Sentries work. And that's another example, you know, I appreciate Sentry being forward thinking there because that's an example of where this kind of research directly makes a difference to the company's bottom line. And that's something that I'm trying to get other companies to ⁓ look more into. to s to see, hey, you know, this work is really important. We should maybe fund it. speaker-0: That's fantastic. And I think that's a really great opening to Segway to talk a little bit more about security. ⁓ certainly something Century's involved with. so I was interested in ⁓ some of the stuff you said in your your blog post around making security more open. And so currently you're you're talking about ⁓ Chain Guard and Socket doing a kind of analysis that is proprietary, and you want to open that up. So I'd like to hear more about that argument and and what you're seeing. speaker-1: Well, look, I mean, I think it's totally fine for different companies to have different solutions that they offer as a paid service. That's awesome. The thing for me though is the data that is that sort of underlies that is data that we shouldn't have to reinvent every time. Right. So we've seen so many initiatives there that build up their own open source analytics, their own models, their own sort of annotations to existing data. And so on. I think it very much goes against the spirit of open source to develop those to have to develop those things anew every time. I think that makes innovation more difficult to researchers that are interested in building tools that help the community. I also think that makes it more difficult for infrastructure like package managers that everyone relies on. So just as an example, if I'm a for-profit company and I develop a way to find ⁓ you know phantom dependencies. I have an incentive to not necessarily contribute that upstream to the package manager because then that means that everyone has that tool that gives me a commercial advantage. I think in s you know, in some cases it's fine to have a commercial advantage, but again, I think this infrastructure is so important that we should really be contributing it back upstream and creating services that are available for everyone. you know, just as an example, we're currently looking at ⁓ the Python ecosystem. ⁓ especially in terms of, for example, making binary dependencies visible in package managers like UV. So that when you list your dependencies, you get the less visible stuff too. and that you can get security information based on that, right? So that you can see exploits that previously would have been invisible. I think there's yeah, so I I just think that The foundational data should be available to the public and should be something that we collaborate on. And especially with all of these models, we see initiatives that want to help open source, but then create their own analysis anew. Whereas if we collaborated on this stuff, we would just be able to do a better job to help the maintainers that need our help. speaker-0: Okay. That is very reasonable. ⁓ I I love that it's got sort of an engineering backing to it. ⁓ but I suspect maybe other folks might be a little more s cynical. So I I think ⁓ so I've been looking a lot into supply chain security. I just think it's the most important topic right now, right? AI. Like it is just everywhere. I I can't not talk about it. ⁓ so and and so I love that you're grappling with it as well. I th I think that that's That's val yeah. I it's like again, it's so necessary. But I one of the things that jumped out to me in your ⁓ opening blog post was that two of the the stewards are members of NPMX. So that'd be Daniel and Matias. So I that's great. They've got all that expertise. But you know, in addition to the fact that you're building an observatory that ranks packages by how critical they are, I'm wondering if that could also be seen as a conflict of interest. Like Do you worry about that at all? And and how are you safeguarding yourself from this perception? speaker-1: Conflict of interest, you mean with NPMX? I mean, I so the way that I see it, I'll I'll tell you my impression. Maybe I'm I guess I'm struggling to see the conflict of interest, but I I am interested in discovering conflicts of interest. So ⁓ Yeah. The way that I see it, it's sort of overlapping initiatives, right? So in the same way that, you know, NPMX I think is a great project and it helps. speaker-0: Yeah. Yeah. speaker-1: ⁓ people in the JavaScript community not only get more visibility when it comes to their dependencies, but also understand them better in terms of file size and performance and all of these things and and security, right? That can help people write better code and more secure and more performant code. ⁓ now as the the stewardship lab has a kind of complementary role, which is creating some of it the technology that enables that. So if we create some research that enables you to discover XYZ thing about ⁓ your packages and that gets integrated into npmx, I think that's useful for everyone. Now, if NPMX was a for profit project, I guess, and the stewardship lab was a nonprofit, then I would see there being a conflict of interest because we would have these directors that would then be incentivized to encourage the speaker-0: Yeah. speaker-1: ⁓ I see what you're saying. Yeah. ⁓ I see. So you're so what you're saying is Okay, so wait, ⁓ is the idea that there's a conflict of interest not between ⁓ I see. So it's not between NPMX per se, but people on our board who develop packages would be incentivized to research that would rank their stuff better or something like that? speaker-0: R right. Well I think, you know, for one you've got that NPMX is a customer, for the lab's product, right? speaker-1: ⁓ well I d yeah, I mean it's hopefully if we develop research that's useful, NPMX could use it. But ⁓ NPMX there's no sort of financial relationship there and I don't know all the details about NPMX's finances, but I don't so it's definitely not a for profit project. Yeah. So I think if a non profit thing helps another nonprofit thing, I think that's great. speaker-0: Universal good. Okay. So not a conflict there. And ⁓ okay. So and then yes. And then to the the second point was kind of the one what you were ⁓ mentioning here. So like ⁓ that the the some of the board members maintain packages that the l lab is then going to rank. and then I guess the third one would be like ⁓ the lab is becoming a grant maker and it runs something that the board members can then distribute ⁓ or be involved in. So I I could just see that there being some you know, there's ⁓ want to be charitable and say that everybody's working for the good, but you know, I think we're here to have a conversation about maybe some some ways that folks might the money you know, the money because we of course began by talking about the financials here. the financials might get a little ⁓ complicated and potentially a little bit ⁓ c ⁓ there there could be some contention about how things are distributed and and ranked, frankly. speaker-1: Yeah. I mean so on those so I I w wanna say generally conflicts of interest in general are ⁓ a problem and something that we take seriously. I we, you know, have in our articles of incorporation, again, legally binding stuff that requires us to ⁓ investigate those conflicts of interest to you know, board members to recuse themselves from any kind of decision that involves them in any way. So that kind of thing. ⁓ so we have procedures in place for that. ⁓ I guess as far as the specific ones that you mentioned, in terms of the research, currently none of the board members have like such granular involvement in the research or it's like, hey, include this other function here to do, you know, say like plus 100 points if it's my project. I don't I just don't think that there's that kind of involvement. ⁓ it's more much more high level. If there was that kind of involvement, that's something that we would need to have flag according to our conflict of interest procedures. Now on on the other end, one thing that I I think is more ⁓ sort sort of important is right now we're not a grant a grantmaker per se, and that you know basically we don't have money, so we're looking for ⁓ funding to ⁓ just be able to do our own research internally currently. If we're able to do that, I think that'll be amazing. In the long term Yes, if we get a lot of funding, it would be amazing to seek out people in the open source space. And that's sort of one of the original intentions of the lab is not just that we do research amongst ourselves. It's to seek out people that are doing the best public benefit open source research and to help fund that research. Absolutely. There, I think in in sort of that medium term, there is a question of, okay, well, am I just getting all my friends to do the work, even if they're not doing the best research or, you know, hopefully the fact that we have six ⁓ board members, free of whom are not directly involved in the research and one advisor, hopefully that will moderate that. But of course that's something to be you know, because ⁓ at the end of the day, if we just, you know, gave support for, you know, if we gave funding to just people that ⁓ you know, not based on them doing the best public benefit research. We would just be failing. It would just go against the whole mission of the whole thing and it would be kind of pointless. So yeah, of course that's important. speaker-0: Yeah. Yeah. Yeah. I ⁓ I hate to give you a hard time about it, but I I feel like the incentive structure around open source, ⁓ and software in general, around supply chain security is just so in flux right now. ⁓ I mean, I'm sure you're familiar with all the bug bounty programs being canceled, curl being the most famous. ⁓ But there's a lot going on right now. ⁓ I I've written about it ⁓ for Red Monk at at great length. I I am following this closely. And so when you talk about burnout, a big part of the burnout that I'm hearing about, at least, relates to AI slop and these PRs that are coming in that take no time for an LLM to to get written. But then also ⁓ because of duplicate entries, but also just things that are not true, ⁓ you know, they they end up being this huge time suck. ⁓ because you have to look at them. They because they might be they might actually point out a zero day or something. ⁓ so yeah, ⁓ it's it's a big problem right now. but I know these are early days for the lab, so I'm sure you're gonna be grappling with all of these questions here. And I i I I if anything, I'm I'm excited. I mean, I think this is these are interesting things. And so having money to distribute is a g is a good problem to have. So I I I I want this for you. speaker-1: Thank you. So ⁓ I think you're absolutely right on the AI burnout stuff. So Miranda's working on a follow-up to her initial burnout report, which is on ⁓ AI and burnout and what the impact of AI has been on burnout among ⁓ open source maintainers. ⁓ you know, certainly from the security point of view, that's a very serious problem. But also just from a a mental health point of view, when it comes to using the tools, ⁓ it really makes me think sometimes about like, you know, why we make open source, right? Like there's I think there's a lot of good answers there. One answer is, you know, one thing that personally I care a lot about is I hope that the work that I do is going to help institutions that I rely on, like the UK's National Health Service that uses a lot of open source code, I hope to have some downstream impact on, you know, these very important services that I care about very much. But it's very easy for values that we have, even that we hold deeply, to sometimes get twisted into incentives that are are not always the best. So for example, one big thing in open source is esteem, right? Like there's a lot of esteem that goes to people that build really big, ⁓ widely used frameworks or maybe technically impressive things and so on. And I think that's great. But because esteem is so important in open source, I think it can lead people to chase that and have that be their incentive and say, okay, well now if I can use AI to build 10, 20, 30 projects or build, you know, any any kind of idea that I have that might become widely used, I have to build it now because maybe that will get me that kind of esteem or you know, relationship to other people or whatever. That's just one I'm, you know, not to say that that's the main thing, but I think there's all sorts of incentives like that that can become really difficult and can really lead to an almost obsessive engagement with the AI tools. And I'm worried about that. And I'm worried about, you know, people's. mental health in open source. And recently, Syntax, the ⁓ YouTube channel, posted this great video about ⁓ AI and burnout. And Scott from Syntax posted this ⁓ survey basically asking people about their experience with AI. And It's just very spooky to see how much AI usage affects people's mental health. I would recommend that video to people and I would also recommend looking for looking up for Miranda's ⁓ new report. But yeah, so I think that it's very tough, especially because this is it's it's not a new technology per se, but it's relatively new that people are engaging with it to this extent. And we just don't know what the best practices are in terms of how to relate to the technology, how to relate to each other using the technology. Like when I see people writing comments on GitHub or whatever with LLMs makes me very uncomfortable personally, just because I want I wanna get to know you guy that's commenting on my thing, right? Like I wanna understand where you're coming from and be friends and speak to you. So it's it's very difficult. And I think this is also why we really wanna work on this research and ⁓ Brand is doing excellent work and so is Scott. speaker-0: Yeah. I will absolutely provide links to those in the show notes. ⁓ yeah. Couldn't agree more. And I'm thinking of like the n the Node.js. ⁓ they they require folks to like jump into the Slack channel just to make a name for themselves so that folks know who they actually are. So or they did at least I I believe that's still how they're making sure that the the folks who are submitting issues are actually people and not just bots or yeah. ⁓ okay. Couldn't agree more. ⁓ So I I wanna hear about some of the other things that you are researching there. And one of the the cute-ish terms that that jumped out to me is the Bernies. Could you the Bernie's can you talk to us about what that is? speaker-1: Yeah, so this it's kind of a kind of a funny term. So this was coined by Andrew Nesbitt on his blog. It's based on a movie called Weekend at Bernie's. I haven't actually seen the movie. I think it's basically ⁓ s someone's boss, I think it is, or one of the characters in the movie dies, but you know, the people in the movie are incentivized to make it seem like he's still alive. So they basically like card him around in this chair and like make him look sort of alive. It's ⁓ kind of grim. But The idea there is there's an analogy to ⁓ open source projects, right? So there are projects that we rely on and they might seem to be active or maintained. You know, the the most trivial example is there's some automated, you know, dependabod thing or, you know, whatever. There's some CI that's ⁓ making small fixes to the project and, you know, keeping it going and and so on. And maybe there's gonna be ⁓ an issue that's looked at now and then or a pull request that's looked at now and then. But ⁓ What's really important there is let's say that I have Foolib as a important dependency for my project. And let's say that someone discovers a security issue in Foolib. There's a lot of talk about how easy it is to discover security issues nowadays and so on. But ⁓ I think a really difficult thing there is actually figuring out what to do after you've discovered the vulnerability. which is those quote unquote bernies, ⁓ those unmaintained or inactive projects, even though they might not be obviously inactive. There's no process there to handle those vulnerabilities, right? And so, you know, that really puts you in trouble when you're faced with this kind of security issue and there's no obvious solution. I mean, I, you know, there's, you know, you can fork the thing and and so on and so forth. But there's a lot of friction to actually having some kind of remediation there. And that's scary. Now, Andrew did a great analysis at the time of of one one of his many blog posts there. There's a lot of blog posts and, you know, a lot of excellent blog posts on Andrew's blog. He's a very regular poster. But ⁓ yeah, in one of the posts he did the sort of analysis at that point in time to figure out across these different critical ⁓ across these different ecosystems, looking at the critical packages within those ecosystems as ⁓ identified by you know number of downloads and dependencies and so on. what stuff appears to be unmaintained based on a variety of signals? It's a great analysis. There's one obvious limitation to that analysis, which is it's only current as of whenever he posted that blog post. So what I think would be really important would be to have again a kind of public benefit solution where we can monitor, hey, Foolib, hey guy who depends on Foolib, did you know that Foolib is is we're now detecting it as being a burning, as being unmaintained, as being end of life or you know, whatever set of criteria we want to apply. You might want to look into that proactively, not when you realize, you know, years later, whoa, like there's now a big issue and I need to migrate away from this thing. So That's exactly the kind of public benefit service that I would like to see because ultimately if this if these projects are critical infrastructure, you shouldn't have to pay to be able to get that kind of information, right? ⁓ that's my opinion. speaker-0: Okay. Thank you for that colorful definition of a Bernie. I love it. ⁓ I have seen the movie. It's been a while. But ⁓ yeah. Well, you know, ⁓ it and ⁓ it's slapstick, silly 80s whatever stuff. But it ⁓ I I think it just expresses the idea well and it's very memorable. I like I like you know, it's kind of cute too, but it strikes me as something that is deeply important. I love the idea of having an ongoing public good as a way to announce ⁓ when packages are not being maintained as they should. So I'm gonna ask you one last question and then we'll wrap up here. ⁓ talk to me about partners. So we obviously know you've got this wonderful board and that gives you some partnerships, some some connections, but are you working with any other big companies? I mean, we talked about the the idea of foundations. I mean that's such a big part of what they do is is try to create these coalitions. so ⁓ who who are you working with specifically in order to make the lab successful. speaker-1: Well, in terms of funding for the lab, so th there's there's a couple of things. First of all, in terms of just speaking to folks, there are a bunch of organizations that, you know, recently, for example, I had a great conversation with some people at AWS where they watched ⁓ a talk that I gave at FOSSEM and then a EuroPython this year about binary dependencies, and they said, Hey, that's a problem. We have That problem, but also more importantly, s ⁓ you know, some related issues in terms of first of all, the the binary dependency problem I describe with Python, but also with our Rust code, there's some limitations where because of the Rust dependency management system not easily being able to incorporate stuff that's external to Rust. In some situations, we're just downloading, you know, that we have packages where we use packages that download stuff, just some C code from the internet. Who knows where from? Compile it at build time, and you know, hopefully, and you know, we just use that ⁓ dynamic library. Hopefully, everything will be okay. So we certainly have conversations with companies like that. And you know, there's been a lot of folks that have been very helpful in, you know, because I'm very interested. Obviously, I know. the issues that I see. And, you know, internally, we know we have people that, you know, we have regular conversations about this stuff as part of the board. However, there's a lot of people, both in industry and in ⁓ open source, that have a lot of information that we don't have. So w there's a bunch of organizations that that we speak to in that respect. In terms of funding We don't have funding. So I've reached out, you know, I don't want to name organizations because I feel like a little bit bad like being on the podcast and we're like, look who didn't pay me despite using my thing. But there are a few organizations that have said, look, this is really important stuff. And when I reach out about funding, and y you know, they it's maybe yeah, I ⁓ I don't know the internal reasoning, but it's been very difficult ⁓ for them to come through with that. So speaker-0: So speaker-1: Again, like I said, right now, the stewardship lab has, you know, virtually no funding. There's a couple of people that you know donated like a hundred bucks on the open collective, which is very nice. And I'm very grateful for that. But ⁓ you know, we need serious funding to to build this stuff and I really think that's important because it's in first of all, it's in the public interest, and that is my number one concern. Secondly, it's just in the interest of those companies, right? Like These companies are saying, Hey, I don't want my dependency tree to break. Mm-hmm. And ⁓ yeah, we need this tooling. So yeah, it I'm we're we're all we're very open to collaboration at the lab. We're we also have sponsors sponsorship tiers where we w where ⁓ those sponsors can have regular meetings with our boards. And so we're very happy to hear what supply chain issues folks are struggling with and to incorporate that into the research. And ⁓ You know, if if you're listening and you you work at a company that is interested in this kind of work and would be able to sponsor us, ⁓ you can email me at Vlad at Vlad dot website. You can look at ⁓ our website at stewardshiplab dot org and we'd be very grateful for your feedback and for your support. speaker-0: That's fantastic. And I love that this has become a CTA because I mean I I I feel like this is a natural place for ⁓ you to be at right now. I mean, the lab was only founded what, a couple months ago? Okay. ⁓ starting those conversations. I mean, you know, things like the Linux Foundation, the CNCF, which kind of began from the ⁓ you know, these enterprise organizations in, you're kind of beginning with like, here are these problems that we see and and speaker-1: Yeah, yeah, pretty much. speaker-0: doing more of a grassroots motion from there. so yeah, I mean, ⁓ I don't know if you've talked with ⁓ folks like Aaron Schnabel at the Common House Foundation, but I know that that's a sort of move that they do as well, where the where they were a bunch of developers. They said, we think that we can do foundation work differently. So this is great. This is a needed thing. ⁓ And yes, hopefully there will be some folks who listen to this conversation and say, hey, you know, I this is something that's of interest to me. I'm gonna reach out and and see see about, you know, Ways that we can collaborate and work together, ⁓ and potentially throw you a couple of bucks. I like speaker-1: I would be I would be very grateful for it and yeah, our our team would be very grateful. speaker-0: All right, fantastic. So I will provide a link to ⁓ the lab in the show notes. ⁓ do you have any social media handles that you would wanna share for folks who wanna hear more about, you know, your personal blog posts or or things that you're doing at the lab from you personally? speaker-1: Yeah. So on Mastodon, I'm at Vlad at Vlad. website. On Blue Sky I am Vlad. website. And then the Storage Lab is ⁓ at Storage Lab at Fostodon.org on Mastodon and at Storage Lab.org on Blue Sky. ⁓ we post about our work but also developments in the ecosystem and the community there that I think are very interesting. And we also have a Discord server. If you go to Storage Lab.org, there's a link at the bottom for an invite. And there's actually a lot of really ⁓ experienced and and helpful people there talking about supply chain security in different ecosystems. We have folks from the Python community, from the JavaScript community, from the Rust community, and we have a a hashtag share channel there where people post news about open source sustainability generally. So if you want to join and just talk about what stuff you care about and let us know what problems you've been facing. If you're an open source maintainer that wants to talk about your experience with security or burnout or anything like that, we'd love to have you there. And yeah, there's a lot of great stories in there. And I'm really grateful ⁓ for everyone who joins. speaker-0: That is such a great way to wrap this up here. I love that. Okay, so lots of places to become connected, to follow up on all of this. ⁓ and again, I will ⁓ provide links so that folks have an easy way to get to them. So again, my ⁓ guest today has been Vlad. ⁓ my name is Kate Holterhoff. I'm a senior analyst at Red Monk. If you enjoyed this conversation, please like, subscribe, and review the Monkcast on your podcast platform of choice. If you're watching us on Red Monk's YouTube channel, please like, subscribe, and engage with us in the comments.