The problem is that the last part changed drastically with LLMs. You can get a lot of solutions easily by prompting an LLM. But that also means you don't need outside PRs for that anymore, and just prompt the LLM yourself.
That means two things in my opinion:
1) People haven't internalized that yet. For a lot of people, a functioning solution to a problem with often quite a bit of source code is equivalent to "adding value" - because in the past it was. It meant you thought about the problem, understood it and found a solution. But it was that thinking that added the value.
2) The minimum threshold for adding this "quality" rises quite a bit. A lot of problems can now be solved very fast with an LLM by someone who understands the code base well enough. You don't need a PR for that.
I suspect, that means in the future you could both get and need less contributions to OSS projects in general.
We'll see
In LLM-friendly repositories it saves everyone's time if the maintainers are the ones steering the machines, and in LLM-unfriendly ones it saves everyone's time by not having generated PRs thrown at the maintainers.
No, I don't think that is true. Anyone who used LLMs in greater degree (e.g. at work) knows for a fact that the output and therefore the end result work heavily depends on the human involved, and their thought process. Of course for anything that isn't completely trivial.
That's what issue trackers are meant to capture.
I could see maintainers wanting to take sole control over the code, and rather than swatting down PRs they can just guide AI to fix reported issues themselves, and merge what they approve of. Cut out the middle men.
Some of that. Also sometimes there isn't even a person, just a bot opening a pull request that doesn't hear feedback.
There's also the problem that many projects put disproportionate effort into mentoring new contributors and helping them get things right, and that's valuable when there's a human learning something, but not when you're just correcting someone's LLM slop.
And that's leaving aside all the other problems, like "these things took all our FOSS code, ignoring its licenses, and then used it to compete with us and drown us out", or "these things are going to turn us all into paperclips".
> (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
This is naive, these projects do not have years or even months to wait, nor will it die down.
Due to attackers using swarms of abliterated models at even 1,000 TPS, these projects can be easily targeted to find vulnerabilities that these AI models can also build exploits for them.
These open source projects have no choice but to defend themselves with AI to quickly patch these bugs before the attackers find them.
They can work at any pace they like, and you have the choice of using or not using them. The software is provided as-is.
I expect the problem isn’t necessarily the AI generation itself, but the difficulty to distinguish between someone that’s really understood the problem domain versus someone with LLM-induced “Dutch courage”.
That in combination with a large uptick in volume of community interactions (issues, PRs, …) risks burning out OSS maintainers.
Perhaps giving it a few months/years for the flurry to die down, and for people to establish better best-practices for using these tools is the motive.