I don't want your PRs anymore
dpc.pw
dpc.pw
As the maintainer of ghidra-delinker-extension, whenever I get a non-trivial PR (like adding an object file format or ISA analyzer) I'm happy that it happens. It also means that I get to install a toolchain, maybe learn how to use it (MSVC...), figure out all of the nonsense and undocumented bullshit in it (COFF...), write byte-perfect roundtrip parser/serializer plus tests inside binary-file-toolkit if necessary, prepare golden Ghidra databases, write the unit tests for them, make sure that the delinked stuff when relinked actually works, have it pass my standards quality plus the linter and have a clean Git history.
I usually find it easier to take their branch, do all of that work myself (attributing authorship to commits whenever appropriate), push it to the master branch and close the PR than puppeteering someone halfway across the globe through GitHub comments into doing all of that for me.
Conversely, at work I implemented support for PKCS#7 certificate chains inside of Mbed-TLS and diligently submitted PRs upstream. They were correct, commented, documented, tested, everything was spotless to the implicit admission of one of the developers. It's still open today (with merge conflicts naturally) and there are like five open PRs for the exact same feature.
When I see this, I'm not going to insist, I'll move on to my next Jira task.
While I understand the sentiment I am glad I got into open source more than fifteen years ago, because it was maintainers “puppeteering” me that taught me a lot of the different processes involved in each project that would be hard to learn by myself later.
Most of my PRs are things where I'm not really interested in learning the ins and outs of the project I'm submitting to; I've just run into an issue that I needed fixed, so I fixed it[1], but it's better if it's fixed upstream. I'll submit my fix as a PR, and if it needs formatting/styling/whatevs, it'll probably be less hassle if upstream tweaks it to fit. I'm not looking to be a regular contributor, I just want to fix things. Personally, I don't even care about having my name on the fix.
Now, if I start pushing a lot of PRs, maybe it's worth the effort to get me onto the page stylewise. But, I don't usually end up pushing a lot of PRs on any one project.
[1] Usually, I can have my problem fixed much sooner if I fix it, than if I open a bug report and hope the maintainer will fix it.
My most negative experiences with free and open source contributions have been like that. The one maintainer who engaged with me until my patches got into master was the best experience I ever had contributing to open source software to this day.
Pretty sad that people see engaging with other developers as "puppeteering someone halfway across the globe through GitHub comments"...
But ghidra-delinker-extension's domain is unusually exacting. Mistakes or shortcuts there will cause undefined behavior of the exotic kind that can be exceedingly difficult to troubleshoot. The only way I've found to keep things from imploding is through unusually exacting quality standards that a drive-by contributor (who usually only cares about a particular ISA/object file combination on a given platform) can't be expected to match.
To be clear, I don't go silent when I receive a PR for this project. In those cases, I do engage with the contributor and give high-level feedback. But my spare time is finite and so is the other person's willingness to jump through all of my hoops.
The PR system is great for reviewing changes within a dev team.
But, indeed, when its an external contribution, it kind of falls apart. It's unrealistic to expect from an external contributor, often a one time one, to know the ins and outs of a project (code standards, naming tastes, documentation, tests, ...)
I really like your workflow, and often did something similar in my projects (or merge in main, with subsequent fixes/realignments).
But I'm wondering if it could be smoothed out and normalized by Github/Gitlab/Forgeo, or maybe at the version control software level.
I know when I run into bugs in a project I depend on, I'll usually run it down and fix it myself, because I need it fixed. Writing it up the bug along with the PR and sending it back to the maintainer feels like common courtesy. And if it gets merged in, I don't need to fork/apply patches when I update. Win-win, I'd say.
But if maintainers don't want to take PR's, that's cool, too. I can appreciate that it's sometimes easier to just do it yourself.
So you can still contribute, you just not need to provide the code, just the issue.
Which isn't as bad as it sounds, it kind of feels bad to rewrite somebody's code right away when it is theoretically correct, but opinionated codebases seem to work very well if the maintainer opinions are sane.
PS The economics of software haven't really changed, its just that people (executives) wish they have changed. They misunderstood the economics of software before LLMs and they misunderstand the economics of software now.
PPS The only people that LLMs benefit are the segment of devs who are lazy.
Conversely, if there's a supply chain attack in a library it's not being immediately spread to thousands of production servers.
But i feel like it was always true that patches from the internet at large were largely more trouble then they were worth most of the time. The reason people accept them is not for the sake of the patch itself but because that is how you get new contributors who eventually become useful.
When you actually work alongside people and everyone builds a similar mental model of the codebase then communication between humans is far more effective than LLMs.
For random contributions then this doesn’t apply
Oh god, I needed to add a feature to an open source project (kind of a freemium project) about fifteen years ago. I had no experience with professional software development nor did I have any understanding of pull requests. I sent one over after explaining what I was trying to do and that I thought it would be a good feature for the project.
Now they probably shouldn’t have just blindly merged it, but they did, and it really made a mess.
Learned a valuable lesson that day haha.
if they merge something blindly, then it's really on them if it makes a mess.
Meanwhile I was tinkering with the schema in the database and messing about deep in the guts of the software. I didn't really know how to separate the two so I just shipped the whole PR thinking they would just run it on the side to demo the thing I was talking to them about.
Well they just deployed it to their production instance and fucked everything up on their end.
I recall being horrified when I was tinkering with their customer-facing instance and seeing evidence of the other work I was doing. I immediately emailed them and said whoa whoa whoa. xD
Found the email that I sent to the founder, from 2014:
>It looked like <redacted> may have got a few surprises in the code she merged from the 2.1M1br branch yesterday. I've just been committing basically all the tinkering i do to that branch, so it may have a few landmines in it.
>Hope i didn't create any headaches for anyone. Sorry!
I've been sitting with this post for a bit and something about the framing keeps bugging me.
I keep coming back to one question: are you planning to add Co-authored-by trailers to these commits?
The pitch is: don't send me code, send me the prompt you used to produce it. And on the surface that sounds like a lighter ask — a prompt is a small thing, one sentence maybe, versus a whole diff. But that's the sleight of hand. The prompt that produced a working patch is almost never one prompt. My PR is the compressed output of all of that work.
So "just send me the prompt" is doing two things at once. It's reframing the contributor's work as a small artifact (one prompt, how hard could that be), and it's reassigning the result of that work to whoever re-runs it. If I send you the actual thing that produced the patch — the whole transcript, the rejected attempts, the corrections — that's not a smaller contribution than a PR, it's a more complete one. And you're going to land the commit under your name.
This is the same shape of argument the model labs made about training data. Individual contribution is "too insignificant" to be worth crediting, but the aggregate is valuable and belongs to whoever assembled it. I don't love it there and I don't love it here.
The other thing I keep thinking about: to anyone who hasn't used these tools seriously, an engineer landing a high volume of clean commits under their own name looks like a very productive author. That gap between how it looks and what's actually happening is going to close eventually, but in the meantime it's a real incentive to set things up this way.
None of this is an argument against the workflow. Review is expensive, untrusted code is risky, I get it. I just want to make an argument for Co-authored-by being part of the deal.
This is similar to what we’ve started to do at work. The first stage of reviewing a PR is getting agreement on the spec. Writing and reviewing the code is almost the trivial part.
Past month or so I implemented a project from scratch that would've taken me many months without a LLM.
I iterated at my own pace, I know how things are built, it's a foundation I can build on.
I've had a lot more trouble reviewing similarly sized PRs (some implementing the same feature) on other projects I maintain. I made a huge effort to properly review and accept a smaller one because the contributor went the extra mile, and made every possible effort to make things easier on us. I rejected outright - and noisily - all the low effort PRs. I voted to accept one that I couldn't in good faith say I thoroughly reviewed, because it's from another maintainer that I trust will be around to pick up the pieces if anything breaks.
So, yeah. If I don't know and trust you already, please don't send me your LLM generated PR. I'd much rather start with a spec, a bug, a failing test that we agree should fail, and (if needed) generate the code myself.
95% of this is covered by a warning that says "I won't merge any PR that a) does not pass linting (configured to my liking) and b) introduces extra deps"
> With LLMs, it's easier for me to get my own LLM to make the change and then review it myself.
So this person is passing on free labour and instead prefers a BDFL schema, possibly supported by a code assistant they likely have to pay for. All for a supposed risk of malice?
I don't know. I never worked on a large (and/or widely adopted) open-source codebase. But I am afraid we would've never had Linux under this mindset.
I find myself doing the same, nowadays I want bug reports and feature requests, not PRs. If the feature fits in with my product vision, I implement and release it quickly. The code itself has little value, in this case.
Maybe I'm not up to date with the bleeding edge of linters, but I've never seen one that adequately flags
let out = []
for(let x of arr){
if(x > 3){
out.append(x + 5)
}
}
let out = arr
.filter(x => x > 3)
.map(x => x + 3)
It feels like a lot of people assume a sense of entitlement because one platform vendor settled on a specific usage pattern early on.
This might be controversial, but we need more Stallmans; that is, people who care about the ethical implications of tech, and not just the tech.
Vulnerability detection might prove to be an issue though. If we suddenly have a proliferation of large quantities of duplicate code in disparate projects detection and coordinated disclosure become much more difficult.
If it’s "take it home OSS" and "there is not much need to submit PRs or issues" then why would anybody submit PRs and issues for "for critical bugs or security fixes"? If they have fix and it works for them, they’re fine, afterall.
And while we’re at it, why would anybody share anything? It’s just too much hassle. People will either complain or don’t bother at all.
I think that after few years, when LLM coding would be an old boring thing everybody’s used to and people will learn few hard lessons because of not sharing, we’ll come to some new form of software collaboration because it’s more effective than thinking me and LLM are better than me and LLM and thousands or millions people and LLMs.
Why do they do that at present? There are plenty of cases where it's a hassle but people still do it, presumably out of a sense of common decency.
Another self-serving reason is so that you can upgrade in the future without having to worry about continually pulling your own private patch set forward.
More often than not, LLMs fixes an issue as a downstream user. So there's even less pressure to fix the issue. Because if library A does not work on Windows, it would just use mash together library B and C and something from itself to fix the work around it.
Before LLMs, it was cheaper in the long run; by upstreaming your patches you don't have to rebase them continually and sometimes the community will maintain the code for you. OTOH sometimes you might need to work on the code again though as other parts of the project evolve if the project is likely to throw out unmaintained code; this is especially true in the Linux kernel where internal APIs change constantly, but upstream maintenance is probably cheaper than continually backporting security fixes to your stable/LTS/SLTS or completely dead versions.
With LLMs the costs might be different but will still exist.
By the end, the project manager begged me to turn off my flamethrower, as I was ripping it all out for a clean west manifest to tagged versions and stacks of patches. "Take it home OSS" is like take-out food: if you don't do your chores and leave it out for months or years on the kitchen counter, the next person to enter the apartment is going to puke.
Zephyr-based project?
But our modern embedded firmware projects all use Zephyr and west, so I just created a west manifest, stole parts of the scripts/ folder from the Zephyr repository to have a working "west patch" command and went to town. If I had more time to work on it, I'd have gotten "west build", "west flash" and "west debug" working too (probably with bespoke implementations) and removed the cargo cult shell scripts.
You can use west without Zephyr, it's just that by itself it only provides "west init" and "west update".
I have mixed feelings about west in general, but I like it enough that I'd probably look at doing something like that in the future too for harmony-sake with our existing Zephyr projects.
Now… especially for critical functionality/shared plumbing, I’m going to be writing a Markdown spec for it and I’m going to be getting Claude or Codex to do review it with me before I pass it around to the team. I’m going to miss details that the LLM is going to catch. The LLM is going to miss details that I’m going to catch. Together, after a few iterations, we end up with a rock solid plan, complete with incremental implementation phases that either I or an LLM can execute on in bite-sized chunks and review.
"AI sucks at most peoples' jobs. If you think AI is good at something, chances are you suck at it too."
Even if they worked, it would be easier for the maintainer to just do that themselves rather than review and communicate with someone else to resolve issues.
Delaying what?
If the maintainer authors every PR they don’t have to waste time talking with other people about their PR.
That's a unicorn.
If I'm lucky, I get a "It doesn't work." After several back-and-forths, I might get "It isn't displaying the image."
I am still in the middle of one of these, right now. Since the user is in Australia, and we're using email, it is a slow process. There's something weird with his phone. That doesn't mean that I can't/won't fix it (I want to, even if it isn't my fault. I can usually do a workaround). It's just really, really difficult to get that kind of information from a nontechnical user, who is a bit "scattered," anyway.
I know my code base(s) well. I also have agentic tools, and so do you. While people using their tokens is maybe nice from a $$ POV, it's really not necessary. Because I'll just have to review the whole thing (myself as well as by agent).
Weird world we live in now.
It wasn't popular but I think it will hold: https://essays.johnloeber.com/p/31-open-source-software-in-t...
This is just a change in position of what work is useful for others to do.
Code formatting is easy to solve. You write linting tests, and if they fail the PR is rejected. Code structure is a bit tricker. You can enforce things like cyclomatic complexity, but module layout is harder.
0: I liked BurntSushi's Rust projects since they are super easy to edit because they're well architected and fast by default. Easy to write in.
How do you like Helix as a starting point? Currently, I'm having Claude write a little personal text editor with CodeEditTextView as a starting point and now that I saw your comment I suddenly realized I mostly like using a modal editor and only didn't do it here because I'm moving from a webpage (where Vimium style stuff never appealed to me). Good hint that. I wonder if neovim's server mode will be helpful to me.
For the same reason a PR can be useful even if it turns out to be imperfect. Because it reduces the workload for the maintainer to implement a given feature.
Obviously that means that if it looks likely to be a net negative the maintainer isn't going to want it.
> It's increasingly apparent that "the source code" is less "source" and more "code"
(How) does this affect the GPL and what it defines as "source code" (the preferred means of modification to a program)?
If people will no longer contribute to the source code directly, this means fewer people will be familiar with the code, meaning that:
- The bus factor becomes more significant. (Yes, this could partly be addressed by LLMs. But if the single maintainer disappears, this will still cause disruption until someone else takes over/forks the project.)
- Fewer people eye-ball the code for security issues (and for malicious changes by the maintainer). This, too, could be addressed by LLMs but are we all going to set up agents in the future that review all our 3rd-party dependencies' code?
Also, at the point they actively don’t want collaboration, why do open source at all?
Strange times, these.
Collaboration is a common pattern in larger projects but is uncommon in general
Nowadays with genAI my powers to solve bugs and add features have unhyperbolically 100x'ed.
I guess my point being that it's become pretty easy to convert back and forth between code and specs these days, so it's all kind of the same to me. The PR at least has the benefit of offering one possible concrete implementation that can be evaluated for pros and cons and may also expose unforeseen gotchas.
Of course it is the maintainer's right to decide how they want to receive and respond to community feedback, though.
Sometimes I'm not a fan of the change in its entirety and want to do something different but along the same lines. It would be faster for me to point the agent at the PR and tell it "Implement these changes but with these alterations..." and iterate with it myself. I find the back and forth in pull requests to be overly tiresome.
The fact-of-life journaling about the flood of code, the observation that he can just re-prompt his own LLM to implement the same feature or optimization
all of this would have just been controversial pontificating 3 months ago, let alone in the last year or even two years. But all of a sudden enough people are using agentic coding tools - many having skipped the autocomplete AI coders of yesteryear entirely - that we can have this conversation
1 year ago Claude Code was relatively new, and a first polished tool that really fitted my CLI-centeric dev-views. I used Aider before, but Claude Code was just much better. The autocomplete AI coders did not seem useful, and didn't have good integrations with Helix text editor. However even the frontier models were relatively bad in practice. Useful but not trustworthy at all. Being wrong/stupid 5-10% of the time compounds quickly.
6 months ago agents became really robust at just writing code they were told to write. Around that time I started really leaning into LLM-assisted coding, which require some skill, experience and adapting own workflows and tooling. And it takes time and effort.
Right now frontier models are really productive and robust. Sure it's still a fancy-autocomplete under the hood, so one needs to plan around that, but it's more common for Slopus finds bugs in my old human-written code, than I find bugs in its new code, especially that one can now easily write and maintain tons of tests which otherwise would never get done. LLMs don't have context and good judgment, so it still takes a lot of designing and steering the agent to write the right thing, but that's OK. And as the productivity bottleneck shifted very heavily from writing code to all other thing around it, it makes it very apparent that it's not that the clanker now that needs to get better, but the process around it.
As a sidenote: what's with the usage of "take" to designate an opinion instead of the word "opinion" or "view"?
To your side note: "take" is a very common synonym for "thought"/"opinion"/"view" in the version (dialect? I guess?) of English I grew up with. If you're unfamiliar with it, that might be a regional or generational effect. I don't know. I'm not a linguist.
Somehow it's not really happening.
Repo, for those interested: https://github.com/jaggederest/pronghorn/
I find that the core issues really revolve around the audience - getting it good enough that I can use it for my own purposes, where I know the bugs and issues and understand how to use it, on the specific hardware, is fabulous. Getting it from there to "anyone with relatively low technical knowledge beyond the ability to set up home assistant", and "compatible with all the various RPi/smallboard computers" is a pretty enormous amount of work. So I suspect we'll see a lot of "homemade" software that is definitely not salable, but is definitely valuable and useful for the individual.
I hope, over the long to medium term, that these sorts of things will converge in an "rising tide lifts all boats" way so that the ecosystem is healthier and more vibrant, but I worry that what we may see is a resurgence of shovelware.
The JavaScript ecosystem is a good demonstration of a platform that is encumbered with layers that can only ever perform the abilities provivded by the underlying platform while adding additional interfaces that, while easier for some to use, frequently provide a lot of functionality a program might not need.
Adding features as a superset of a specification allows compatibility between users of a base specification, failure to interoperate would require violating the base spec, and then they are just making a different thing.
Bugs are still bugs, whether a human or AI made them, or fixed them. Let's just address those as we find them.
That workload of maintaining a fork doesn't come from nowhere, it's just a workload someone else would have to do before the fork occured.
Give me ideas. Report bugs. Request features. I never wanted your code in the first place.
Most git hosting providers allow maintainer to checkout a PR, commit changes to it, and merge with co-authoring. Might be a good workflow in this case.
PRs, at the very least, provide a quality gate. You have to a) express the idea in runnable code and b) pass the tests.
Thank your contributor; then, use the PR - and the time you’d have spent reviewing it- to guide a reimplementation.
Submitters use LLMs to generate the code and reviewers use LLMs to review it.
This just like my favorite, “We can use LLMs to write the code and write the tests.”
You’ll have a job for years to come :)