Part of this is an alignment problem, but on the human side: the bottleneck is no longer writing code but staying aligned with it, knowing what it does and whether it does what you meant. In my own work, that’s now most of the job, even for code I asked for. For maintainers reviewing large PRs from strangers, it's certainly much worse. A ban is bit harsh, but I understand why they’re rationing their attention.
I think this is the end of open-contributions, the maintainers already having too much on their plate.
Plus it is becoming exceedingly rare of finding a contributor that save time, as in can do better than the maintainer itself using LLM and reviewing it itself.
My experience lately is the best way to contribute to open source now is to just write detailed issues. The maintainer can then paste them in to an AI tool themselves and go back and forth faster than they could comment feedback to you and wait for changes.
if someone wants to contribute, they need to prove they produce value to the project. I dont think this is controversial at all.
The fact of being open source means if your contributions are rejected, you simply need to fork. The open market competition will soon determine if your contributions were truly valuable and whether the original project's owner misjudged, or that contribution was essentially worthless.
I agree with fellow commenter, now with LLM the forks will NOT been distinguished as much by their technical differences/features as their trustworthiness (which is already the case today, but tomorrow will be skewed even more). Massively increasing inertia and favouring initial/well-known work/founder/team.
> That's not entirely true: my work might get zero traction because nobody will know about it.
Being able to market your work and build community are key skills for open source contribution. The history of forges is littered with interesting code that never got enough attention to go anywhere.
It can still work. For example if you look at https://github.com/emdash-cms/emdash/issues they have a whole bunch of tooling that uses AI to automatically triage and come up with PRs automatically.
It's the end of open-contributions for one specific repository, that is all.
It only covers QGIS, the UI application, not GDAL/GEOS and the other libraries that give it its functionality.
Additionally, in the past few years the number and popularity of new open-source projects that do accept open contributions far exceeds the few old ones that do not.
Expanding on that, the issue is aggravating the maintainers bottleneck, because how do you find new maintainers if you do not accept outside contributions?
Another option would be to make a contributor pay for the review of its PR, even a small fee, to deter AI-slop, at least for new contributors. It could/would exclude students or people with the lowest wage though, but I'm optimistic even a 1$ bill or less would be enough.
I'm purely focusing on the effectiveness of the measure keeping the open-source ecosystem alive, not discussing much about fairness.
The current contributors are already massively skewed towards people with more ressources and time and 75% of the world, so I do not expect a sharp decrease in contributions.
Why is everybody all the time in favour of AI on HN? This is objectively a good change because it will improve the quality of the code in the long term.
There's a few major flaws or logical fallacies or whatnot in your comment:
1. "everybody all the time in favor of AI" - this is not true (objectively)
2. "This is objectively a good change because it will improve the quality of the code in the long term." - this cannot be considered "objectively" a good change because quality is subjective. Second, it makes the assumption that human written code is always (objectively) better than LLM generated, which is also not true.
But this is a software engineering project - the code is only part of the whole project / product, and the (subjective) quality of the code is only part of that. LLMs could write perfect code by whatever quality metrics they use, but if a reviewer is overwhelmed by a morbillion other perfect code contributions from LLMs it's moot.
AI assistance doesn't necessarily imply lower code quality. It can help with improving it in a lot of ways. Full vibe-coding without careful review is what results in low quality code. I think a lot of projects are having trouble getting to the sweet spot, though: if they allow LLM-assisted contributions then no matter how much they write to try make sure the result is high quality they're going to be inundated with far more low-quality contributions and have to work harder to filter through and reject them than if they just have a blanket ban which then makes it a lot easier to reject everything. The linked discussion is specifically with a view that not all LLM assisted contributions are bad but that they need to stem the flow for now and figure out how to open up afterwards.
Will it? Plenty of open source projects have bugs unfixed for decades because it's too tedious to fix by hand and would take five minutes with AI these days. I've also found that good LLMs can be more diligent in updating comments, tests, etc.
> I'd like to open another topic about the usage of LLM for review, auditing and security purposes, but I think this is a very separate thread, and we'll open discussions at the user conference before any formal discussions.
That does not mean the product becomes more useful. I could rewrite Windows 1-to-1 with better code quality and no one would care because it still provides the exact same features. Unless "better code" means "better features", better code is useless.
This is extremely short-sighted. Software is not a static product. "Improve code quality" translates into being able to add features more quickly and with less risk of bugs. For an open-source project, this also gives readers the opportunity to understand the codebase and learn from it.
QGIS is actually one of the big portable/cross-platform hybrid Python/C++ apps, which makes it arguably more complex for an LLM to cope with properly than one or the other, and makes code quality a rather more entrenched/storied problem.
In this way it is very much a spiritual cousin of FreeCAD (also cross-platform Python/C++/Qt6), though that (at least currently) has a somewhat more liberal ("humans in the driver seat") policy.
AI will soon be the majority of all cognitive intelligence by orders of magnitude. Insisting on human-only contributions to software projects is like insisting on hand-weaving a t-shirt when a loom can do it for a dollar. These projects only do it to limit spam from public contributors.
First, just check out the comments on any "I'm tired of reading slop" submission to refute your first point, the circle jerk is real.
Second, while I sympathize with not wanting to be inundated with low effort PRs, putting a ban on AI assisted contributions in response is myopic virtue signalling.
I think in this case it's not about signalling: in the linked discussion they are saying that the problem is the workload created by the AI-assisted creations, not the AI use in and of itself, and they are open to relaxing the restriction in future once they can figure out how to manage it.
(The issue is, I think, if you allow AI, no matter how many paragraphs you write about taking responsibility and ensuring high quality contributions, you're gonna get a lot of bad ones just because by sheer volume there's enough people who aren't gonna read it, and that's gonna take a disproportionate amount of effort to filter out).
I'm in favor of AI, but if I was a maintainer for an open source repo, I would also favor banning AI contributions. At least for the wild, maybe people who have built a reputation in the community could stay. I think AI can write quality code. What I doubt is if the average contribution will involve quality code or even human input.
For me, it is the way AI has kept suggestions to either open issues with maintainers or make PRs to fix an "issue" it found. I know it hasn't researched the issue in depth enough to be talking with the confidence it has, and I know I am in no position to be bothering someone else unless I want to spend considerable time investing to make sure the issue is exactly what the AI is claiming, it isn't a known issue, and it is justified to bother the maintainer with it. But there are far too many who will see that option and just tell the AI to do it.
It isn't that I'm against AI. It is that opening a PR or filing an issue use to have significant enough gatekeeping that most low effort low quality work simply wouldn't pass it, but that has now changed. So a new gate is needed to ensure those who aren't willing to put their own time into the work before asking for the time of others, and banning AI is one of the better options I've seen.
This also doesn't even end AI interacting with the project, just changes it. If you have some unique use case that AI finds, you can download it locally, have the AI make the change just for you, and have AI keep updating when necessary. Each user gets the customization they want while maintainers are protected from low effort low quality spam.
Ironically I lost my use case for QGIS since LLMs can readily write scripts for manipulating and converting point clouds (lidar data). I'm not a pro by any measure, mostly just making contour maps, but it massively streamlined things. To me it reveals the future of software
It's true that simple data conversion is now more easily performed using vibe coded scripts. But the real value of QGIS lies in it enabling managing data large complex projects (infrastructure, urban/environmental planning, etc.).
For those who, like me, had no idea what QGIS was: It is a free Geographic Information System (GIS), which means that it deals with creating, managing, analyzing, storing, and visualizing geospatial information. Think of (3D) maps and stuff like that.
I implemented css geometry properties for svg2 in resvg with claude. I know it works and I've read the relatively small diff. But I'm afraid to send a PR because it might offend a artisanal handcrafted free-range software enthusiast. I guess any other AI enjoyer who needs this feature, which is standard functionality in svg2, will just burn a few tokens and do it themselves to keep the luddites from smashing the factories.
In fact, this change seems quite logical. AI is certainly a useful tool, but that doesn't mean it must be uded always and everythere. Edpecially when doing so could compromise the final quality of projects. Let's see where all this leads
Contributions that are valuable, are valuable. These "No AI Contributions" nonsense is like saying AI art is not art. It's just not valuable for you, has nothing to do with AI. The QCIS project simply doesn't want to go over each PR and see its value? Because AI-generated things are not valuable for them, has nothing to do with AI, PRs, contributions, etc.
To play the devil’s advocate - AI generated code is incompatible with human generated code. I think this is a tradeoff most projects should make, but I can imagine some projects wanting to work the old way. I would question their relevance in the future, but I can respect that.
There is no need for them to accept AI contributions from third parties. Whenever they want AI code, they can just ask for it themselves, ensuring the model has the correct context and specifications in the prompt.
If you didn't mention it, how would they know if your contribution was written by AI or not? What happens to contributors who sneak in their AI-assisted commits where it's not obvious?
> If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your
contribution, you will be subject to code reversion and contributor rights sanctioning.
Policies like this have an element of trust to them. That's not new: open source projects have needed to trust contributors not to paste in proprietary licensed code since open source began.
Of course, if you sneak in a simple patch that an AI agent wrote for you, nobody might notice. The fact is, maintainers of big OSS projects are increasingly dealing with patches in the 10kLOC range, all at once, coming from people with little to no previous engagement with the project: that's usually a dead giveaway.
The question I have is what is an AI assisted contribution? For example, I still right code by hand, but I make many prototypes using AI before committing to a specific implementation. My code is clearly AI "assisted", but all of my final code is written by hand (no autocomplete either).
Banning does not imply verification. The policy is just a warning. So now you know, if they suspect that a PR is AI-generated, then there may be further consequences. I don’t think someone is going to apply a stamp on each PR.
The most egregious examples are always lazy (big diff, lengthy descriptions, weird phrasing,…). Now there’s a section in the policy to point to for the quick rejection.
The discussion is not about ownership of the code, that doesn't interest the people who have written the policy in question.
"Assisted" does not necessarily mean "authored", which is the point of the comment you're replying to; helping you review the code is "assistance", even if no code was written.
Good, QGIS is one of the projects that can be put closer to the bottom of the stack in that XKCD comic. I've seen QGIS being used just as a visualisation tool, and i mean it's good at it too, but even in a limited use case i am aware of it was used to do important infrastructure work like planning water pipelines and predicting failures for said pipelines.
I’ve been able to contribute to projects recently using ai. And another project banned this so I didn’t bother. The second was a bug fix for an issue I was having. The first was a new feature.
Either way my bug got fixed but if a project maintainer doesn’t want it who am I to fight it.
You can always fork it. I suspect my contributions are higher quality because I use different model providers to review each other but whatever.
QGIS is not your run of the mill project, though. This is specialized software and a rare breed. It's in their right to decide either way, and this is the right call for this niche, IMHO.
I'm a non-native english, so I change the code myself, but I tend to participate in communities while using a translator.
If I use AI, I can fix bigger things, but most of what I contribute to open source is finding small bugs, so I don't use AI for open source contributions. (I mostly don't even have the ability to make big changes.)
Looking around open source like that a few times, I can understand the hatred toward AI to some degree: too many requests pour onto a single individual. Of course, that doesn't mean AI isn't helpful. In my view, AI writes code blocks better than I do, and it might even be better to use AI for some of the open source I've contributed to... but overall, I feel that some kind of system for filtering AI-based PRs is needed.
And neither of us will get any traction, because the QGIS team has a history and proven track record within the GIS community, and neither of us are attempting to solve a problem that community has.
I bet millions of moved to deno, the javascript runtime... and they are ending support next year... after running for a few years only. You seem to be not questioning them.
Second, majority of apps do not last 2 decades.. and that is okay... someone else can fork the repo and continue if needed.
Lucky for AI companies that OSS projects are doing this, otherwise where will they get their carefully created training data from? They would be reduced to training off the slop their tools produce! /s
> QGIS is trusted by organisations because they know they can contribute back, they can hire contributors for support, training and feature. As a community project, this is something we really want to protect
We have gone from "LLM-slop is gonna ruin open source projects" to we wanna "protect" humans so they can make some dough on the side training and stuff. If human coders become the bottleneck in the chain, the solution is obvious and there's only so much protection anyone can do.
Looking at the scope of their code, the quality, the testing rigor etc. it's clear that they feel threatened by AI. Realistically a couple of prompts coupled with a factory of agents can replace this entire codebase in a matter of hours.
Furthermore, how will they prove whether code is AI generated or not?
And... I was correct. See their other PR
> QEP 429: Add exception to the AI policy for trusted contributors - #388
Aka only the trusted maintainers can use LLMs for speedups, the rest can suck it? Very mature behavior from the maintainers.
Plus it is becoming exceedingly rare of finding a contributor that save time, as in can do better than the maintainer itself using LLM and reviewing it itself.
The fact of being open source means if your contributions are rejected, you simply need to fork. The open market competition will soon determine if your contributions were truly valuable and whether the original project's owner misjudged, or that contribution was essentially worthless.
Being able to market your work and build community are key skills for open source contribution. The history of forges is littered with interesting code that never got enough attention to go anywhere.
Then marketing it to convince others to even try... If the idea is too niche it might never hit that threshold for uptake.
Another option would be to make a contributor pay for the review of its PR, even a small fee, to deter AI-slop, at least for new contributors. It could/would exclude students or people with the lowest wage though, but I'm optimistic even a 1$ bill or less would be enough.
The current contributors are already massively skewed towards people with more ressources and time and 75% of the world, so I do not expect a sharp decrease in contributions.
1. "everybody all the time in favor of AI" - this is not true (objectively)
2. "This is objectively a good change because it will improve the quality of the code in the long term." - this cannot be considered "objectively" a good change because quality is subjective. Second, it makes the assumption that human written code is always (objectively) better than LLM generated, which is also not true.
But this is a software engineering project - the code is only part of the whole project / product, and the (subjective) quality of the code is only part of that. LLMs could write perfect code by whatever quality metrics they use, but if a reviewer is overwhelmed by a morbillion other perfect code contributions from LLMs it's moot.
It is useful?, it works most of the time?
> This is objectively a good change because it will improve the quality of the code in the long term.
It depends?, sure, banning hit-and-run massive AI generated PRs will help.
These were problems before AI too, people just want to get their name on things without putting in effort.
This also bans possibly high quality PRs that fix things or add something new.
Either way, we'll see, anyone can still fork and if it's a better project then that will win over
> I'd like to open another topic about the usage of LLM for review, auditing and security purposes, but I think this is a very separate thread, and we'll open discussions at the user conference before any formal discussions.
That does not mean the product becomes more useful. I could rewrite Windows 1-to-1 with better code quality and no one would care because it still provides the exact same features. Unless "better code" means "better features", better code is useless.
Software design and architecture is about creating a system that can be built well, run well, and modify well.
If you just throw things together without thought you get an unmaintainable mess.
Can you explain why you think that?
QGIS is written in C++. Does that affect t your answer to this question at all?
In this way it is very much a spiritual cousin of FreeCAD (also cross-platform Python/C++/Qt6), though that (at least currently) has a somewhat more liberal ("humans in the driver seat") policy.
Second, while I sympathize with not wanting to be inundated with low effort PRs, putting a ban on AI assisted contributions in response is myopic virtue signalling.
(The issue is, I think, if you allow AI, no matter how many paragraphs you write about taking responsibility and ensuring high quality contributions, you're gonna get a lot of bad ones just because by sheer volume there's enough people who aren't gonna read it, and that's gonna take a disproportionate amount of effort to filter out).
Would you personally join in to evaluate and review the onslaught of AI generated PR to the project?
For me, it is the way AI has kept suggestions to either open issues with maintainers or make PRs to fix an "issue" it found. I know it hasn't researched the issue in depth enough to be talking with the confidence it has, and I know I am in no position to be bothering someone else unless I want to spend considerable time investing to make sure the issue is exactly what the AI is claiming, it isn't a known issue, and it is justified to bother the maintainer with it. But there are far too many who will see that option and just tell the AI to do it.
It isn't that I'm against AI. It is that opening a PR or filing an issue use to have significant enough gatekeeping that most low effort low quality work simply wouldn't pass it, but that has now changed. So a new gate is needed to ensure those who aren't willing to put their own time into the work before asking for the time of others, and banning AI is one of the better options I've seen.
This also doesn't even end AI interacting with the project, just changes it. If you have some unique use case that AI finds, you can download it locally, have the AI make the change just for you, and have AI keep updating when necessary. Each user gets the customization they want while maintainers are protected from low effort low quality spam.
My 2 cents.
> If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning.
Policies like this have an element of trust to them. That's not new: open source projects have needed to trust contributors not to paste in proprietary licensed code since open source began.
The most egregious examples are always lazy (big diff, lengthy descriptions, weird phrasing,…). Now there’s a section in the policy to point to for the quick rejection.
> My code is clearly AI "assisted"
No such thing, it's 100% your code, regardless of how it came to be.
"Assisted" does not necessarily mean "authored", which is the point of the comment you're replying to; helping you review the code is "assistance", even if no code was written.
Curiously, https://github.com/qgis/QGIS-Enhancement-Proposals/pull/387#... shows that at least some contributors realize the vagueness of the policy, but they don't seem to care, which is rather unfortunate.
Edit: https://xkcd.com/2347/
Either way my bug got fixed but if a project maintainer doesn’t want it who am I to fight it.
You can always fork it. I suspect my contributions are higher quality because I use different model providers to review each other but whatever.
I'll fork it in about 30 seconds.
And neither of us will get any traction, because the QGIS team has a history and proven track record within the GIS community, and neither of us are attempting to solve a problem that community has.
The question is whether or not you are willing to support your creation for the next two decades.
Second, majority of apps do not last 2 decades.. and that is okay... someone else can fork the repo and continue if needed.
If not you may want to familiarize yourself:
https://en.wikipedia.org/wiki/QGIS
What a track record!
We have gone from "LLM-slop is gonna ruin open source projects" to we wanna "protect" humans so they can make some dough on the side training and stuff. If human coders become the bottleneck in the chain, the solution is obvious and there's only so much protection anyone can do.
This "human bottleneck" is why we have QGIS in the first place. I think they deserve a bit more respect than that.
Which chain? It’s not like there’s much productivity going on. There’s a lot of activity for very little impact.
Furthermore, how will they prove whether code is AI generated or not?
And... I was correct. See their other PR
> QEP 429: Add exception to the AI policy for trusted contributors - #388
Aka only the trusted maintainers can use LLMs for speedups, the rest can suck it? Very mature behavior from the maintainers.
you are the reason for this policy change