Welcome to a new issue of This Week in Plasma!

This week about 200 KDE contributors and enthusiasts attended Akademy, but somehow people still found the time to be productive! Plasma contributors released the second beta of Plasma 6.8 and landed a bunch of user interface improvements and bug fixes.

As always, this is only a curated subset of everything that happened in Plasma over the week.

Check it out:

Notable UI improvements

Plasma 6.8

Click feedback for System Tray icons now works a lot better (even if it remains inconsistent with other things, which is also being worked on!). (Kamil Wolter, KDE Bugzilla #520915)

The focused tab in a Plasma tab bar now looks less like a link, which it isn't. (Christoph Wolk, libplasma MR #1584)

You can now use the "Switch to Last-Used Keyboard Layout" keyboard shortcut on the lock screen. (Pavel Lunin, kscreenlocker MR #373)

Password fields throughout Plasma now show an explanatory tooltip when you hover over the little eyeball icon that shows and hides the characters of the password. (Christoph Wolk, KDE Bugzilla #525790)

Muting an app or window from its Task Manager entry no longer closes the preview tooltip for it. (Christoph Wolk, KDE Bugzilla #521174)

Dragging the QR Code of an item in the Clipboard widget now shows it visually attached to the pointer during the drag. (Kai Uwe Broulik, plasma-workspace MR #7108)

Plasma 6.9

KRunner-powered searches are now more flexible about currency conversions: you can now put the currency symbol on either side of the number and it will still recognize it as something that can be converted. (Alex Čižinský, KDE Bugzilla #446045)

Copying text in Info Center now shows some visual feedback so you know it worked. (Mradul Pal, kinfocenter MR #313)

You can now search for a weather station whose name includes punctuation without including the punctuation in your search. For example, you can search for "st louis" to find weather stations for "St. Louis". (Bohdan Onofriichuk, KDE Bugzilla #515637)

Notable bug fixes

Plasma 6.7.6

Fixed a bug that could make logout, shutdown, or restart fail if there was already another attempt to do so running in the background. (Gregor Papez, KDE Bugzilla #525911)

Fixed a bug in the Weather Report widget that could make it get stuck after canceling a search that returned any results from the BBC. (Bohdan Onofriichuk, KDE Bugzilla #1133)

Fixed a regression that made CPU Information get cut off in Info Center. (Nate Graham, KDE Bugzilla #523197)

Plasma 6.8

Plasma no longer crashes when you delete a starred clipboard entry from the Meta+V popup. (David Edmundson, KDE Bugzilla #526007)

Long labels can no longer overlap on System Settings' Shortcuts page. (Christoph Wolk, KDE Bugzilla #525725)

Fixed a bug in the Weather Report widget that could mis-report the night temperature for weather stations from the wetter.com provider. (Bohdan Onofriichuk, KDE Bugzilla #520315)

Queries in KRunner-powered searches longer than 63 characters no longer spam the journal log with hundreds or thousands of pointless messages. (David Edmundson, KDE Bugzilla #525983)

The Dictionary widget's minimum size no longer breaks its layout. (Christoph Wolk, kdeplasma-addons MR #1138)

Notable in performance & technical

Plasma 6.8

Plasma's Bluetooth setup wizard can now be used to find and pair Bluetooth Low Energy devices while something else on the system (such as KDE Connect) holds open a discovery session for other devices. (Robert August Vincent II, KDE Bugzilla #526178)

Plasma 6.9

The C.UTF-8 locale is now available on System Settings' Region & Language page. (Nate Graham, KDE Bugzilla #438290)

How you can help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

Would you like to help put together this weekly report? Introduce yourself in the Matrix room and join the team!

Beyond that, you can help KDE by directly getting involved in any other projects. Donating time is actually more impactful than donating money. Each contributor makes a huge difference in KDE - you are not a number or a cog in a machine! You don't have to be a programmer, either; many other opportunities exist.

You can also help out by making a donation! This helps cover operational costs, salaries, travel expenses for contributors, and in general just keeps KDE bringing Free Software to the world.

To get a new Plasma feature or a bug fix mentioned here

Push a commit to the relevant merge request on invent.kde.org.

26 Sep 2026 12:00am GMT

Let's go for my web review for the week 2026-39.

---

The Test

Tags: tech, culture, business, politics

Yes, the preposterous statements from the tech moguls have a use. They allow them to gauge how obedient you are. This is thus a political function and a way to check their power. Maybe it's time we collectively start to say the Emperor has no clothes?

https://tante.cc/2026/09/24/the-test/

I asked 100 companies for my data. Some deleted it instead.

Tags: tech, data, law, privacy

Don't be like those companies! I wish there'd be more responsible handling of such requests.

https://arstechnica.com/tech-policy/2026/08/i-asked-100-companies-for-my-data-some-deleted-it-instead/

Why I Love AI

Tags: tech, ai, machine-learning, gpt, copilot, science, research

Since I've got my PhD in AI almost twenty years ago now, this piece strikes hard. This fellow kept doing research while I didn't (the reasons to be told another time but it's linked to this article). Clearly AI researchers who started around that time or before have a very different vision to what "AI" means as a field (although I've a few difference I'm fairly aligned with this article)… Clearly we've been robbed of the term by the industrial complex.

https://www.possibilityspace.org/blog/posts/i-love-ai/

Don't be fooled by this summer of AI hype

Tags: tech, ai, machine-learning, gpt, copilot, hype, ethics, ecology

The hype is very high right now indeed. This can lead only to misguided decisions. But really it's mostly distraction from the massive ethical concerns this industry carries. It would require for policymakers to step up but I'm afraid it unfortunately won't happen or they'll come up with misguided attempts if they don't first consult with field experts.

https://www.technologyreview.com/2026/09/22/1144867/dont-be-fooled-summer-ai-hype/

No Sloptober

Tags: tech, ai, machine-learning, gpt, copilot

Interesting initiative. I wish it'll be popular and many people will follow it. Maybe it'll cure some of them of their AI psychosis…

https://no-sloptober.com/

How to talk about "AI" without adding to the anthropomorphization

Tags: tech, ai, machine-learning, gpt, linguistics

Goes maybe a tad too far in the opposite direction at times leading to clunky phrases. That said this effort of naming things properly is badly needed. I hope the media will seize it and report about those tools properly.

https://buttondown.com/maiht3k/archive/how-to-talk-about-ai-without-adding-to-the/

America is getting its AI race with China wrong

Tags: tech, ai, machine-learning, gpt, trust, business, law

So apparently the low adoption is due to the lack of trust in the systems and regulations could help? Who knew…

https://restofworld.org/2026/america-china-ai-race-trust/

ChatGPT now knows what you do on other websites via ad collector

Tags: tech, gpt, attention-economy, surveillance

It was only a matter of time I guess. Another vehicle of the attention economy. They're trying to monetise through advertisements.

https://www.buchodi.com/chatgpt-now-knows-what-you-do-on-other-websites-via-ad-collector/

Laya - 33ms Multilingual System 1 Decision Engine with Calibrated Probabilities

Tags: tech, ai, machine-learning, decision-making

Now this look like a very interesting and useful model you can run locally. Definitely helps for classification tasks or assisting in decision making.

https://laya.convaiinnovations.com/

kev: tiny Jev-like family of decision models built on top of Qwen3.5 you can train and run on your own

Tags: tech, ai, machine-learning, decision-making

Looks like yet another interesting model to build decision assistance systems and classifiers.

https://github.com/jaredpalmer/kev

Linux programs look at things in /proc more than you'd expect

Tags: tech, linux, system

And most times as developers we don't even realize it happens! It's so conveniently hidden deep in most libraries or runtimes.

https://utcc.utoronto.ca/~cks/space/blog/linux/ProcGetsUsedByPrograms

About alignment, struct layout and the cache…

Tags: tech, c++, memory, caching, performance

Need to mind the memory layout of your structs to get good performance. Often overlooked but that also includes the padding.

https://meetingcpp.com/blog/items/About-alignment-struct-layout-and-the-cache-.html

How did AMD Ryzen get 50% faster in two years?

Tags: tech, hardware, cpu, amd, performance

There's really something brewing at AMD. They're on a roll performance wise.

https://lemire.me/blog/2026/09/18/how-did-amd-ryzen-get-50-faster-in-two-years/

How many strings can you create per second?

Tags: tech, memory, performance, c++, rust, go, python, javascript

Probably more than you think in this setup. And even more in C++ with the STL having years of smart tricks behind it.

https://lemire.me/blog/2026/09/25/how-many-strings-can-you-create-per-second/

Why CAFEBABE?

Tags: tech, java, funny

So many weird magic numbers to consider… Funny conversation around the one of Java class files.

https://www.artima.com/insidejvm/whyCAFEBABE.html

Union vs sum types

Tags: tech, type-systems

Wondering about the differences between union types and sum types? This gives a good idea about what they are.

https://viralinstruction.com/posts/uniontypes/

The Engineering Manager's Guide to Emotional Tolerance

Tags: tech, management, emotions

This mostly fine advice. Managing requires acknowledging emotions otherwise you can't lead effectively. Don't get dragged too far into it though, you're not a therapist.

https://thrivinginengineering.substack.com/p/the-engineering-managers-guide-to-emotional-tolerance

---

Bye for now!

25 Sep 2026 9:13pm GMT

My experiences at Akademy

It's been a hot minute since my last blog post, mostly because I was focusing on finally finishing my studies - while I'm not quite done yet (still missing one exam), I have a good reason to come out of hiding: KDE Akademy 2026 just happened and I was there!

Talks

While I was already at the Plasma Sprint in Graz last year, this is my first other KDE-related event I attended and oh boy was it ever an event. So many talks ranging from educational and thought provoking to simply silly fun and plenty of opportunities (for frequent and extended coffee breaks leading to even more education, thought provoking and simply silly fun conversations!

BoFs

If it was just that I would have already called this amazing, but the "talks" part of Akademy was just the first two days (not counting the "arrival day" + evening welcome event which I could unfortunately not attend myself), but the following days were equally amazing, if not even more so. A bunch of lively discussions in plenty of BoF rooms (and, which I have learned there, the famous hallway BoFs) around so many topics I can't even hope to mention them all here. I attended some conversations around how to better get in touch with stakeholders to reduce the general society's reliance on big tech, the technical intricacies of theming systems in general and KDE Union in particular, implementation details for the new XDG Intents, ... I could go on forever, really, but I shall restrain myself.

In short: Tons conversations and planning that works best in-person was done as well as a lot of networking and putting-faces-to-names.

The C word

Now unfortunately not everything was sunshine and roses - Wednesday was a day of unspeakable, chocolate-based torture for all of us. We toured the Zotter factory near Graz which included the ability to taste-test their chocolates at various steps during production process (yes, this includes up to as early as whole dried cocoa beans!) as well as a wide selection of their final products. It was much more interesting than I thought it would be and such a great experience to do all this with so many kool (with a K!) people.

However... let's just say mistakes have been made and I misunderstood the Zotter employee's statement that there are "roughly 300 taste testing stations" as a promise and not a threat. I definitely purchased a number of chocolate bars in their shop at the end but I don't think I'll be eating any of them any time soon after my complete lack of self control during the tour and the ensuing (and entirely predictable!) consequences.

And the worst part: After that we went to a Buschenschank for a good old "Brettljausn" (not sure how to translate, but essentially a meat and cheese buffet) where I also ate way too much since it's been way too long since my last proper Brettljausn.

And with that I think I covered everything I wanted to talk about - Thanks so much to everyone organizing and attending to make this such an unforgettable week! If you'll excuse me, I'll now fall into bed and sleep what feels like for several days straight

24 Sep 2026 8:00pm GMT

Here are the new modules available in the Plasma 6.8 beta:

• kup: Backup scheduler for the Plasma desktop

Some important features and changes included in 6.8 beta are highlighted on KDE community wiki page.

Help stress-test the Union theming system

This releases marks the second half of the Union theming system's public tech preview!

New in Plasma 6.8: Union now themes QtWidgets applications, such as Dolphin and Kate. Bear in mind this support is preliminary and you will encounter bugs. When you do, please report them here!

To test Union:

1. Make sure the union package is installed (name may differ depending on your distro)
2. Launch System Settings
3. In the sidebar, navigate to Colors & Themes → Application Style
4. Click "Breeze (Union)"
5. Click Apply

This will apply Union styling to both QtQuick and QtWidgets apps.

The intention is for these apps to look as similar as possible when styled with Union to how they look with Breeze - though any minor visual improvements should be considered intentional!

If you find any issues, make sure they're Union-specific by running the app with the Breeze style to compare the two. If the issue is Union-specific, report it here!

KWin

KWin now depends on the plasma-wayland-protocols 1.23.0 release to provide fix for memory leak.

Everything else

View full changelog

24 Sep 2026 12:00am GMT

During this year's Akademy, while celebrating KDE's 30th birthday, I found some time to do some hacking on a beloved old toy widget: the Bouncy Ball I used to maintain for a while, and which Filip recently made available for Plasma 6 again.

The all-new Bouncy Ball 3D - find it on the KDE Store (and by extension your Plasma's Add Widgets dialog) now - adds high-quality 3D graphics, more expressive physics with satisfying ball squish, and better support for living in and launching from a Plasma panel.

I have of course coordinated this with Filip a bit, and we agreed it's better to make this a seperate widget/release for now to keep the classic ball available for its fans.

Note the new widget requires at least KDE Frameworks 6.26+, i.e. around the Plasma 6.7 timeframe.

Enjoy the bounce!

While you bounce about, consider watching my Akademy 2026 presentation on taking KDE to the Great Pyramid in Egypt for high-tech archeological research.

24 Sep 2026 12:00am GMT

I got pissed off with the current situation occurring on social media regarding multiple topics, so I decided to make a FAQ explaining the situation.

The topics include the mentions of AI at Akademy, the policy proposal, and some moderation shenanigans.

Does this count as damage control? Probably. Does it originate from being upset with the current situation rather than some weird corporate-esque reputation thing? Yes. Was I the only one to feel the exact same thing at around the same time? No.

Misinformation in general already bothers me a lot, misinformation that damages other people to such a high degree is another level of pisses me the fuck off though.

It doesn't really matter. I hope the following is informative, especially to dispel misinformation.

Note that I'm not a KDE e.V. board member. The following is based on what I know. I just used neutral language for the most part.

I should also note that I'm in the NoAI camp, that I actually watched the talks mentioned here (imagine that), that I spent half a year learning about AI and ethical use (part of which is mentioned in Slop is incompetence, treat it as such) to spite-ground my complaints about it better.

I am not going to go through the timeline of events because Nate already did that in his KDE and AI, and you, and me blog post. I'm only going to address matters I've personally seen online. Some of those were already addressed by the Promo team (where most of the work was from one person doing their best).

I am not sure this blog post counts as speaking for other KDE people when I say "we" or "KDE does", but I feel confident about these at least being a general sentiment.

Why was an "AI-native" talk part of Akademy?🔗

The referred talk is What would it take? A lovable, sovereign, AI-native KDE.

Anyone can submit a talk, and it was accepted precisely to get a different perspective and to see people's opinions on AI.

As you can see, the reception wasn't great.

Was the "AI-native" talk written with AI?🔗

Clearly. The only one to do so.

What was the "AI-native" talk actually about?🔗

The main three points the talk brought were lovability, sovereignty, and making KDE AI-native.

"Lovability" does not mean "Loving KDE software" in any sort of Actual Love sense (it's weird that I have to clarify that, some people did understand it like that).

It refers to the idea achieved through usability studies that people liking what they use and seeing it as actually theirs creates a significant appeal enough to matter even in commercial or governmental settings. In a sense, you could just call it "Appeal".

It talks about the sudden urge coming from outside KDE to make it a desktop for sovereign nations, outside the control of the Silicon Valley. Naturally, for this to be achieved, this appeal is necessary.

"Making KDE AI-native" does not mean "Making KDE AI-first". It primarily meant a few things:

• Some users will use AI on Plasma.
• Whether a user uses AI on Plasma is optional and should stay that way.
• Users trying to use AI on Plasma (or any environment) don't feel safe.
• Therefore, a solution to this would be having a nice interface with a proper privacy-focused, sandboxed environment.

Here, "native" is a bit of a stretch, referring to "we provide the optional facilities for you to use AI safely". It also ties into the appeal trait mentioned before, using points like Nepomuk in its favor.

Naturally, the conclusion is an opinion of the presenters. And of course, this is a gross oversimplification of the talk points.

Does that mean KDE is going AI-native?🔗

No. The talk derives from the opinions of the presenters and is not a statement from KDE.

Does that mean KDE is making a stance about AI by accepting this talk?🔗

No.

Why was Omarchy mentioned at Akademy?🔗

Scott Jenson's talk Are we really going to use the same Desktop UX forever? briefly mentions Omarchy as an example of lack of innovation in UX.

One of Scott's points was that the UX hasn't changed in the desktop, and desktop Linux especially has been waiting for Windows and MacOS to make innovations to the desktop paradigm first.

The AI ecosystem is not bound to this, so they are making "new things in a weird way". Yet, Omarchy, which is deeply AI bound, does not enter this category and is another example of unchanged UX.

KDE contributors want no association with Omarchy. Nate said this in his blog post, but this is easily seen in the audience booing Omarchy when it was mentioned in the talk.

Scott Jenson's general stance about AI in the video is "we're going to improve things on the desktop, if it ends up benefiting AI too I don't care".

Are you aware of the ethical and environmental concerns surrounding AI?🔗

Yes, to varying degrees per contributor.

KDE Eco has already made a statement against AI. We have people arguing about the environmental damage caused by data centers, although I see it's the same discussion and narrative argumentation I've seen in traditional environmental talk pretty much.

The AI ecosystem is shifting towards open source, but ethically trained datasets are still a minority. We are all aware of Anthropic and Amazon buying books for scraping and subsequent destruction.

These are strong points of contention for our contributors and we acknowledge that. Not just the question of using it at all, but even the question of what constitutes ethical use in the field is blurry, which makes things difficult for us to even discuss the matter properly. Please be patient with us on that matter.

Is the proposed AI policy pro-AI?🔗

No. I'd call it "permissive of AI under strict circumstances". Very much like other policies in the FOSS world. This one was, in fact, inspired by them.

In my opinion, a pro-AI policy would simply allow AI contributions or would be in favor of AI in general, actively seeking to integrate it in core Plasma components.

Even if you do equate both terms, it would be against the fact that we are dissatisfied with the current situation, have been keeping slop out, and want to keep slop out, and want to validate that with a policy.

The terminology doesn't matter, to be honest. You get the idea from this whole post. I'll call it "permissive" for now.

Why was the proposed AI policy permissive of AI?🔗

It is an initial draft intentionally designed to guide contributor behavior, leaving a lot to interpretation.

Initial drafts are there to get input from other contributors and be improved, and to measure community expectations.

What pretty much all KDE contributors already agree with is that any slop should be rejected and if any AI contribution is made, it should be done to our highest standards and following proper professional behavior. Emphasis on "if any". Hence, the draft starts with that.

Agreement past that point is difficult because KDE traditionally does consensus-based decisions for this, and there are technical and non-technical points of nuance to elaborate and formalize the policy. Which we didn't do yet.

The draft as it stood was not a statement on what the general contributor community does or its values.

Another point to take from this is that the policy draft as it stood was stricter than the current practice. Nate mentions it in his blog and elaborates on this better than me.

Why did you remove the policy proposal?🔗

We didn't. It is confidential and locked.

The main reason why is due to bikeshedding and heated arguments. This problem was further enhanced once it was exposed on social media, but this was not the sole cause.

It would end up being locked even without outside interventions.

While mentions from non-contributors are not the sole cause for the issue locking, they aggravate the situation.

Are you ignoring non-contributing voices?🔗

No. While it is true that, ultimately, this is a contributor decision for contributors, we are aware of KDE For People, and we are aware you do not want AI in KDE software.

We ask that you be patient with us. The proposal was made with bad timing, as most main KDE contributors would soon be present at Akademy, making it difficult to commit properly.

Please wait at least a week after Akademy ends. Akademy does not last only for the first two days with talks.

A new draft proposal that should better align with the community expectations is on the way. Probably by me.

We ask that you be polite with us. These sorts of situations lead to contributors receiving email threats and trolling, and this has already happened. Nobody deserves that.

"Ultimately, this is a contributor decision for contributors"?🔗

The KDE account said it best:

Maybe this needs clarifying. "For maintainers only" does not mean that no other opinions count in the discussion, but that the policies will mostly be useful to "maintainers only".

If you are not maintaining a KDE project, these policies will not be applicable. Maybe other policies adapted to other roles will have to be developed down the line.

But, at the moment, the people who are suffering most the deluge of slop, are maintainers, so this is for them.

Furthermore, "listening to users" and "doing exactly what users say we should do" are different things. Naturally, this also means "if KDE doesn't follow what users say, they didn't listen" or "if KDE deliberates instead of taking a quick decision, they didn't listen" are fallacies.

What about the awful person commenting on the proposal and the person denouncing them that was banned first?🔗

Disclaimer: I can't say I know about this in detail, because to me it was such a non-issue. Either way, I can't explain the minutiae out of respect for our moderation team.

From what I can tell, the moderation was already steering towards the desirable result because we don't want people like that near us or our users.

The reason the person denouncing them was banned first is because they clearly broke our Code of Conduct, or process.

The other person's ban required some discussion among other moderators for Reasons™️, and some time was required to discuss this with other mods about the situation (people do live in different timezones, you know). Imagine that, wanting input from other moderators, certainly not something that has ever happened in history.

This is effectively the same explanation given by the KDE account, although I knew this before it was given:

Person A violated the internal rules of invent and was banned on the spot. Person B was banned after an investigation. The two bans were inevitable. We cannot have people violating our processes (person A) or our CoC (person B).

That person A made the ban of person B happen faster? True. But person B would've been banned sooner or later regardless.

Hint for the future: when denouncing someone, follow the community's Code of Conduct and use appropriate channels. Otherwise you do a disservice to yourself, to your own cause, and damage the community you like.

This would actually have been a non-issue that would have gone entirely unnoticed if people didn't demand immediate results on social media and literally just waited (some people even calling KDE fascists).

What should we expect from a new policy proposal?🔗

If it were up to me:

It would be more explicit about what we want and don't want, and it would educate people on how to avoid AI as well as provide a means to extend this educational resource, which is something I've seen nobody else do. Whether this is in the policy itself or in an appendix doesn't matter. We already see use of AI as a problem that hinders personal growth, and we love helping people grow as contributors.

It would keep justifications like technical reasoning, ethics and environment out, but not excluded. This means an appendix of sorts being linked in the proposal, and possibly done after the policy. This would be purely to keep the policy brief and clear.

It might not be a policy at all, but guidelines or some other sort of document.

It will probably not come immediately or be mentioned publicly, because we've had enough of harassment and "death to you and family" threats that are worse than Phoronix and Reddit comments or "apolitical" right-winger techbros, which is honestly both impressive and sad.

It would come a significant amount of time after Akademy. Imagine that: people go to Akademy, have a good time, and have no time or motivation to deal with some extrinsic force coming from social media, and are kept out of the discussion because of that? No. The people involved also need a cooldown anyway.

It would probably not be a 100% AI ban or match your full expectations, but it should at least cover your fears of KDE becoming an AI desktop (that is not going to happen). It will probably have nuance that will surprise you.

Again, it would be an initial proposal. By the time it is proposed, or soon after, don't feel anxious that it's not a 100% ban, because that's not the final result. Please wait. Anticipatory anxiety is unhealthy.

Why did Nate call KDE For People brigading in his blog post?🔗

It's his opinion of what that is, or a definition I suppose. I'll restate the obvious that it does not mean KDE as a whole thinks of it as brigading. Another obvious thing is that people can have opinions.

Note that his blog post is, well, a blog post, on his own website, using informal language and "I" pronouns, issuing a personal apology because he feels guilty and responsible for what happened, that he felt inclined to write instead of working on some Wayland thing he actually wanted to fix. Imagine actually leaking personal opinions or definitions in such a thing. Shocking!

Once again, re-stating the obvious, his blog is his words and his opinions, in case it wasn't clear from how it was framed by the KDE account as a "first-hand account".

In case you didn't read any of the comments, his definition has to do with "outside force exerting pressure onto community's decision-making". This might or might not have matched reality in this case, but it doesn't matter. You were offended by it, and this needed clarification.

He already edited it because of my input that originates from a friend that signed the petition.

24 Sep 2026 12:00am GMT

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.

I'm going to leave the comments on this post open, but I will request that everyone who wants to comment read and understand the entire post first.

So anyway…

What happened?

Here's a verifiable timeline of events:

1. Several weeks ago, a KDE developer started a mailing list thread asking about how we should handle the flood of AI slop merge requests.
2. Everyone agreed it was a problem, and that we don't want that crap.
3. There was less certainty about the best way to handle it socially.
4. Several wished for an official policy so we didn't all have to figure it out on our own.
5. I proposed a set of draft guidelines making it quite clear that slop merge requests are unwanted, and can be ignored or closed.
6. It received a generally positive reception.
7. Another KDE developer requested that we workshop it somewhere more modern and capable.
8. I got busy and didn't do so.
9. Several weeks later, various people on the internet discovered that a talk proposing "a lovable, sovereign, AI-native KDE" had been accepted at Akademy 2026 and created drama around it.
10. Akademy happened, and the talk was given to what I'm told was a fairly chilly reception.
11. The next day, a workshop was held about the topic, also receiving a chilly reception.
12. Realizing this topic was not going away, later that day I re-opened a second draft of my LLM guidelines on invent.kde.org.
13. KDE contributors began to discuss the draft proposal.
14. Two people unknown to any KDE contributors appeared and began fighting with one another about the broader topic of the morality of AI, not the proposed guidelines.
15. One of those people doxxed the other (edit: I have been informed that this is not really what doxxing is) exposed the other person's odious Twitter posts in an effort to discredit them.
16. Comments on the draft proposal were locked to only KDE developers - one of two tools that that Gitlab provides for this kind of thing, the other being to hide it entirely.
17. The person who doxxed exposed the other was banned.
18. Later, the identity of the doxxed exposed person was verified, and they were also banned for their conduct outside of KDE being so unacceptable that people inside KDE did not want to associate with them.
19. Someone else outside of KDE set up https://kdeforpeople.com in an attempt to brigade (edit: I have been convinced that this was too strong a word to use here) pressure KDE into banning LLMs.
20. A bunch of people signed onto it, almost none of whom are known KDE contributors (I see one person I know in there).
21. The topic was picked up on social media and the press with… varying levels of accuracy.
22. The draft proposal was removed and the whole topic hidden.

TL;DR:

A bunch of people mostly outside of KDE who disapprove of LLM usage derailed KDE's attempt to add restrictions to LLM usage.

Yep, that's where we're at in the state of online discourse around AI.

I'm sorry

After everything I wrote last month about keeping your community safe and containing damage so it doesn't spill out into public view, I feel pretty bad that my attempt to craft a compromise policy around LLM usage in KDE (which would have tightened it!) backfired and created a storm of drama.

It wasn't my intention, and I apologize for my role in it. If I make another attempt to craft a policy that provides certainty and cover for maintainers who want to reject AI slop, I will be even more careful to avoid creating unnecessary drama. If someone else wants to, I will try my best to help them with the same.

More facts

People jumped to some pretty wild conclusions in the various social media threads about the topic that I saw. Before we continue, let me set some more records straight:

• KDE e.V. has not taken money from DHH or Omarchy. I also have not, either personally, or in my business.
• KDE e.V. has taken money from Framework, but only after verifying that Framework had severed their (already very limited) ties with DHH and Omarchy. Also, all of this happened a year ago, before Omarchy received a ludicrous amount of money from a veritable rogues gallery of villains.
• Today, Omarchy is radioactive in KDE and adjacent communities I'm aware of. Nobody I know wants to have anything to do with them.
• The "lovable, sovereign, AI-native KDE" idea was presented by two people important to KDE in decades past, but who had not made any contributions recently besides this Akademy talk. Their idea does not reflect the overall direction of KDE or Plasma, and I don't think it ever will. If "a lovable, sovereign, AI-native KDE" freaks you out, I believe it is completely reasonable and safe to ignore.

What on earth is going on here?

I know people are really riled up about AI. I get it. The negative effects of LLM usage seem to become more obvious by the day:

• They lower the barrier to entry for people who have no idea what they're doing to DDoS FOSS maintainers with a tidal wave of crap. And this was the actual reason for the proposed restrictions.
• They make it easy for lazy people to avoid learning communication and job skills.
• They make it easy for lonely people to form unhealthy para-social relationships.
• The companies behind the big ones are really bad.
• Some of their training data was stolen.
• Some of their training data that was not stolen results in the destruction of rare books.
• The process of training them on freely available online data imposes extra hosting costs and slows down access for humans, acting as economic free riders.
• The license of source code they produce is legally unclear.
• They have been discovered autonomously hacking rival companies.
• Their resource usage frequently strains the infrastructure of the communities their data centers are located in or near.
• Their data centers are using enough electricity to blunt and reverse prior positive global trends of lower electricity demand and greener electricity generation.
• The specialized hardware they use has monopolized global production lines, massively inflating the price of normal consumer and business computer hardware.
• The enormous amount of capital allocated to them may be impossible to recoup, with the potential to eventually cause a worldwide economic crash.
• They are either mandated or voluntarily used by so many people already, that many who do not use them fear they will "fall behind" or "become obsolete" despite concerns with any of the above.

So yeah, bad stuff. I completely understand why a lot of people have problems with LLMs. I have these concerns as well.

I also understand why a lot of experts in their field really like LLMs. These are very powerful and sophisticated tools. Capable people with decades of experience can successfully automate away a lot of tedious work, and still end up with a final product identical to what they would have done by hand.

I don't use LLMs for automating work myself, but I do understand the appeal to many experts.

And I also understand that LLMs can be responsibly used in really useful ways for general tasks like learning a nebulous skill, retrieving deeply-buried information you can only describe in unspecific ways, or helping you troubleshoot a problem with unclear steps or parameters.

At the same time, I think we have to acknowledge that irresponsible LLM usage by people who are not yet experts is a disaster for their learning, expertise, social skills, and emotional health.

In other words, this is a hard problem.

What on earth do we do?

How are we expected to handle a technology that is:

1. Very powerful
2. Genuinely useful for various things
3. Dangerous, de-skilling, and/or addictive in the wrong hands
4. Full of really bad externalities
5. Broadly available worldwide at effectively zero cost

It's like 100 billion toaster-sized nuclear reactors dropped from the sky one day. The very least you can say is that this would be very de-stabilizing!

The world is changing fast and I have no idea what's going to happen. But I don't think the genie is going to be put back in the bottle. I don't know what to do, and that's scary. And I have a lot of empathy for anyone else who's scared by this, too. We're in this boat together.

What can you do to help?

If I or someone else tries again to propose a set of usage guidelines that restrict inexpert usage of LLMs, with the goal that KDE receives fewer of the AI slop merge requests that are burning people out, please don't make things worse.

Please don't derail the process.

Please don't take it as an opportunity to fight over the broader topic of AI in general.

Please don't try to burn each other to the ground over it.

Please don't actually doxx or send hate mail to anyone over it, or try to get them fired from their job.

Please, just be kind. We're all trying our best over here. No one in FOSS is a cackling techbro… outside of maybe Omarchy. The rest of us are trying to figure out what to do about the nuclear reactor that fell into our living room without killing ourselves, hurting anyone else, or becoming unemployable.

---

If at this point you want to post a comment, please be kind and treat the topic with an adult level of maturity. I believe in you.

23 Sep 2026 7:54pm GMT

We are happy to announce the release of Qt Creator 20.0.2!

The release fixes issues with the recent releases of the Android command line tools, and updates Qt Creator for changes in Xcode 27, the iOS Simulator, and Qt 6.12.0.

23 Sep 2026 1:32pm GMT

In the previous blog post I introduced Canvas2D, the new QML item in Qt 6.12 that lets you paint with JavaScript using the GPU through Qt Canvas Painter. That post was about the API: what it is, how it compares to Qt Quick Canvas and to the QCanvasPainter C++ API, and how fast it is. But that post might have left someone wondering what a real UI built with it could actually look like.

So, while testing Canvas2D (and QQEM) in preparation for the Qt 6.12.0 release, I spent a few days building a demo application to give some ideas. WatchUI is a smartwatch demo with six swipeable views, running on a 3D watch model. This is based on the smartwatch demo that was built a while back for the Qt 6.5 release. But the content of the watch screen has been reimplemented using not just QQEM effects but also Canvas2D. The demo looks like this:

23 Sep 2026 10:31am GMT

As part of the on-going development of Qt Bridges, we are out with a new beta version of Qt Bridge for Rust, with a focus on CXX-Qt compatibility and soundness. The API surface has changed in only a handful of places compared to 0.2. Where it did change, it is mostly because we removed any API we could not make sound.

23 Sep 2026 10:22am GMT

22 Sep 2026 10:00pm GMT

This year's Akademy is over - at least for me. I'm already on a train on my way back home, but there's still plenty of people staying in Graz for more days of hacking and fun. Even though I haven't contributed to KDE much in the past few years, I am really glad I decided to go.

First, I want to thank everyone from the organization and local team for hosting us in Graz and orginzing a great Akademy. I know how much work it is, so kudos to all of you <3.

I'm really happy that the community is in such a great shape. There's a lot of new people participating and contributing, which is a great sign! After all as Cornelius showed in his talk - this year we have the most people ever contributing to KDE - and the year is not even over yet!

This year we also voted the new KDE Goals. I am really happy that KDE for Enterprise goal have been voted in. As someone pointed out (with a little tongue-in-cheek): we've solved gamers, now it's time to solve enterprise. Kevin and the team in enioka Haute Couture are already doing great work on KDE PIM thanks to the Sovereign Tech Fund. They started with improving my akonadi-e2e-tests experiment and pushing it forward to a point where it has helped them discover (and fix) many bugs in CalDAV in IMAP - this is foundational work that everyone will benefit from. It's inspiring to see so much activity and many new contributors in KDE PIM again.

I attended another talk about making KDE "lovable" by Eva and Jan. They discussed many things, but one that stood out to me, especially with relation to the Enterprise goal, is that we should make sure that the end-users, those who actually use our software in organizations, feel like they gained something by migrating away from whatever they were running on before and were used to. They should feel our software makes their jobs easier, makes them more efficient and feel like it adapts to their needs - make it not just usable, but /lovable/. I really liked that thought. How do we make KMail loveble, though? That's a tough one…

As for myself, I had a lot of schnitzels over the couple days, took a slide down from Schlossberg, fixed some bugs and generally had a great time. I managed to get KMail, KOrganizer and KAddressBook to compile and run on macOS to the point that I can actually read and write emails. But there's a lot of fixes and polish needed still, more on that some other day.

All in all, it was a very fun, very productive and very inspiring Akademy for me, and I can't wait to see everyone again.

21 Sep 2026 4:00pm GMT

We just merged a code change in Okular master to use QtMultimedia instead of Phonon to play multimedia files.

This will be released in December.

We did as much testing as we could but given the complexity of this feature it would be nice if users could test it as much as possible.

If you have PDF files with video or audio files it would be great if you could install this flatpak file https://invent.kde.org/graphics/okular/-/jobs/5052739/artifacts/raw/okular.flatpak (may be out of date in a few days, write a comment if you want to test and the file is no longer available).

You can install it with flatpak --user install once downloaded (it should not conflict with neither your distribution installed Okular nor if you have a stable Okular flatpak installed)

Then you can run it with flatpak run --branch=master org.kde.okular

Once you do that do as much testing as you can with PDF files with embedded audio/video. If you find bugs (specially if they are regressions against the current version) please report the issues in bugs.kde.org

21 Sep 2026 3:59pm GMT

I've been writing a lot of documentation recently - including almost all of KDE Linux's docs, as well as the KDE human interface guidelines.

And I'm at Akademy 2026 right now where the cat is out of the bag - one of KDE's three latest goals is about documentation! Thiago, Joseph, and I will be tackling this:

Ahh documentation… everyone's favorite topic. We all just love reading it - and even more, writing it, right?!

Yeah, I didn't think so. Like a vacuum cleaner or a dental X-ray, documentation may be sometimes necessary, but you want to interact with it as little and as quickly as possible, then forget about it.

So this goal is not really about writing more documentation, but rather better documentation.

To that effect, I'd like to share some guidelines I try to follow and that I'd like to guide our work when writing software documentation:

1. Don't

The best documentation is no documentation.

There's a famous XKCD comic about it:

The software's usage should be blindingly obvious, or at least generally self-explanatory. Aim for this platonic ideal in the software itself.

You'll fail, of course. But the effort will improve your software and let you get away with writing much less. Anything you have to document how to do is clearly something that could be more obvious or more automated!

2. Make it easy to find

Documentation in the software itself is better than on some website. Make heavy use of descriptive labels, subtitles, and help buttons. Put explanatory comments in config files.

For web documentation, link to it everywhere. Don't assume the user will find it easily!

3. Keep it actionable

People only read documentation after exhausting all other options. By the time they arrive, they're tired and cranky.

Front-load the answer they're looking for, and get to the point fast. Quick tutorials are better than manuals, lectures, or history lessons. Don't just explain what every button does - this should be obvious (see #1).

Add copious amounts of copy-paste-able sample code, especially in API documentation.

4. Keep it short

Endeavor to minimize the unnecessary wordiness of the text that the reader will be reading, in order to maximize the likelihood that they will succeed in locating an example of the specific information that they were seeking.

See how horrible this is? Your readers will want to beat you in the neck with a cactus.

Keep sentences short. Use "the", "a/an", and "that" as little as possible. Don't repeat yourself.

Use lots of line breaks to avoid exhausting walls of text.

Don't over-document; obvious things don't need to be explained. You only need to cover topics that readers keep having trouble with - and that reveals flaws in the software; see #1.

5. Phrase it readably

Use the imperative mood and the active voice. Tell the reader what to do! It's why they're reading. Write naturally, and don't be too formal.

Use bold text to help readers skim by highlighting the most important parts of longer paragraphs or bulleted list items - especially their opening sentence or clause.

6. Organize it simply

Use a linear flow, not a branching flow. Nobody can get lost going linearly from start to finish. Aim for one level of organization with no nested sub-pages.

Organize each page's text into sections with descriptive headings so the reader can skim to the exact part they're looking for.

When multiple options for how to do something are available, choose one to be the official recommendation. Only mention alternatives later, in a de-emphasized manner.

Provide a table of contents; Ctrl+F on that page should be useful.

---

This is a surface-level treatment, of course. Even if the final product should be small and focused, the way to get there is a vast topic. So consider it a sneak peak of one of the thrusts of the goal, and thank you to everyone who voted for it!

21 Sep 2026 7:36am GMT

OK, it's been a while since I blogged about community data analytics… I thought I'd do more posts on the matter but somehow never managed to get back to it. Now it's a bit more than 6 years since my last post on the topic!

Worry not though I didn't loose touch. Indeed I still hone this skill professionally since it's an excellent source of information to better target audits or to give better advice when consulting on software architecture. This is by the way exactly what my last post on the topic was about. But this is not what we're here for today!

Indeed, in a few weeks, KDE will turn 30 years old. This is impressive in terms of longevity for such a community. We've fostered a very diverse group, people are coming and going of course… So where does KDE stand? Are we looking at 30 more years or is it on a darker path?

It took a quick look at how KDE has been growing and shrinking as part of a post about communities size and activity. It was a quick peek only (I needed to look at other communities too) and 8 years ago. Time to revisit it all and with more details! Time to brace yourselves, it shall be a somewhat long read, we have 30 years to explore, but more importantly we'll look at several subcommunities separately.

Choices, improvements, and caveats

For this article I made a couple of choices. I decided to give the current article the same angle than the 2018 one about communities size and activity. So I won't show some of the more advanced diagrams I can produce and will stick only to the easy to read "team size" diagram and the "activity" diagram (the beloved "colored blobs" diagram).

For the latter, I also decided to anonymize the contributors, so no need to zoom to try to find your name, you won't. I generally leave them when I'm doing more focused work since we mostly know who is working in a given team, but here I'll be casting a very wide net and I don't feel some people to feel uncomfortable because their name appears. Hopefully this should limit ego trips.

Note however, that behind the curtain I did produce "contributor network" diagrams (more advanced, more expensive, harder to read) without anonymization. They won't be included in the article, but if I happen to mention some people, it'll likely come from prior knowledge that I validated through those diagrams.

The last choice I made which deviates from previous explorations is how I map identities. I usually went for names and used manually curated rules to normalize such names. Some people are not really consistent there with sometimes three or more variations (looking at you Aleix 😉) hence those rules. Now doing this for all of KDE over 30 years… let's say I didn't have the time to update my rules this time around. Also, we're having more company sponsored development nowadays so I decided to use emails. That means for instance that I represent two different contributors depending if I'm using my kde.org or my enioka.com email address. It doesn't seem to skew too much the data, probably less than not having normalized names. For finer grained explorations it also helps figure out if a given contributor was doing something on company time or his own time (not everyone has that discipline but so be it).

Now let's talk about improvements compared to previous related articles. Roughly speaking I tended to look only at repositories with C++ in them: libraries and applications. This time, I changed how I built my corpus of repositories (the switch to GitLab made things easier too) and I'm covering as wide as I could. It's important because we're doing more packaging work nowadays and also we can get a glimpse to the sysadmin activity.

But that's also where lay the caveats…

I didn't include the kdelibs repository this time, to reduce chances of counting some of the commits happening during the KDE Frameworks transition twice. This means we'll have the very early history missing and the one we have will be underestimated a bit. But from previous explorations this shouldn't distort things too much or change the trends we're going to see anyway. I double checked this by also running experiments with kdelibs included on the side so I'm not worried. It's worth keeping in mind though as if you use a fine enough comb you might spot tiny discrepancies.

Another problem to keep in mind is that I had to exclude the KDE Neon repositories. This is quite unfortunate but the majority of them started as forks coming from Debian or Ubuntu and so they pulled many commits unrelated to our community activity. The volume of those commits was unfortunately high enough that it'd completely skew the data at important points in time to have a readable history. Sadly I couldn't figure a way to reliably sort between the commits to keep and the ones to reject hence why I left it completely out. Still it is something to keep in mind as well: later years are slightly underestimated. Hopefully not by much but I have no way to check.

However the Snap packaging and KDE Neon Core efforts are included as those were easy to split from the rest.

OK… with all those disclaimers out of the way time to look at the result.

30 years of KDE history

First let's take a look at the teamsize plot for the whole community. It is an updated version from my 2018 post. Back then it was the only one we looked at. Of course, keep in mind I did things slightly differently as explained in the previous section.

What can we see here? (I recommend looking at the full page version for all the plots) First striking thing is a similar profile to the plot I did in 2018 for the 1997 to 2018 period. Which is good news: what I wrote in 2018 isn't invalidated by the adjusted and improved method I used for data collection.

Back then I noted that the active part of the community had been growing all the way to 2010 then started to shrink again. This is what we see, it peaks around 180 on average (and sometimes reaches towards around 200 people) then shrinks again hitting bottom around 110 persons on average in 2017.

We had no definite answer about why we'd seen this decline. The best shot we had is work done by Paul Adams and presented at Akademy 2014 pointing out that the community cohesion started to drop around the same time. This kind of pointed to the switch to git which could have demotivated some of the existing contributors. Also we didn't have a really good forge on top, so it was harder to have a consolidated view of what was happening in all of the repositories IMHO.

Alright, but 2017 is almost ten years in the past… Since then, we had two major events happening. First, 2018 is the year where we had the first set of KDE Goals being picked by the community, one being "Streamlined onboarding of new contributors". Second, we had the transition to GitLab which was fully delivered early in the second quarter of 2020.

Interestingly, we see the team size starts to pick up again towards the end of 2017. This is around the same time as the beginning of the KDE Goal process leading up to the first set of goals being selected in November 2017. It is also when we worked on the KDE Vision refresh. Around this period we don't see the commit count pick up though (the entry count line), the new people probably joining at the time don't quite compensate earlier losses.

Then later on, we see the team size growing again but this time the commit count is picking up too. It is between the end of 2019 all the way to mid-2020. Could it be helped by the GitLab switch? In any case, this is very good news, in my 2018 post I wonder if KDE would stabilize around the lower value of the time or pick up again… It definitely picked up again!

Now it seems like the team size if around 140 people on average, so closer to the all time high of 2010 but we didn't fully close the gap yet. Interestingly though, the commit count is much closer to the one we had in 2010, with a bit less people. We even had an all time high commit count in 2023 which surpassed any other week since the creation of the project.

And to make things even brighter, the trends at the end of the plot point upwards. Looks like 2026 will be a very good year. Hopefully the growth will stay stable this time and then the community will be the biggest it's ever been.

Now let's take another point of view.

This is our activity plot for the whole history of all of KDE. This is our colored blobs, I won't focus much on the colors this time, it just says we have some contributors who are constant outliers in their activity. It's not news and I'm not going to point them out.

Much more interesting is the shape of those blobs. The "bottom envelope" forms a curve and if we look at the angle it has, it is becoming more and more vertical. It's not always the case we see some inflexion points if we zoom in, but on the whole history it definitely becomes steeper. Including towards the end of 2025 and through 2026 we see it changing again reinforcing the same trend.

This means we're seeing more and more new contributors. KDE is recruiting new contributors and does so faster and faster. But is it only drive by contributions or people staying for longer?

This is were what's on the other side of the curve, the actual blobs get interesting. If it's not very dense and we see "lots of gray" it means people contribute a bit then stop. If it's dense it means they're staying around much longer or "forever". To me, it started to get denser around 2019. So not only KDE is recruiting faster, but it's retaining contributors for longer. It's of course not at dense as in the early days but it's likely the best you can do with such an old, large, and diverse community.

So altogether, I would say that KDE is a community which struggled between 2010 and 2017. It shrunk in the process but has been recovering since then. It feels very strong right now and could surpass the all time high it had in the past if the conditions are right. There are first signs of this: more commits per contributor, recruiting more, and better retention.

Looking a bit closer

At least we established that the forest (the whole KDE) is likely healthy. It doesn't tell us much about individual trees though. Even healthy forests have diseased trees and that's OK. Still for our exploration I think it's good that we reduce the scope a bit and look at sub-communities within KDE to see how they fare.

KDE Frameworks

Looking at KDE Frameworks the teamsize plot seems to tell a very different story than KDE as a whole. There are obvious similarities though. It's mostly growth since the beginning and until 2010, the slope on that post is not as steep but remember the caveats. Since I didn't include the kdelibs repository we miss some commits in the early history.

We find the same dip starting in 2010, but there's a first big difference. It rebounds strongly and much earlier! Around 2012 it picks up already and reaches all times high in 2014. There I immediately know how to explain it because I was right in the middle of it.

We knew we were reaching the limits of the kdelibs model and in 2011 we had the Platform11 meeting. This is where we planned to turn kdelibs into KDE Frameworks. So for us a slow down in the kdelibs area was only natural we were busy making the necessary plans for the architectural transition. The transition itself began to be executed a bit later culminating in 2014 with the release of KDE Frameworks 5.0.

Hence the new dip we see just after. Everyone was tired and things were getting back to normal. By 2015/2016 the activity level was already back to the activity level of 2010.

This explains why I was kind of surprised by Paul's talk in 2014… I was buried deep in KDE Frameworks and everything looked fine from there.

Which leave us now with the period of the GitLab transition. When it's fully in effect (2020) KDE Frameworks also grows just like the whole KDE community. It's oscillating a bit but it looks like it stabilized there.

On the side of the activity plot, we see an overall acceleration in recruiting since the very beginning but it has clear periods of slowing down. Towards the end we find the same profile than for the whole of KDE: it looks like it's accelerating further in 2026.

That being said in terms of retention, KDE Frameworks isn't as good as KDE as a whole. But maybe it's fine, it's the base of all the projects and by its nature it likely attracts more drive by contributions than anywhere else in the community. We want to mutualize and that's what people seem to be doing.

This product is not very noisy and just happily churns along it seems.

KDE PIM

KDE PIM clearly has a more complicated history. It starts to mostly grow like the rest of KDE all the way to 2004 and then has a first clear dip in team size starting in 2004. It took three years to recover from it. I'm not sure what caused it… I wonder if it's related to the great KMail maintainer war I hear about from time to time? It was before my time getting involved in KDE PIM.

Anyway, once the project recovered in 2007 things seem to be going along well with even a small spike in team size and larger spike in commits around 2009. If my memory serve this is when KDE PIM had seen some serious funding last. Then it dives like the whole of KDE around 2010.

It starts to pickup a bit again during the GitLab transition, but not as dramatically as the whole of KDE so something else must sustain that community wise increase. This is a common pattern for the whole of our applications by the way (I did plot it but didn't include it here as this is already way too long).

One reason to rejoice is the increase of both team size and commits building up in 2026. With some of my colleagues, we might have something to do with this and I'm fairly happy about it. It's likely not the only factor of course, as I mentioned earlier it looks like 2026 will be a particularly good year for KDE as a whole.

In term or recruiting and retention, KDE PIM is a bit at risk I'd say. Clearly there's been a slow down in recruiting new contributors starting in 2015. It looks like it's slowly getting better catching up to earlier times but it took ten years to get there and it's too early to see if it'll sustain it.

In term of retention… let's face it, it's never been great nor improving. There's a few individuals who stay around but not many. There's clearly something pushing new contributors away preventing them to stay for long. For the nature of the product it raises questions. I have theories but no definitive answer so I won't share them here.

What's sure is that KDE PIM needs more involvement going forward to be sustainable.

Plasma

Time to our flagship product: Plasma. The plots here include desktop, mobile, and big screen repositories. Note the very early history can't be trusted, clearly it inherited commits from before Plasma was a thing.

Anyway, in terms of team size it's been almost constantly growing. We find the 2010 dip but it's much less dramatic than in all the other plots. It stabilized much quicker and managed to stay with an almost identical team size.

We also find the increase leading up to 2020. And clearly it's one of the projects which benefitted the most of the GitLab transition. It's average team size almost doubled during the transition!

Earlier I asked where the increase we could see on KDE as a whole but not on applications was coming from? Well, this is probably it.

Like the rest of KDE, 2026 will be a very good year for Plasma as well. I wonder… will it double in size again next year compared to 2020?

Unsurprisingly recruiting is going well in Plasma if we look at the activity plot. Now the retention has been somewhat spotty, but clearly it's improving: the density increases as we go down. Keep up the good work I'd say!

KDE Linux

Time to look at the new kid on the block: KDE Linux. There's been a lot of PR and expectations around this one but keep in mind it's still young (history starts in 2023). We don't have many data points yet so it's a bit more difficult to draw conclusions.

Clearly so far it's been growing in term of team size. This is good. That said, it is rather smaller than I'd expect from the exposure the project gets. This can be a good thing if it's because we have a high impact team. But it can be a bad thing if it's a sign of hyping things up before they're truly ready to have a bigger team. Time will tell I guess.

What worries me a bit more is that the commit count doesn't seem to pick up as fast as the team size. Again, we need more data and history to be sure there is a problem. But I'm wondering if we're seeing early difficulties to synchronize within the team which is eating away at what could be produced. It might be a sign of some growing pains having a hard time to make newcomers truly productive.

The activity plot seems to go in the same direction as my questioning above. The project has been recruiting faster towards the end of 2025 and this year. At the same time its retention rather diminished it seems. It could be again a sign of newcomers not finding their place or simply only motivated by drive by contributions.

Community wise it looks like KDE Linux is off to a good start but needs to strengthen its path on how to get involved.

Conclusion

This article turned rather longer than I anticipated, sorry about that!

We had a quick tour through 30 years of commit data. I would have liked to also process merge requests but at this scale it's very time consuming so maybe I'll do it another time on something more focused.

In any case, I'm rather happy that KDE as a whole seems very healthy. The last time I did such an exploration we left things undecided wondering if the community would ever recover from "the big 2010 dip in activity". I would argue it did and with a few more years like 2026 we could expect to even go above the 2010 levels. We're seeing early signs of it I think.

As for the projects we explored, flagship products (KDE Frameworks and Plasma) are doing rather well, for the other ones… your mileage may vary, it depends where you look. KDE PIM clearly has long term challenges it needs to overcome while KDE Linux raises questions but nothing unsurmountable. For both there's likely some community work to be done, something need to be done to have a better retention of contributors.

I'd loved to also zoom in on Krita, Kdenlive, Elisa, etc. There are so many products in KDE!

So it looks like in almost 30 years KDE built a great community and many awesome products. We're really forming a large and diverse family. Like any large families it can get sometimes ugly or messy but keeping the ties matter. Kudos to all the people involved for the past 30 years! Even if you're not involved anymore you helped contribute something beautiful and precious to the world. We're the living proof that large commons can be created and made sustainable thanks to passionate people.

19 Sep 2026 7:12am GMT

Welcome to a new issue of This Week in Plasma!

This week, Plasma folks shifted to bug-fixing and polishing work for Plasma 6.8. As of the time of writing, there are only four open regression reports for Plasma 6.8, which means either the release is already amazing, or people aren't testing the beta release enough! You know what you need to do. :)

Also, notice that we have bug fixes going into four concurrent Plasma releases right now. FOUR! That's a lot of release management, but it seems like the Plasma team is up to the task!

Notable UI improvements

Plasma 6.7.6

System Settings' Wi-Fi & Networking page now fully fits within the window at its default and minimum size. (Marco Martin, KDE Bugzilla #443553)

Plasma 6.8

On KWin's Overview effect, highlights for adjacent virtual desktops no longer touch. (Nate Graham, KDE Bugzilla #523656)

Kup's backup progress notifications now show the elapsed time, and average speed information is now more accurate. (Méven Car, kup MR #62)

Did another few rounds of visual polish on KDE's desktop portal dialogs to increase their information density and visual consistency. (David Edmundson and Oliver Beard, xdg-desktop-portal-kde MR #628 and xdg-desktop-portal-kde MR #630)

Plasma 6.9

Renaming a file or folder on the desktop now shows all the standard warnings and confirmations when necessary. (Ramil Nurmanov, plasma-desktop MR #3684)

The Weather Report widget now warns you when the weather provider you've chosen might report less data than you would expect. (Ismael Asensio, kdeplasma-addons #1127)

In the Clipboard widget, buttons to invoke actions now only appear for entries that have actions associated with them. (Tomáš Hnyk, KDE Bugzilla #440727)

On System Settings' Wi-Fi & Networking page, the "speed" setting has been renamed to "speed limit" to clarify its purpose. (Fernando Marcelino Muniz, KDE Bugzilla #523099)

Notable bug fixes

PulseAudioQt 1.9.0

Fixed a very odd issue whereby multiple audio devices could end up in a "selected" state, making it unclear which device was actually the default one, and impossible to change it. (Harald Sitter, KDE Bugzilla #500968)

Plasma 6.6.7

Fixed a bug that could make the login screen fail to appear if no screens were present early in the boot process, and connected later. (Oliver Beard, KDE Bugzilla #520720)

Fixed a bug that could occasionally make Plasma crash on login, seemingly randomly. (David Edmundson, plasma-workspace MR #7042)

Fixed an old bug that could make Plasma crash seemingly randomly when something made a System Tray item animate in just the right way at just the right time. (David Edmundson, KDE Bugzilla #487699)

Fixed a recent regression that de-synchronized the brightness level shown in the System Tray widget and the brightness OSD. (Christoph Wolk, KDE Bugzilla #523281)

Transition times for the Night Light feature are now shown correctly in the Brightness & Color widget when Night Light is configured to be always on. (Vlad Zahorodnii, powerdevil MR #678)

Plasma 6.7.6

Fixed a bug that could occasionally make KWin crash when you returned to a game using Alt+Tab. (Vlad Zahorodnii, KDE Bugzilla #510116)

Fixed a focus-related regression with Wine windows. (Vlad Zahorodnii, KDE Bugzilla #525590)

The Clipboard widget no longer disappears from the System Tray when its panel is over 100px thick. (Tomáš Hnyk, plasma-workspace MR #7048)

Plasma 6.8

Fixed a bug that could sometimes make KWin crash when interacting with titlebar buttons in very specific ways. (Vlad Zahorodnii, kwin MR #9926)

Fixed a very weird bug that could make Plasma hang on login when the computer was connected to a monitor with a non-standard VCP range, such as the Samsung Odyssey G60SF. (Marco Martin, KDE Bugzilla #525216)

Deleting three or more items at a time from the Menu Editor app no longer makes it crash. (David Edmundson, KDE Bugzilla #525598)

Unit conversions in KRunner-powered searches now work in French. (Tobias Fella, KDE Bugzilla #510873)

Plasma 6.9

When Plasma Browser Integration sends a notification about files downloaded using a Firefox-based browser packaged as a Flatpak, the file path that it shows is no longer garbled. (Bharadwaj Raju, KDE Bugzilla #524384)

Made Plasma Browser Integration more robust at exporting album art from a compatible browser to the Media Player widget. (Takashi Kashiwagi, KDE Bugzilla #514788)

Fixed a subtle incompatibility between Plasma's Edit Mode and the popular Conky system monitoring widgets. (力文 胡, KDE Bugzilla #525792)

Notable in performance & technical

Plasma 6.8

Plasma no longer writes to a cache file every single time it displays a notification. (ValdikSS, KDE Bugzilla #523805)

How you can help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

Would you like to help put together this weekly report? Introduce yourself in the Matrix room and join the team!

Beyond that, you can help KDE by directly getting involved in any other projects. Donating time is actually more impactful than donating money. Each contributor makes a huge difference in KDE - you are not a number or a cog in a machine! You don't have to be a programmer, either; many other opportunities exist.

You can also help out by making a donation! This helps cover operational costs, salaries, travel expenses for contributors, and in general just keeps KDE bringing Free Software to the world.

To get a new Plasma feature or a bug fix mentioned here

Push a commit to the relevant merge request on invent.kde.org.

19 Sep 2026 12:00am GMT