A talk in three parts, building towards a vision for a sovereign desktop in 2026 (and a look back).
- Loved. In 2003, together with Eva Brucherseifer, Jan’s company relevantive ran the first large-scale usability study of the Linux desktop on behalf of decision-makers considering migration. KDE 3.1 on SuSE was tested by 60 office workers with no prior Linux experience; 87% enjoyed working with it, 80% estimated they could reach professional competence within a week. The Linux desktop wasn’t a usability disaster — but realising its potential required deliberate configuration, honest naming, and treating migration as a human-resources problem, not a technical one. The findings shaped a decade of OpenUsability work inside KDE. They are, awkwardly, almost entirely still applicable. We’ll look at what stuck, what didn’t, and why “lovable” — not merely “usable” — is the bar today, and why getting it right cuts the cost and risk of every migration discussion that follows.
- AI-native. A desktop that loves you back has to know you. Personal AI has crossed the threshold where the desktop itself can be compiled per user, per device, per moment, from a small portable model of the user — what we are sketching as Kadai: an encrypted, vendor-agnostic personal kernel from which Plasma assembles each Activity. Plasma is uniquely well-fit for this — Activities, Plasmoids, the existing scripting surface — but a handful of upstream changes (declarative reconciliation, per-widget capabilities, richer Activity metadata) would turn KDE into the first shell that treats AI as infrastructure rather than as a chat box bolted to the side.
- Sovereign. Once a user owns their model and their tools, the same question returns at institutional scale. EU institutions, member countries, and a long tail of organisations are openly asking what a credible, non-colonialising desktop stack looks like. No project carries this alone — a sovereign desktop is an ecosystem question. KDE is uniquely positioned as the shell, the integration layer, the experience; but filesharing belongs with Nextcloud, the browser with Firefox, the office suite with … The last third of the talk is about what KDE’s partnership surface could look like — outward, to industry and public administration, and sideways, to the allied open-source projects that already do the rest of the work better than anyone could redo it. Who owns that surface, where it lives, what KDE e.V. would need, what not to build. Sovereignty, from this angle, is just lovability and AI-ownership scaled up to the organisation: the user not owned by a vendor, the institution not owned by a foreign supplier — and the stack not owned by anyone, because the right partners hold the right pieces.
This talk is an invitation — from peple with a long arc inside this community — to take a serious swing at the question the 2003 study posed and never quite resolved: what would it take for KDE to be the desktop people actively choose, not just the one some of us settle for? Attendees will leave with: a concrete proposal (KaDAi) to react to or tear apart, a clear set of asks the project could direct at Plasma maintainers, and the framing for a sovereignty conversation that KDE is uniquely positioned to lead.
It sounds useful to me. But who cares? This is KDE we’re talking about! It’ll be a subsystem you can disable at will just like everything else in KDE.
Needs to be something that must ebay enabled first. I hate opt out technology.
That type of thing is typically a decision made by your distro. For example, since most people don’t have the necessary hardware to use decent models, I’d imagine that the AI packages wouldn’t be installed by default.
Only people that manually install the packages will get the AI features.
Pretty sure we can say that won’t be the case.
If you read the discussion, it’s about KDE being “Ai-native” and treating it as “infrastructure”. It literally even talks about how they don’t want it to be a “bolt-on chatbox”. They’re discussing making AI the desktop.
It is a “discussion”, but it seems more like prepping the community for something they already decided and want.
Meh. They said the same thing about integrating semantic search into KDE. Yet I have turned that indexing off since forever and it never really changed much.
I guess I spent a lot of time tagging my files back in the day so I could find them better, haha. What a huge ass waste of time!
AI is so vastly superior for searching than all previous efforts combined, it feels like renaming, tagging, etc are just pointless tedium.
I care because I don’t want security vulnerabilities introduced into my desktop, and because there are other things they could be working on…
It’s a community of mostly volunteers. Volunteers work on what they want to work on. Telling them to not do that, would not mean they’d pick something else to work on…
If they want to make agentic bullshit to appease corporate investors, then they should find something else to work on.
AI can have vulnerabilities but so far nearly all of them have been related to fully automated systems. As in, you give a model the power to reach out to the Internet or read/write files anywhere it wants (i.e. break out of the sandbox), then you tell it to perform some long-running or infinite task like, “when a file shows up in this place, read it, then perform actions based on what was in the file.”
I believe we all call that, “a recipe for disaster” (LOL). That’s not what they are talking about when integrating AI into KDE.
There’s not really any inherent vulnerability in letting the user spin up a model to perform a task. Also, if it works like development IDEs, the end user needs to accept any changes the model is trying to make before anything at all happens.
Having said that, this is very new tech. It really could have some unforeseen vulnerabilities. However, all new tech has that problem. Any time you add a new feature to anything there’s always the chance of creating a vulnerability.
Burying our collective heads in the sand because we’re afraid of the potential for a vulnerability seems a bit weak to me. We already know how not to implement things! Just look at whatever Microsoft is doing and don’t do that! 😁
Local AI isn’t like Big AI! I mean, think about it: How much resources is ollama getting on your local PC/GPU compared to what say, OpenAI gives its models? The potential for vastly problematic issues is so, so much higher on Big AI infrastructure.
BTW: Ollama unloads any running models after five minutes of inactivity by default. It’s kind of annoying (to me) because it can take like 3-30s to reload the model (depending on how big it is) but for something like a KDE integration, I’d imagine they’d be using tiny models (e.g. models meant for embedding) that load and unload in just a few seconds. Especially for RAG/search functionality.
They’re not.