YHK - yet another hacker news clone

No, you retain full authorship of your code regardless of how it's generated.

> My code is clearly AI "assisted"

No such thing, it's 100% your code, regardless of how it came to be.

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.

> Realistically a couple of prompts coupled with a factory of agents can replace this entire codebase in a matter of hours

you are the reason for this policy change

I don't imagine they will care if you do that, there will be no detrimental effects to them from doing so.

but you can just fork the entire repo and continue development with AI yourself, why the need to rewrite it from 0?

Go for it. I bet you could do it in a week.

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.

You can clone anything in 15 minutes with AI. Just like you can start a child in 15 minutes.

The question is whether or not you are willing to support your creation for the next two decades.

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.

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.

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.

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.

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.

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.

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.

In favor? There's a whole spectrum between "complete ban" and "slop all the way", IMO.

> Why is everybody all the time in favour of AI on HN?

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

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.

Dude maybe if it was ChatGPT 2.0.. AI has come a long way.

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.

Calling your own opinion objective is not a good practice. This is very much something you can have different opinions on.

> This is objectively a good change because it will improve the quality of the code in the long term.

Can you explain why you think that?

QGIS is written in C++. Does that affect your answer to this question at all?

>it will improve the quality of the code

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.

Because this is a startup/tech community and people generally look forward to exploring new ideas and tech?

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.

Are you asking why most people from Big Tech, very likely working on AI-adjacent products, have a very strong pro-AI bias?

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.

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.).

> If human coders become the bottleneck in the chain, the solution is obvious and there's only so much protection anyone can do.

Which chain? It’s not like there’s much productivity going on. There’s a lot of activity for very little impact.

> If human coders become the bottleneck in the chain

This "human bottleneck" is why we have QGIS in the first place. I think they deserve a bit more respect than that.

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.

The new policy says:

> 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.

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.

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.

for what purpose? qgis is already free to use, unlike Adobe's CS