Episode 289: Courtney Miller on Maintainer Burnout and Software Abandonment ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fmedia24.fireside.fm%2Ffile%2Ffireside-images-2024%2Fpodcasts%2Fimages%2F2%2F27729c65-f4a6-4496-8c86-820e7f13b285%2Fcover.jpg%3Fv%3D6&w=512&h=512) šŸ”— **Source:** [Episode 289: Courtney Miller on Maintainer Burnout and Software Abandonment](https://share.snipd.com/episode/3546809b-e53d-4110-bb32-a8103c746bd0) ## Highlights - **Abandonment Defined And Dissertation Focus** - Abandonment means a project is no longer maintained and downstream users may keep relying on it unaware. - Courtney Miller framed her dissertation to study developer experiences, measure abandonment in npm, and design interventions like Abandabot. Transcript: Courtney Miller The title of my dissertation is Support the sustainable use of open source software. And what it focuses on is a shift in perspective. So the way that I got into this research is through open source sustainability, which focused on trying to prevent abandonment from happening and ensure ongoing maintenance on digital Infrastructure projects. But we realized that, hey, no matter how much we study this, abandonment still happens. And we need to figure out how to support users when they face it. So that's exactly what my dissertation was about. We started by talking to developers, trying to understand the challenges, measuring abandonment at scale, and then developing a tool to help improve the processes used in identifying Abandonment. ([TimeĀ 0:01:34](https://share.snipd.com/snip/7e3aee1f-b4b4-41c4-9ba3-102f39534066)) - **Maintainers Describe Winging It With Abandoned Dependencies** - Interviews with maintainers revealed they 'wing' responses to abandoned dependencies and lack tooling. - Developers described manual, ad-hoc identification and difficulty deciding how to respond to downstream breakage. Transcript: Courtney Miller Absolutely. So just in chronological order, in the first chapter of the three, that was, we feel like we're winging it. And that was a study where we spoke to open source maintainers of GitHub projects that relied on abandoned packages. And so we asked them about their concrete past experiences with it. And we identified several points in the dependency usage lifecycle where they experienced challenges. And through that study, we learned that a lot of times developers, as I kind of previously mentioned, struggle with identifying abandonment because often they use manual processes Because although there are wonderful software component analysis tools for other dependency management practices like updates and vulnerability patches, most widely used SCA Tools today don't actually help with abandonment. There are some tools in beta, but people didn't really have tooling support. They struggled with figuring out how to respond and figure out what are suitable alternatives. And so we kind of just unearthed all of these different challenges that people have with abandonment. ([TimeĀ 0:05:26](https://share.snipd.com/snip/7790ac4b-9070-40a6-b05b-f16e2a53c440)) - **15 Percent Of Widely Used npm Packages Were Abandoned** - In an npm ecosystem analysis, Courtney found ~15% of widely used packages experienced abandonment (2015–2020). - She used two heuristics: explicit notice (maintainer announcement) and activity-based inactivity to label abandonment. Transcript: Courtney Miller And so for that, in the second chapter, we did an ecosystem-wide analysis of package abandonment, specifically widely used packages, which we defined as packages that had at least 10,000 downloads in at least one month during our six-year observation window, which spanned from January of 2015 to December of 2020. And in that analysis, we started by first defining abandonment because as you mentioned earlier, there are lots of different types of abandonment. And actually there is no right answer to how to define abandonment. There is no one definition. So we did a bunch of iterative heuristic design to come up with two. And the two that we came up with were based on previous literature and our empirical findings. And it is first explicit notice abandonment, which is where the maintainers of a package publicly express their intent to no longer do so. So for example, that can be a note at the top of the readme, that can be flagging the packages archived in the NPM registry, things like that. The other type of abandonment we identified was called activity-based abandonment. This is commonly used as a way of identifying abandonment in open source sustainability literature, including some of my own previous work. And that's where we notice clear shift in activity patterns in a project from regular maintenance to an extended period of inactivity. And so we started by creating these definitions of abandonment. And then we looked at all the packages in the NPM ecosystem that were widely used at the time of analysis. And we identified which of them were abandoned using our heuristics. We collected a bunch of trace data and we analyzed it to figure out which of these are abandoned. And we identified that out of the widely used packages, about 15% of them had experienced abandonment during our observation window, which was surprisingly high percentage for me Personally. ([TimeĀ 0:06:41](https://share.snipd.com/snip/93fa3acb-e29b-4339-977c-2b52d0bdcddd)) - **Explicit Abandonment Prompts Downstream Action** - Downstream users seldom respond to abandonment unless maintainers explicitly announce quitting. - Explicit notice abandonment meaningfully increases the likelihood of downstream remediation. Transcript: Courtney Miller So then we wanted to understand how do downstream users respond and how widely impacted are they? And we learned that most exposed downstream users don't respond to abandonment. However, downstream response is significantly more likely when package maintainers explicitly announce that they're no longer going to maintain the package. So when packages are explicitly abandoned, it helps support downstream responses, which was a really, really big indicator. ([TimeĀ 0:09:03](https://share.snipd.com/snip/4db7a5de-4e91-448a-a24a-b65520b7e1a3)) - **Notify Only Dependencies That Will Impact Your Project** - Build targeted alerts not blanket notifications to avoid fatigue; predict which abandoned deps actually matter. - Courtney designed Abandabot to pre-configure notifications using theory-driven plus LLM classifiers to surface impactful dependencies only. Transcript: Courtney Miller And the pun was fully intended. So what we did in Designing Abandoned Bot is we knew that people struggled with identifying abandonment because it's a lot of a manual process. So we said, we're going to automate the process of identifying abandonment. But then there was this catch-22, where from a lot of our conversations with developers, we learned that for a lot of them, they don't actually care about the abandonment of all their Dependencies equally. So if we just did something like Dependabot does by default, where we notified them of all updates, this would very likely create a lot of notification fatigue and lead to a lot of the Key usability issues that limit the effectiveness of tools like Dependabot. And so what we wanted to do is try to figure out, can we create some sort of intelligent pre-configuration tooling that can predict for a given project, which of its dependencies would Be impactful and therefore noteworthy to their project if it were abandoned so that we could then know which ones to notify them of and which ones not. And what we learned is that using a combined theory-driven and LLM-based classifier approach, we were actually able to do a pretty good job at predicting which abandonment you're Going to care about and which you're not. ([TimeĀ 0:09:41](https://share.snipd.com/snip/4be66348-e250-4220-89c2-b7fa6ff535c8)) - **Move From Alerts To Automated Remediation** - Alerts alone are insufficient; tools must help remediate by suggesting migrations or automated patches. - Courtney recommends integrating abandonment detection with automated migration blueprints and alternative identification. Transcript: Courtney Miller I mean, like it's good to be aware, sure, but like developers are aware of a lot of things every single day. Some would argue way too many things. So just making them aware of it is kind of useless. The next step that needs to happen is a band of bot needs to help support automated remediation by providing project-specific blueprints of how people should respond. And this can mean synthesizing things like wisdom of the crowd migration patterns or identifying potential suitable alternatives and creating automated patches and things like This. ([TimeĀ 0:12:29](https://share.snipd.com/snip/860eefde-97dd-4ec4-883a-2749a93b399f)) - **Under Maintained Packages Are A Hidden Supply Chain Risk** - There's a gray area before abandonment: under-resourced or under-maintained projects pose supply-chain risks too. - Identifying and prioritizing stressed but not-yet-abandoned packages could prevent larger downstream failures. Transcript: Courtney Miller Is an issue, but there's also this like whole gray space before abandonment, which is where, you know, under-resourced projects lived and under-maintained projects live. And that is a serious, you know, supply chain security threat vector as well. It's not just fully abandoned packages. And so I think that you do bring up a really good point. And I think that, you know, I've seen some exciting work looking at exploring under-maintained packages and how to better support them. I think something similar to Abandonbot could be done for under-maintained packages. Design a heuristic to identify under-maintained projects. That would be a fun one. And then automate it at scale and identify, especially using dependency tree kind of stuff, you could identify which under-maintained packages are in stress points that would have High impact on the community and things like that. ([TimeĀ 0:13:51](https://share.snipd.com/snip/859ba5cf-4cd8-4232-9d4c-2ad4bf97618f)) - **Responsible Sunsetting Can Be Healthy For Ecosystems** - Abandonment isn't always bad; responsible sunsetting can enable healthy ecosystem transitions. - Courtney highlights maintainers can ease community resilience by announcing sunsetting and providing migration guidance. Transcript: Courtney Miller He's not wrong. And I'm really, really glad you brought this up because yes, you are absolutely right. My dissertation takes one particular lens, but it's a myopic one and it's not fully representative of the whole situation. On the exact same coin, there's another side, which is, you know, one thing that we've been thinking about a lot and something that my advisor Christian brought up early in my dissertation Is that not necessarily every abandoned project is a bad thing. Sometimes things have to die. You know, it would make sense to think about where should we be focusing our resources instead of trying to keep more things alive. And so I think that that is a very valid perspective. And one thing that we've been thinking about a lot, and that I am very excited to research as well, is looking at responsible sunsetting. Sometimes it is the right choice for a project to be no longer maintained, but that doesn't mean it has to be a bad thing. And there's things that maintainers of projects can do to make it so that the abandonment is not so bad and that it's easier to respond to from the community. ([TimeĀ 0:16:03](https://share.snipd.com/snip/c730e3d4-8c00-40c9-b811-490456fef7f8)) - **LLMs Enabled Practical Impact Predictions For Abandonment** - Courtney used a RAG + LLM approach to predict impact using four theory-driven factors. - The factors were depth of integration, availability of alternatives, external evolutionary pressures, and importance of functionality. Transcript: Courtney Miller And frankly, we wouldn't have been able to have built a band of bot, especially in the timeframe we did without it. And so it was kind of a thing where at the time when we started, we had no idea how to use it, but we figured it out. And the way that we used it at a high level is essentially, so we developed the theoretical understanding of what factors make packages abandonment impactful to a downstream project. And we identified these four factors, which were the depth of integration. So how deeply embedded in the code base is it, the availability of alternatives, external evolutionary pressures, and importance of the functionality being utilized. And so we had these factors and we were great. So if we can figure out how to measure these factors and analyze them for a given project, then we can make a prediction about whether we think that this package's abandonment will be Impactful or not. And the question just became super cute, but how the heck are you actually going to do that? And we could go with the traditional approach where, right, we start with the same way, developing our theoretical understanding, operationalizing the factors into these metrics, Collecting data at scale, training a conventional machine learning model. But that would have taken probably three years and would have been extremely difficult, especially because we're talking about nuanced context-specific factors. So what we ended up doing instead is using a RAG-based approach to using feeding an LLM-specific context information based on our theoretical understanding, as well as a theory-driven Structured reasoning prompt that had it do train of thought reasoning for each of our factors followed by meta-reasoning synthesis step where it made the ultimate prediction of yes Or no this package's abandonment will be impactful to this project or not and then we used a combination of static analysis and just good old-fashioned github api data scraping to develop The context that we fed in and then the llmLM followed the task, made the predictions. We did an independent user study to evaluate its effectiveness and found that the majority of the time downstream users agree with the predictions about whether a given package will Be impactful to their specific project or not. ([TimeĀ 0:18:26](https://share.snipd.com/snip/2fd0eb02-df56-4b1f-8df4-265cde59d7d7)) - **GenAI Both Helps And Harms Open Source Sustainability** - Generative AI could both reduce and worsen abandonment: it can automate maintenance or flood projects with low-quality contributions. - AI slop drives governance changes that may inadvertently raise maintainer burnout and reduce newcomer paths. Transcript: Courtney Miller And so I have a discussion section in my dissertation where I talk a little bit about how I think that it could potentially help make abandonment better. For example, it could help automate package maintenance. It could automate dependency migration when packages are abandoned. Maybe projects never have to die. You can just create a fork and maintain it on your own. And so I think that there's a lot of potential ways that it could help support and especially kind of the user focused approach to abandonment that's kind of advocated for in my dissertation. We're more empowering users to figure out how they can respond effectively instead of trying to prevent the abandonment from happening. But on the other side of the same coin, there are ways that Gen.AI could make abandonment worse. And a lot of those have to do with overwhelming developers with a bunch of AI slop, or in other words, low quality submissions that are Gen.AI. And it is a really, really big problem in the community. And a lot of projects are having to resort to things like creating new governance rules, shutting projects to external contributions. And it is a little bit tough because those things for some appear to be effective-term remediation strategies, right, to deal with the flood. But the problem is doing those things can impact the long-term sustainability of these actual projects. And so we're talking about the core digital infrastructure that we all rely on that's already classically strained. That's what my entire dissertation was on pre-GNAI. And now we have this entire other giant tsunami putting a huge amount of pressure on it. And so it's creating exacerbated situations that are making abandonment a lot more prevalent, a lot more difficult to deal with. ([TimeĀ 0:21:19](https://share.snipd.com/snip/c8fa2aa8-29cf-4e2f-be9d-16d4fa9a55a9)) - **Add Abandonment To Software Composition Analysis Tools** - Incorporate abandonment detection into SCA tools now so downstream users can manage dependency risk. - Courtney urges toolmakers to adopt abandonment heuristics and integrate remediation support into existing workflows. Transcript: Courtney Miller Yes, I think that abandonment is something that kind of needs to be addressed now. It should be incorporated into SCA tools, tool makers. I think it's really important for the technology to catch up. It's there. Let's figure it out. Call me. But I think that it's just really important to be addressed right now because there's also a lot of other things that we need to do. ([TimeĀ 0:26:42](https://share.snipd.com/snip/23b19aea-d4bf-41b6-a420-2ed091f69fea))