A proposal to make KDE an “AI-native” desktop has gone down like a house on fire: screams, flames, people running for safety. There may be no survivors.*
Last weekend was KDE’s annual Akademy conference and it included a presentation proposing an AI-native KDE. We noted that it seemed likely to polarize the audience. It looks like this was a considerable understatement.
In the days since, a debate over proposed restrictions on LLM-assisted contributions descended into bans and a deleted thread. An outside campaign called for KDE to prohibit AI altogether, a GNOME developer proposed a similar policy for that project, and KDE developer Nate Graham apologized for his role in the uproar.
The Akademy talk was titled “A lovable, sovereign, AI-native KDE” and the slide deck [PDF] is now available. It ends by saying: “The question is not whether AI. It is how. You choose how much AI – and which.”
It seems almost calculated to provoke an argument rather than invite discussion. We do not know if the authors intended this – we attempted to contact both of them, but they have not yet responded.
Graham opened a discussion on Invent, KDE’s GitLab instance, about proposed restrictions on LLM-assisted contributions. Although we are not a member, we watched this with some interest over the weekend. It rapidly became heated. Moderators issued warnings, restricted further comments, and eventually removed the thread.
There is an archive of the discussion, but we warn you, it contains some highly offensive language, albeit censored by the member who quoted another member’s tweets on X. As events unfolded, the participant who drew attention to the posts was banned first. The author of the offensive material was banned later after their identity was verified.
The discussion is gone, but the argument continues.
One response was an outside initiative called KDE for People, which called on the KDE project to adopt a No-AI policy. Around 250 people signed it before its organizers closed it to further signatures.
GNOME developer Jordan Petridis has also published The GNOME LLM Policy That I Want, proposing that LLMs be barred from creating or modifying anything submitted to GNOME or hosted on its infrastructure.
This mentions the recent ballot on AI usage in Debian. We reported on the developer referendum about a month ago, noting that the broad spread of anti-AI options in the ballot was likely to split the vote. (This likelihood was dismissed in the comments.) Well, as The Register’s Asia-Pacific desk reported a few days later, Debian did not ban AI contributions.
Graham subsequently explained his involvement in a post titled KDE and AI, and you, and me. He opens by saying: “So I accidentally triggered an online shitstorm in the process of trying to craft a set of more restrictive LLM usage guidelines for KDE. Sorry about that.”
He notes that the Akademy talk met “what I’m told was a fairly chilly reception” and that “the next day, a workshop was held about the topic, also receiving a chilly reception.”
Every couple of years, the KDE project sets three goals for the next two years. Earlier this week, after Akademy, it chose its latest three: you can see them in the last column of the goal-setting Kanban board. The ones chosen are:
KDE for Enterprise and Deployments (Issue #5)
Better documentation (Issue #2)
Next Generation Styling for KDE (Issue #3)
We see no mention of AI in there. In context, that may come as a relief to parts of the community.
Bootnote
*A tip of the black Borsalino to the late great Terry Pratchett, for two different “house on fire” references we combined. ®
Sure, you’re talking about the imbeciles using AI, but I dare you to tell the difference between AI and corporate talk. AI can make amazing marketing press releases because the human written ones didn’t make any sense anyway. They’re the same bullshit.
And yes, code written by AI that is simply prompted by a junior or a person who know what they’re talking about, is going to be shit. A vibe coded project will show it’s colors. But you’re ignoring (or unaware) the output that ends up in an expert’s projects. You might think you can recognise it, but I can tell you, you won’t. And if you don’t want to believe me, try it yourself.
I worked with a dude who used to finish his tasks pretty quickly and I just thought he was a good programmer. It finally dawned on me that he was using AI, because his level of the programming language wasn’t that high but the code constructs he was using were advanced and sometimes unnecessary. They weren’t bad and I’d let them through the review, because he got the job done, he understood most of what was going on and was learning the language as he went along. But I was only able to detect it because I spoke to him daily and could gauge his level of understanding more accurately. Had he submitted the code he did anonymously, in a one off PR to an opensource project that is anti-AI, I guarantee you, it would’ve gotten merged.
I dunno man as someone that reads a lot of AI slop for a living I’ve gotten pretty good at sifting out when someone actually wrote a doc and when someone just shat it out with Claude. They all have their specific tells and ways of meandering around the point that just doesn’t exist.
I know people like to think so, but there was an empirical study done with professors who said they could recognise AI submitted work from their students and were wrong 50% of the time.
That sounds more like you just let ineffecient code that the programmer can’t maintain through the revuew process. Shit like that is why software is getting continually worse
I would go even further and say that somebody who doesn’t understand the importance of maintenability in software development and lets unmaintaineable code through is functionally him or herself a junior developer.
If something is way harder to go through to fix bugs or add new functionally than it should, that means you’re just paying in maintenance time the bill which should’ve been paid during coding time, and maintenance time “bills” are way more expensive because its far more time costly to track down bugs and if the thing is already in production you often have the added cost of having to fix side effects of the bug such as corrupt data.