What happened to Bevy when they loosened their AI policy to be more ‘realistic’
i think the break down of trust, the perception of reality and destruction of communities has been greatly underestimated when it comes to AI (or it was deliberate, better put my tinfoil hat back on…)
even more so when there’s no way of knowing how many of those pro-AI voices are even real people
The dynamic between “AI” boosters and people who don’t want to use LLMs is not on level ground. “AI” boosting in a space with people who want to be “AI Sober” is disruptive and antagonistic, knowing that you’re doing it is baiting or outright trolling.
This is something I’ve wondered about with regards to all of this, especially in the open source community. If a large enough group of people thinks a project would be better with AI and the original project is resistant to it, then presumably by the general nature of open source they should be able to just fork it, make their AI version and see which is more popular. And if AI is so much better and faster, then that should rapidly become the dominant version.
However, I don’t recall that happening with any projects I’ve heard of, and I don’t really hear about much forking going on. I’m sure it’s happened somewhere, but to me it seems like the vast majority of stories I hear are about existing projects suddenly being deluged with AI until they get overwhelmed, and then descending into flame wars when they try to do something about it.
That was a very good read, thank you for sharing it
Seconding Cris, that was a fantastic read.
I actually like the way this is formulated.
It’s not a knee-jerk “ban all AI forever!” thing, it’s a more reasonable “by these authoritative sources, we don’t have reasonably eco-friendly, people-centric, ethical AI right now. This may change, but for now using these tools the way they are proposed goes against these KDE goals and values, and even part of KDE itself, KDE Eco, goes strongly against it”.
Still, KDE is typically closer to the “move fast and break stuff” edge, so I get to assume they’ll largely opt to ignore it. But maybe we can put at least some reasonable brakes on it where it matters the most.
I wonder if any major project has had forks because of their inclusion or exclusion of AI.
And I’m unsure if that’s positive or not. Maybe it is because it can accommodate the needs and wants of everyone. But then again there’s division and all this tension. The polarization is too much right now. And it may even grow further, as the AI enticement becomes deeper with cheaper, smarter, whatever may happen… Meanwhile, oligarchs are enjoying their Datacenters and pushing their agenda for surveillance and control or even monopoly of one voice, the voice of AI, that holds “the truth” with examples as whatever you get when asking DeepSeek about Tiannamen square. And chatgpt may have blindspots of their own that we are yet to see.
What I’m trying to say is that the political debate is bigger than what any community can really hold without accepting a certain degree of heterogeneity.
There is a no AI vim fork, “evi”: https://codeberg.org/evi-editor/evi
And a no AI tmux fork, “opentmux”: https://codeberg.org/opentmux/opentmux
And a no AI keepass fork, “ChiPass”: https://codeberg.org/ChiPass/ChiPass/
I’m not aware of any major project forks due to it, only smaller ones, such as this fork of Waybar that was specifically forked to remove the AI code added to the main project.
Forking the bigger projects would be a pretty huge effort. If enough left at once it could be viable, or perhaps a fork could be cut down to make it more manageable to maintain and develop for a smaller team.
If there is no forks, maybe the dissenters from the major projects will congregate toward independent projects who have already taken a stand against AI.
I think that contributions should be evaluated by their content, which the contributor has full responsibility, instead of trying to impose rules you can’t 100% verify just because they look good on paper.
- The patch is good (in quality terms), accept it.
- The contributor created a successive set of bad and lousy submissions? Block it for a period of time.
Putting a “ban” on how the code is generated, is just a statement of good intentions that you can’t enforce or verify.
Most contributors tend to follow the rules of a project. Some will skirt them, some AI code will probably get in, but a ban will certainly limit it, and certainly look better in court compared to “We made it a rule that it’s okay to not disclose that you used the likely copyrighted code generator”.
Take for example the WINE project, which has a strict ban on anyone who has seen the Windows source code from contributing to the project (such as an ex-employee or someone who has seen the source code from a leak). This is obviously impossible to enforce; how could they reasonably prevent a microsoft employee from submitting code that might be infringing on Microsoft? They can’t. But their ban will certainly aid them in court if MS ever did sue them for infringement. and I think it likely anyone who had seen the source code and wanted to add a patch would respect the rule. It’s not perfect protection, but it’s certainly better than “If you submit windows source code, just don’t tell us, and hopefully we won’t get in trouble”.
WINE and ReactOS having that statement for protection, makes sense for obvious reasons, given the nature and aim of the project. Even if, as we agree, it is totally unenforceable.
This total AI ban trend we are seeing in recent times, while similar, lacks the self protection reason and the text of the link backs it up with more abstract things such as: “erodes trust”, “makes it more difficult to review code”, “harms privacy”, etc. All good intentions, quite a show against this new type of tool (that has its problems yes), but with the only practical consequence of pushing people away.
I would prefer a set of stricter guidelines and standards, to make it easy to reject slop and bad (vibe coded) contributions.
the standards of the petition would fail all five most popular DEs and Sway. Niri is talked of as prohibiting AI but said policy of “You can use LLMs privately (not like I can check or control that), but not to write from scratch.” seems to match KDE’s policy completely.
I agree Niri doesn’t have a usable anti LLM policy as of today. But there are still other desktops!
E.g. the river compositor has this policy: https://codeberg.org/river/river#strict-no-llm-no-ai-policy
Use of generative AI/LLMs is strictly forbidden for all contributions to river.
This includes bug reports and comments on the issue tracker.
which one? I haven’t heard of River before. the repo says it’s only a compositor and needs a window manager, and kwm seems to be the most popular River-compatible window manager, and it doesn’t have a policy unless you count “It is the contributors’ responsibility to ensure that all submitted code is either original or GPL-3.0-compatible.”
Sadly, some river WMs aren’t anti AI. But some are, e.g. this one: https://codeberg.org/beansprout/beansprout Or this one: https://codeberg.org/sivecano/rhine
Despite signing as “a community of KDE users and contributors”, the signatures list does not separate contributors from others. oP’s previous thread was locked for a reason
Are you suggesting I made this initiative?
no, i see now how my words imply that and apologies for that. i was making the point that i believe a lot of people and signatures are misinformed.
