The Maintainer's Dilemma
18 points by telemachus
18 points by telemachus
I've always wondered, for personal projects where (1) there are a lot of downstream things depending on your code and (2) the maintainer doesn't have time to review PRs, why do people not feel comfortable with posting a brief notice in the README to the tune of "I don't have bandwidth to review patches. If you'd like to make changes to the code, please fork it and make your improvements there."
People are creating PRs (and hence you're feeling some guilt on not attending to them) because the assumption is that you'll review the PR/merge it. Now, one can debate whether that assumption is "justified" or "appropriate". But regardless of that, communicating boundaries clearly (instead of it being implicit where the contributor has to judge this based on recent PR review history etc.) seems like a win-win for both the busy maintainer and the hopeful contributor.
why do people not feel comfortable
There is a gulf between intention and reality. Many people WISH someone would contribute to their thing. But what they really wish is that someone with their same taste, preference, style, and values would do work AS THEY WOULD for them. Then when faced with imperfect work from an imperfect clone of themselves they have no experience (or possibly interest) in empathizing with this person to coach them to get a sub-par result to what they could do easier directly.
Most have never had that experience so can't emulate it to pass it on or pay it forward. They want community, they want code contributions, but when reality meets intentions they don't know how to productively face conflict and so it's easier to just ghost.
(Not everyone but some)
Forking and running with that long term is a lot of work too. Less if it's only internal. (Company fork of aws-vault took only some cleanup, packaging, communication - maybe 2 days for me) A lot more if you then want to fork and improve a dependency in some large project. For example I'm dealing with https://github.com/NixOS/nixpkgs/issues/512622 which effectively requires forking a project that Facebook archived 7 years ago and transferring ownership of a project which was effectively dead for a few years too. It took a month so far and I suspect will require another 1-2 even if the forks/PRs are already in place.
It's a lot less work for everyone if changes land in the original and maintained repository.
Sure, I'm not saying that it's less work overall to fork. I'm saying that, if you need some changes for your work, you will probably fork anyway, because you don't want work-related stuff to be blocked on whether an upstream maintainer accepts your patch or not.
In that case, if the maintainer has written down that they're not reviewing patches, that saves you time because you don't keep trying to upstream the patch/ping the maintainer every N weeks for code review.
I turned Jules loose and watched email after email arrive with new PRs. Looked promising. Then I went on a cruise.... Jules kept going ... By the time I got home, I had over 120 PRs across the two projects.
So the author initiated the LLM and it went all Sorcerer's Apprentice on him. First order of business, stop Jules.
Jules also created these PRs as me, not as Jules — which raises its own questions about attribution and accountability.
In once sense, no, he started Jules as his agent, so accountability ultimately goes to the author. The buck stops with him, as Jules was a tool started by human agency. That Jules attributed the PR to the author might be a tool issue with Jules, depending if the tool should get the attribution, or the author (I'm of the opinion that the tool should get the attribution as it makes it clear how the PR was generated).
The PRs themselves weren’t wrong, Jules had found real issues. But none were quite right either; each needed course correction before I could merge. With guidance Jules made the adjustments,
This bugs me the most about the post. If the author started Jules, and Jules found a real issue but the PR wasn't quite right, just close the PR and fix it manually if you know what it fixes. Don't spend the more time going back and forth with it as that wastes time, and Jules won't care at all. If someone else sent an LLM to generate PRs (as recently happened to me), that's a separate issue (and one which I'm inclined to wish that Github had a “dismiss with prejudice” button, but that's me).
The rest of the post waxes philosophically about the implications of LLM generated PRs swamping the maintainers and how do they respond to such an onslaught. Me? If I were to get a ton of LLM-generated PRs, I'd close without merging sans hesitation.
In once sense, no, he started Jules as his agent, so accountability ultimately goes to the author.
I don't think we can have the same black and white level of code ownership anymore. I wish I could explicitly tag my commits/PRs with either of:
Otherwise my commits in a project which is made for unsupervised automation look the same as ones I actually spend a lot of time on. Neither me nor the maintainers are happy with that.
ownership anyone.
Do you mean "anymore" here?
And can't you instruct the LLM to include itself on PRs?
Yes and no. The only things common enough to surface in the UI at the moment are the "commiter" and the "co-authored-by" trailer. And neither of them communicate what really happened any more than "edited in Cursor" would tell you. We really need more context.
This is a really good, thoughtful article.
I eventually chose to walk away from my programming language Wren because I didn't have the time to stay on top of the issues and PRs coming in. I felt like I was constantly letting people down and the stress sucked most of the joy out of it for me. This is not on those contributors at all. Everyone who filed an issue or sent a PR was uniformly kind and well intentioned. It was just more social load than I could handle (especially as someone who already carries around a lot of social anxiety).
For my hobby game, I ended up adding a section to the README that says the game is open source but not open contribution. For me, for that project, I think that's the right call. I like sharing things with people, but for a hobby project, I don't want to sign up to be on anyone else's timetable. Don't get me wrong, I love community projects and collaborating with people. But that requires a certain amount of temporal commitment that is hard to find these days.
AI is obviously exacerbating this load because it's so much easier for people to send out contributions but not really much easier for a maintainer to absorb them.
The current open source social norms were evolved at a time where the needs of software were growing very rapidly (the web, web 2.0, etc.) but the ability to create code was in short supply. So we created a culture that optimizes for extracting as much software engineering effort out of any potential contributor as possible. Projects risked dying of starvation otherwise as requirements changed faster than maintainers could keep up.
But with AI, there is now a risk of dying from bloat and obesity and projects fill with unvetted code, unknown bugs, scope creep, and unclear design coherence. In that world, we need different norms.
I wonder if an "open source, closed contribution" model is a better fit. Anyone can access and use the code. But contributions are closed to a known set of pre-approved contributors. Adding to that set is done slowly and deliberately to ensure the project is capable of keeping up with their contributions. Of course, this has to be done well to avoid problems with gatekeeping.
I don't know what the right model for an issue tracker is. Maybe different policies for bugs versus feature requests. For bugs, you definitely want to know about them and you want the barrier for people(/bots) filing issues to be low. For feature requests, it can be a real tax for maintainers to have to wade through the thousands of works of Markdown that an LLM is happy to spit out for a design proposal only to discover hours later that the whole idea is misguided.
A response from an AI in a day might be more respectful than silence from a human forever.
Nah, I would have preferred to not read this blog post at all. Next time, please consider just not prompting when it's time to blog.
Going on a cruise and have an agent create 120 PRs while you are sipping cocktails on the deck is not really normal useage of these tools .. just sayin'
Why is this article so long?