KDE and AI, and you, and me

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

Keep your community afloat with the right defense tokens

My favorite tabletop game of all time is Star Wars: Armada, a Star Wars themed ship combat wargame.

Armada has many deep and tactically interesting features, but one of my favorites is the unique suite of defense tokens available to each spaceship to protect itself against attacks, from among the following six options:

  • Scatter – the attack is completely canceled. “I wasn’t where you were shooting”
  • Evade – cancel an attack die at long range, or re-roll one at short and medium range. “I dodged your attack, so it missed or became a glancing blow”
  • Brace – halve the damage. “Ouch, you hit me! But it wasn’t as bad as it could have been”
  • Redirect – move some damage to an adjacent hull zone. “You hit me, but not where I was weakest”
  • Contain – downgrade a critical hit to normal damage – “My damage control efforts turned the potential catastrophe into just a normal crisis”
  • Salvo – return fire. “You hit me, but I hit back”

There’s way more information here for people whose military nerd curiosity has been piqued.

Anyway, this is well and good for games about spaceships, but what’s the relevance? Let’s imagine that we humans have these defense tokens, too. And today I’d like to talk about how they relate not to physical attacks, but interpersonal ones.


You negligent fool! You nit-picking jerk!

Someone has blindsided you with unexpected criticism! The monkey brain sees this as an attack:

Red alert! Shields up! All hands to battle stations! Your blood pressure rises. You see red and gear up for a fight:

And what’s the most satisfying defense token to use? Salvo, for sure. Hit back:

Oh yeah, that’s pretty rich coming from you given how you messed up that other thing last week!

The angry email. The “call-out” social media post. The sharp reply on chat. The hyper-critical blog post. They feel good, right?

But Salvo doesn’t actually avoid any damage. in Armada, if you Salvo every attack, your ship explodes, with the only other effect being that the attacking ship gets hurt too — usually a lot less.

From the perspective of minimizing interpersonal friction in a group setting, Salvo is the worst defense token. It didn’t end the conflict created by this unexpected criticism; in fact, now the conflict is bigger and louder, because the criticizer has also gotten hurt. Other people may leap to their defense, or yours, and pretty soon the battle lines are established. What started as a community soon feels like a war zone.

Redirect isn’t great, either; in a community context it’s basically blame-shifting, which similarly doesn’t prevent any damage; it just moves it around, and the community still suffers.

Neither is is not what we want for our community if the goal is to remain friendly and welcoming!

Prevent and reduce damage

If we want to keep our ship flying community alive, we need to prefer the defense tokens that prevent or reduce damage:

  • Scatter: prevent conflicts in the first place by meeting expectations, being mindful of other people’s feelings, and maintaining your relationships.
  • Evade: notice impending conflicts and help make them fizzle out early. Be humble.
  • Brace: mend fences and fix problems so the conflicts that do erupt shrink over time.
  • Contain: keep conflicts localized to the participants, and prevent them from spiraling out of control. Don’t let drama spill out into the larger team or the whole organization — or heaven forbid into the media! Accept valid criticism and let others have the last word.

These social defense tokens are harder and less satisfying to use than Salvo and Redirect. But over the long term, they do a much better job.

Which brings us to KDE

Today I think KDE is known as a pretty friendly place. And when I look around, I see a lot of examples of people ­— consciously or unconsciously — using defense tokens in their interpersonal relationships that reduce harm rather than moving it around or sending it back.

It’s not perfect, of course. We all mess up sometimes. And a culture like this takes years to develop. But I think the strong social bonds between contributors inside KDE are self-evident, and represent a significant part of the organization’s success today.

So I want to congratulate KDE and encourage us all to keep it up! I know times are tough and a lot of things in the world feel like they’re exploding, or getting ready to. Things suck more than they should, and there’s always more we can do to improve it. But as long as we maintain our relationships with one another, it becomes a lubricant that makes all those things so much more possible to survive or achieve.

Analyzing KDE Project Health With git!

I was reading the latest edition of Kevin Ottens’ excellent weekly web review and one particular article caught my eye: “The Git Commands I Run Before Reading Any Code“. In a nutshell, you can use the git version control tool to quickly assess a project’s health, what breaks, who’s a key figure, how bad emergencies are, and so on.

So useful!

I immediately wanted to apply this to KDE projects. So I took the commands from the post and made some shell aliases and functions for convenience:

# git repo analysis tools
alias what-changes="echo 'What changes a lot?' && git log --format=format: --name-only --since='1 year ago' | rg -v 'po$|json$|desktop$' | sort | uniq -c | sort -nr | head -20"
alias what-breaks="echo 'What breaks a lot?' && git log -i -E --grep='fix|bug|broke|bad|wrong|incorrect|problem' --name-only --format='' | sort | uniq -c | sort -nr | head -20"
alias emergencies="echo 'And what were the emergencies?' && git log --oneline --since='1 year ago' | grep -iE 'revert|hotfix|emergency|urgent|rollback'"
alias momentum="echo \"What's the project's momentum over the past 5 years?\" && git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c | tail -n 60"
alias maintainers-recently="echo \"Who's been driving this project in the past year?\" && git shortlog -sn --no-merges --since='1 year ago' | rg -v 'l10n daemon script' | head -n 30"
alias maintainers-alltime="echo 'And what about for all time?' && git shortlog -sn --no-merges | rg -v 'l10n daemon script' | head -n 30"
function repo-analysis {
what-changes
echo
what-breaks
echo
emergencies
echo
momentum
echo
maintainers-recently
echo
maintainers-alltime
}

Now let’s run it on Plasma. Here’s plasma-workspace, the core of Plasma:

$ git clone ssh://git@invent.kde.org/plasma/plasma-workspace.git
$ cd plasma-workspace
$ repo-analysis
What changes a lot?
  1519  
    38 CMakeLists.txt
    29 shell/shellcorona.cpp
    24 runners/services/servicerunner.cpp
    21 wallpapers/image/imagepackage/contents/ui/config.qml
    19 libnotificationmanager/notifications.cpp
    18 shell/org.kde.plasmashell.desktop.cmake
    18 devicenotifications/devicenotifications.cpp
    17 kcms/lookandfeel/kcm.cpp
    16 wallpapers/image/plugin/model/packagelistmodel.cpp
    16 kcms/cursortheme/xcursor/xcursor.knsrc
    15 wallpapers/image/plugin/model/imagelistmodel.cpp
    15 applets/notifications/global/Globals.qml
    15 applets/devicenotifier/devicecontrol.cpp
    14 wallpapers/image/plugin/imagebackend.cpp
    14 shell/panelview.cpp
    14 .kde-ci.yml
    14 applets/systemtray/systemtray.cpp
    13 runners/services/autotests/servicerunnertest.cpp
    12 krunner/qml/RunCommand.qml

What breaks a lot?
   225 shell/shellcorona.cpp
   183 shell/panelview.cpp
    83 CMakeLists.txt
    74 applets/systemtray/package/contents/ui/main.qml
    71 applets/digital-clock/package/contents/ui/DigitalClock.qml
    63 klipper/klipper.cpp
    62 applets/notifications/package/contents/ui/NotificationItem.qml
    58 wallpapers/image/imagepackage/contents/ui/config.qml
    56 shell/desktopview.cpp
    56 libtaskmanager/tasksmodel.cpp
    54 shell/main.cpp
    54 applets/systemtray/systemtray.cpp
    53 shell/shellcorona.h
    52 krunner/view.cpp
    48 applets/digital-clock/package/contents/ui/CalendarView.qml
    47 runners/services/servicerunner.cpp
    46 wallpapers/image/imagepackage/contents/ui/main.qml
    45 applets/notifications/package/contents/ui/NotificationPopup.qml
    44 applets/systemtray/package/contents/ui/ExpandedRepresentation.qml
    43 startkde/startplasma.cpp

And what were the emergencies?
4f526a7bd1 Revert “applets/systemtray: Prevent popups from overlapping with the panel”
dca5788fee lookandfeel/components: Revert Plasma::setupPlasmaStyle
2c0fd34541 Revert “ContainmentLayoutManager: send recursive mouse release events too”
b6b230f4ff Revert “Read selenium-webdriver-at-spi-run location from CMake”
b8651b56f6 hotfix: Remove doc translations without actual doc
1f43f576e8 Revert “Add forceImageAnimation property to force animated image play”
f0349b6c81 hotfix: remove stray .po file
3ff7ae4269 Revert “CI: enable parallel testing”
83bebc7896 Revert “Limit evaluateScript execution at 2 seconds”
4f45f672be Revert “kcms/componentchooser: Don’t offer NoDisplay services”
3bf0ff8f56 Revert “Disable linux-qt6-next while the regression in Qt gets fixed”
80996f0633 Revert “kcms/wallpaper: set roleNames for WallpaperConfigModel”

What’s the project’s momentum over the past 5 years?
   148 2021-05
    87 2021-06
    62 2021-07
    85 2021-08
   121 2021-09
   106 2021-10
   146 2021-11
   190 2021-12
   191 2022-01
    84 2022-02
   168 2022-03
   130 2022-04
   146 2022-05
   141 2022-06
   136 2022-07
   107 2022-08
   232 2022-09
   234 2022-10
   181 2022-11
   150 2022-12
   154 2023-01
   161 2023-02
   156 2023-03
   156 2023-04
   163 2023-05
   137 2023-06
   186 2023-07
   190 2023-08
   275 2023-09
   226 2023-10
   283 2023-11
   157 2023-12
   131 2024-01
   147 2024-02
   249 2024-03
   180 2024-04
   188 2024-05
   158 2024-06
   128 2024-07
   146 2024-08
   169 2024-09
   156 2024-10
   116 2024-11
    98 2024-12
   145 2025-01
   126 2025-02
   120 2025-03
   116 2025-04
   131 2025-05
   131 2025-06
   132 2025-07
   115 2025-08
   110 2025-09
    97 2025-10
   147 2025-11
   114 2025-12
   140 2026-01
   131 2026-02
   119 2026-03
    44 2026-04

Who’s been driving this project in the past year?
  116  Vlad Zahorodnii
  113  Nicolas Fella
   87  Christoph Wolk
   82  Fushan Wen
   78  Nate Graham
   66  Kai Uwe Broulik
   48  Bohdan Onofriichuk
   37  Harald Sitter
   34  Tobias Fella
   31  Marco Martin
   30  David Edmundson
   25  Akseli Lahtinen
   21  Ismael Asensio
   17  David Redondo
   16  Niccolò Venerandi
   15  Bhushan Shah
   11  Alexander Lohnau
   11  Kristen McWilliam
    9  Oliver Beard
    9  Shubham Arora
    8  Alexey Rochev
    8  Han Young
    8  Philipp Kiemle
    7  Albert Astals Cid
    6  Aleix Pol
    6  Méven Car
    5  Devin Lin
    5  Joshua Goins
    4  Alexander Wilms
    4  Arjen Hiemstra

And what about for all time?
 1543  Fushan Wen
 1497  Marco Martin
 1374  Kai Uwe Broulik
 1030  David Edmundson
  772  Nate Graham
  658  Alexander Lohnau
  551  Aleix Pol
  548  Nicolas Fella
  438  ivan tkachenko
  385  Eike Hein
  264  Sebastian Kügler
  250  Martin Gräßlin
  238  Harald Sitter
  232  Martin Klapetek
  223  Jonathan Riddell
  207  Vlad Zahorodnii
  194  David Redondo
  190  Friedrich W. H. Kossebau
  189  Laurent Montel
  144  Bhushan Shah
  134  Christoph Wolk
  134  Ismael Asensio
  126  Lukáš Tinkl
  121  Niccolò Venerandi
  117  Méven Car
  105  Natalie Clarius
   91  Konrad Materka
   80  Vishesh Handa
   80  Volker Krause
   79  Ivan Čukić

ShellCorona both changing and breaking a lot is no great surprise to me; it’s fiddly and complicated. We need to do something about that. The number of emergencies doesn’t look too bad, and momentum feels fine too. The project also appears to have a nice healthy diversity of contributors. Excellent!

It’s been quite illuminating to run these tools on KDE projects that I’m both more and less familiar with. Give it a try!

About Plasma’s X11 session

X11 is in the news again, so I thought it would make sense to be clear about the Plasma team’s plans for X11 support going forward.

Current status: Plasma’s X11 session continues to be maintained.

Specifically, that means:

  • We’ll make sure Plasma continues to compile and deploy on X11.
  • Bug reports about the Plasma X11 session being horribly broken (for example, you can’t log in) will be fixed.
  • Very bad X11-specific regressions will probably be fixed eventually.
  • Less-bad X11-specific bugs will probably not be fixed unless someone pays for it.
  • X11-specific features will definitely not be implemented unless someone pays for it.

This is actually not too bad; there are relatively few open and fixable X11-specific bugs (0.76% of all open bug reports as of the time of writing), and when I went looking today, there were only two Bugzilla tickets requesting new X11-specific features that needed closing. Most bugs and features are platform-agnostic, so X11 users will benefit from all of these that get fixed and implemented.

Eventually it’s lights out for X11 though, right? When will that happen?

Yes, the writing is on the wall. X11’s upstream development has dropped off significantly in recent years, and X11 isn’t able to perform up to the standards of what people expect today with respect to HDR, 10 bits-per-color monitors, other fancy monitor features, multi-monitor setups (especially with mixed DPIs or refresh rates), multi-GPU setups, screen tearing, security, crash robustness, input handling, and more.

As for when Plasma will drop support for X11? There’s currently no firm timeline for this, and I certainly don’t expect it to happen in the next year, or even the next two years. But that’s just a guess; it depends on how quickly we implement everything on https://community.kde.org/Plasma/Wayland_Known_Significant_Issues. Our plan is to handle everything on that page such that even the most hardcore X11 user doesn’t notice anything missing when they move to Wayland.

Why are you guys doing this? Why don’t you like X11 anymore?

The Plasma team isn’t emotional about display servers; it’s just obvious that X11 is in the process of outliving its usefulness. Someday Wayland will be in this boat too; such is the eventual fate of all technologies.

In addition to the fact that Wayland is better for modern hardware, maintaining code to interact with two display servers and session types is exactly as unpleasant as it sounds. Our resources are always limited, so we’re looking forward to the day when we can once again focus on programming for a single display server paradigm. It will mean that everything else can improve just a little bit faster.

Regardless of when you pull the trigger, isn’t it premature?

Most major distros have already moved their Plasma sessions to Wayland by default, including Arch, Fedora, KDE neon, Kubuntu, and generally their downstream forks. Several others whose roadmaps I’m familiar with plan to do so in the near future.

At this point in time, our telemetry says that a majority of Plasma users are already using the Wayland session. Currently 73% of Plasma 6 users who have turned on telemetry are using the Wayland session, and a little over 60% of all telemetry-activating users (including Plasma 5 users) are on Wayland.

Interestingly, the percentage of Plasma 6 users on Wayland was 82% a month ago, and now it’s down to 73%. What changed? SteamOS 3.7 was released with Plasma 6 and the X11 session still used by default! Interestingly, since then the Wayland trendline has continued to tick up; a month ago the percentage of Wayland users dropped from 82% to 70%, and now today it’s up to 73%.

So you can see that to a large extent, this is up to distros, not us. It wouldn’t make sense for us to get rid of Plasma’s X11 support while there are still major distros shipping it by default, and likewise, it won’t make sense for us to keep it around long after those distros have moved away from it.

Regardless, Wayland’s numbers are increasing steadily, and I expect upward bumps when the next Debian and Kubuntu LTS releases come out, as both are currently planned to be Wayland by default.

Now, is Plasma’s Wayland session perfect? No. (what is?)

Is it better than the X11 session in literally every way? Also no.

Is it better in most ways that matter to most people? The numbers say yes!

Well I’m not a most people! I’m me, I’m an individual! I’m not a number, I’m a free man!

That’s fine, and you’re the reason why we’re still maintaining the X11 session! We’re going to try very hard not to to get rid of it until you’re happy too.

Ultimately that’s the goal here: make everyone happy! This includes people who have mixed-DPI/refresh rate multi-monitor setups or laptop touchpads, as well as people using AutoKey or graphics tablets with dials on them. Long transitions like this are tough, but ultimately worth it so that we all get something better in the end.

Akademy 2024: broadening, professionalizing, and being awesome

Akademy 2024 is a wrap, and others have already begun to write about the conference in beautiful Würzburg, Germany, with some posts already visible on https://planet.kde.org. This year’s Akademy was fantastic, probably the best one I’ve ever attended. Other than the A/V situation (which we’ll be addressing next year, pinkie-promise), it was well-organized and smoothly run.

But more substantively, the talks and sessions were incredible, and really wove together a coherent narrative: KDE has mature and effective leaders who are pushing forward strategic projects that combine to become more than the sum of their parts. Among them:

Design

Andy Betts introduced us to the concept of the design system and how he and other VDG designers are building one to help unify layout and style across KDE software. …then Arjen Hiemstra introduced us to Union, a new styling system intended to be a single tool to style everything, and it can be informed by the design system’s semantics as well.

Apps

Nicolas Fella explained how our app development platform is lacking, inhibiting the growth of a more vibrant KDE-centric app ecosystem. This is also the topic of one of KDE’s newest high-level goals (full disclosure: I’m a co-champion of this goal along with Nicolas as primary champion). Carl Schwan laid out his “App Initiative” which is directly related, and David Edmundson talked about how we can improve the ability of our software to work in sandboxed environments.

Distribution

Harald Sitter introduced us to “KDE Linux” (tentative name), a new technologically advanced OS that will offer a radically high level of stability, security, and polish for those wishing to get KDE software directly from the source. David Edmundson’s talk about sandboxing is also heavily related here as well.

Recruitment

But how are we going to do all of this? Paul Brown, Aniqa Khokhar, and Johnny Jazeix introduced us to the “KDE Needs You 🫵” goal, aiming to reach more people to broaden the pool of potential contributors so KDE is sustainable for years to come.

Eco

And finally, some perspective on a different sustainability issue: this was the hottest year on record, breaking records set just a few years prior. Our planet’s capacity to sustain human life in certain regions is starting to be impacted, and we need to consider both how our work exacerbates it, and how we can do our part to help make it better. Accordingly, we heard from Joanna Murzyn, Cornelius Schumacher, and Joseph P. De Veaugh-Geiss about KDE’s efforts to prolong the lifespan of old hardware so it doesn’t become e-waste. And Nicole Teale gave us some concrete hope by informing us about a program to introduce German schoolkids to the idea of upcycling old computers by installing Kubuntu on them, very similar to a similar program here in the USA that I was tangentially involved with!

Hopefully the themes and synergies here are clear. KDE is becoming more professional, more comprehensive in scope, will take more initiative for the distribution of its own software, will evolve that software’s design in a way that’s supported by modern design tools and professional designers, and contributes to solving the world’s biggest problems. I find this to be super exciting, and I hope you do too!


My personal role in Akademy was a bit more behind-the-scenes this year. I did take part in two presentations: the former goal wrap-up and the KDE e.V. Board of Directors report.

In these, I described the successes and challenges of my now-concluded Automation & Systematization goal, and helped to inform the community about KDE e.V.’s activities since last Akademy.

I also participated in Many birds-of-a-feather (BoF) sessions about various topics, including:

  • A tech discussion about KDE Linux — install it today and help make it great!
  • Plasma planning and roadmap — Plasma is in a great state, and we’re going to resume Monday meetings, this time in video form. I’ve got five specific features, UI changes, or bug-fixes I want to add to 6.3, and others have even more ideas.
  • Design team decision-making process — super useful; we came up with one to enable us to make important decisions again.

Beyond the BoFs, I found myself constantly talking to people between sessions, during lunch, and in what seemed like every spare moment! Including:

  • Björn Balazs about his work to create https://privact.org, a foundation building a next-generation method to gather metrics from users with zero risk to their privacy.
  • Jos van den Oever about KDE developers applying for sponsorship from https://nlnet.nl to work on important KDE and KDE-relevent projects. Seriously, go do it!
  • Eike Hein about KDE’s history and the 100% drama-free Trinity Desktop Environment.
  • Neal Gompa about the challenges involved in shipping an immutable-base-system OS outside of single-purpose appliances (i.e. as a desktop OS for regular people, enthusiasts, and developers).
  • Xaver Hugl live-debugged an issue on my laptop that he was able to speedily conclude was a Libinput bug.
  • …and many more I didn’t have the remaining brain capacity to remember!

All of this was completely exhausting, and I had to excuse myself from a few group events and dinners to rest and process the day’s events. But Würzburg being a ridiculously beautiful city certainly helped!

This has been my favorite Akademy so far, and thank you so much to everyone who helped to make it possible — David Redondo, Kieryn Darkwater, Victoria Fierce, Lydia Pintscher, and the rest of the Akademy team! Job’s a good ‘un, and I’ll see you around the internet!

How YOU Help With Quality

In today’s other blog post, I mentioned how we’ve been getting a huge number of bug reports since the Mega-Release. If you’re not in software engineering, this probably seems like a bad thing. “Oh no, why so many bugs? Didn’t you test your software properly!?”

Since most people are not involved in software engineering, this perspective is common and understandable. So I’d like to shed a light on the assumptions behind it, and talk about the challenges involved in improving software quality, which is a passion of mine.

Don’t kill the messenger

See, bug reports are a “don’t kill the messenger” type of thing. Bugs are there whether they get reported or not, and getting them reported is important so you have a more accurate picture of how your software is actually being used by real people in the real world.

In our KDE world, the alternative to “lots of bug reports” isn’t “few bug reports because there are few bugs” but rather “few bug reports because the software isn’t actually being used much so no one is finding the bugs.” What matters more is the severity of the actionable bug reports.

What bug-free software looks like

That sounds so defeatist! Surely it must actually be possible to have bug-free software, right?

Yes. But to achieve it, you have to test literally every possible thing the software can do to make sure it performs correctly in the environment in which it’s doing it. If the software can do infinite things in infinite environments, then testing also becomes infinite and therefore impossible, so combinations get missed and bugs sneak through. Bug-free software must aggressively limit the scope and variety of those environments to just the ones that can be tested. What does that look like in practice?

  • Limit what the software can do in the first place. Remove as many features, options, and settings as possible without compromising the product’s necessary core functionality.
  • Limit how the user can modify and extend the software after release. No user-created themes, widgets, scripts–nothing! Every modification to what the software can do or how it looks must go through a the same QA team that QAd the software in its original state. 1st-party modifications only.
  • Limit the versions of upstream 3rd-party libraries, dependencies, and kernels that the software is allowed to use. Lock those versions and test everything the software can do on those specific versions.
  • Limit how downstream 3rd-party user-facing software (i.e. apps) can interface with the system. Lock it down in a sandbox as much as you can so any misbehavior can’t affect the rest of the system.
  • Limit the hardware that the software stack is allowed to run on. Test everything the software can do only on that hardware.

Does this sound very much like how KDE software is developed, distributed, and used? I’d say it’s more like how Apple builds products (and note that Apple products still have bugs, but I digress)! By contrast: KDE develops lots of features and options; we’re liberal with supported library, dependency, and kernel versions; and we don’t prevent you from installing our software on any random device you can get your hands on.

You can see the challenge right away! The foundation of quality is a set of restrictions that we don’t want to impose on ourselves and our users. You folks reading this probably don’t want us to impose them on you, either.

Quality from chaos

So is it just impossible to ensure quality in a permissive environment? No, but it’s harder. That’s right: we in the KDE free software world set for ourselves a fundamentally more difficult task than the big corporations with their billions of dollars of resources. Given this, I think we’ve done a pretty darn impressive job with the Mega-Release. And judging by initial impressions out there, it seems like many others agree too!

So how did we do it?

We lengthened our beta period to 3 months and relied on bug reports from people using the software in their own personal environments.

Yes you, loyal reader! We wanted to hear how our software was working on your 12-year-old Netbook. We wanted to hear how it worked when plugged into two TVs and a rotated monitor, all through a KVM switch. We wanted to hear how it coped with the most bizarre-looking 3rd-party themes. By using our flexible and non-limited software in your diverse ways on your diverse hardware, you’re testing it and finding all the bugs that we lack the resources to find ourselves.

Does this sort of QA work sound like something you don’t want to do? That’s 100% fine. But then you need for someone else to be the QA team for you. There are two options:

  • Buy a computer with KDE software pre-installed; there are a lot of them now! Then it’s the vendor’s responsibility to have done adequate QA on their own products. Is it buggy anyway? Complain to them or find a better vendor!
  • If you’re going to install it yourself, limit yourself to common hardware, default software settings, and operating systems that are relatively conservative in their update schedules. Then the QA has been provided by others who who already used your exact setup and reported all the bugs affecting it.

Become a superhero

But what if you do want to help out with making the software better for others, but you’re not a programmer? Congratulations, you’re a real-life superhero.

We’ve already talked about reporting bugs. It’s also important to do a good job with your bug reports so they’re actionable! I’ll encourage folks to read through our documentation about this. Low-quality bug reports don’t just waste our time, they waste yours as well!

But where do all those 150-200 bug reports per day that I mentioned actually go? There’s a flip side which is that someone needs to do something with every single one of them. The more bug reports we get (which, again, is good!) the more we need people to help triaging them.

Because the truth is, most bug reports don’t begin life being actionable for developers. They may be missing key information; they may be mistaking a feature for a bug; they may be describing an issue in someone else’s software; they may be about an issue that was already fixed in a version of the software that the reporter doesn’t have; they may be describing a real issue but in an unclear and confusing way; and so on.

The job of bug triagers is to make each of these bug reports actionable. Ask for missing information! Move them to the right products! Set the version and severity appropriately! Mark already reported bugs as duplicates of the existing report! Mark obvious upstream or downstream issues accordingly and direct people to the places where they can report the bugs to the responsible developers! Try to reproduce the issue yourself and mark it as confirmed if you can! And so on. It isn’t terribly glamorous work, so there aren’t very many people lining up to be volunteer bug triagers, unlike developers. But it’s very important. And so every person who helps out adds resources to what’s currently a very small team, making a massive difference in the process.

If you’ve been looking for a way to help out KDE in a way that doesn’t require programming or a consistent time commitment, this is it. Triage a few bugs here, a few bugs there. Chip in when you can. If 30 people each triaged three bugs a day (this would take under 10 minutes, on average), we’d be in an amazing position.

So get started today! I’m available to help in the #kde-bugs Matrix room.

Still don’t wanna? Donate to KDE e.V. so we can eventually hire our own professional bug triage and QA team!

Where bugfixes and new features come from

A few conversations I’ve had recently at Akademy 2023 have inspired me to write about a topic I’ve been wanting to share for a long time. So today I’d like to shine a bit of light on how the process of getting bugs fixed and features implemented works in KDE. This article’s target audience is general users more so than experienced technical contributors who will already have an understanding of this. But feel free to read anyway if you consider yourself a member of that group!

To begin with, I sometimes encounter the impression that there’s this pool of developers who either roam around looking for bugs to fix and features to implement, or are told or motivated to do so by some higher authority. This isn’t necessarily a misconception, but it needs to be qualified a bit. Well, a lot!

First we have the volunteers who are so often talked about! In general, volunteers work on things that feel rewarding to work on. As a result, most will only work on things relevant to their personal use cases, that are easy or fun, or that they feel a sense of personal obligation to continue working on. There are exceptions, but they tend to be rare and temporary, as the people in question often get hired by someone and lose most of their KDE time.

On that subject, some developers are sponsored to work on KDE software by KDE e.V., by a contracting firm in KDE’s orbit, or by a direct institutional or individual user of KDE software. In general these folks are paid to work on specific features and bug fixes relevant to the use cases of their employers or clients–which can be quite exotic, involving things like hundreds of users with networked home directories, specialized stacks of cryptography software and hardware, multi-screen multi-GPU setups, expensive business printers, and so on. These are the kinds of use cases that an average user never encounters.

There’s often some overlap here. Some paid KDE contributors work for a company that pays them to work on specific projects but gives them some personal time to work on KDE projects of their choice for a few hours a week. Some are contractors who reserve a bit of their own time to volunteer for KDE. And some are fortunate enough to receive open-ended invitations to “Make it better for us” as applied to a broad slice of the system.


This leads to some obvious conclusions regarding the kinds of bugs and features that are likely to get fixed and implemented. Here’s a chart that summarizes it:

Everyone likes the green box. A surprising number of bugs and feature requests fall into it. Even hard bugs can get fixed quickly if their impact is significant and widespread (which means many eyeballs on them) and they are trivially reproduced (which means fixes are easy to test).

Next we have bugs or features in the red box. These are mostly irrelevant to an average user. If you’re a non-average person or institution with a specialized use case, the course of action is clear: pay someone to fix or implement it for you. KDE e.V. maintains a list of contractors who offer such services. Otherwise it probably won’t get done. Expect to pay Real Money™ for this kind of service; targeted contracted software development is rarely cheap. Pizza money donations and average bug bounties ain’t gonna cut it!

Finally, we have bugs or features in either of the yellow boxes. Sometimes these kinds of things get done by volunteers, but it’s hit-and-miss with an uncertain timeline because the work is just not that important–as evidenced by the fact that institutional or individual users rarely if ever pay for them to be fixed. But of course, people who are affected don’t like being told that their small pain points are unimportant, so in my experience, these issues represent a big source of frustration for users in general. Fixing them anyway is a big part of the 15 minute bug initiative. …Which you may notice has stalled at around 50-60 bugs. These remaining bugs are all quite solidly in those yellow boxes where it’s hard to find anyone willing to either do the work or pay for it to be done.

But all is not lost! If you’re annoyed by a yellow-box issue, and you’re unable or unwilling to pay to have it fixed, there is another way to help: try to move the bug or feature closer to the green box somehow! Here are some ideas:

  • If the issue is truly major, help call attention to it. Perhaps it simply got missed among the endless flood of other bug reports. For this to work, the issue really does need to be major; I mean more like “causes data loss” and not “System Tray icons for my autostarted 3rd-party apps sometimes don’t show up.”
  • Identify the easiest possible way to reproduce the bug with 100% success on common and generic hardware, then mention it in the bug report and set its status to CONFIRMED.
  • Identify any volunteer developers in the bug report who take an interest in the issue but mention they lack the hardware to reproduce it, and offer to buy or loan them such hardware.
  • Start fixing or implementing it yourself, even if you know you can’t do it. Your draft work may be enough to motivate someone else to finish it up, or provoke the kind of normally unhelpful nerd-rage nitpicking that drives someone to show you how it’s done by doing it themselves!
  • Wait for the use case to become more widespread, and hence more important. High DPI, multi-screen, multi-GPU, and high refresh rate hardware setups have all become more common over time, and accordingly, the number of people willing to put effort into making them better (or pay for this to happen) has increased.

None of these suggestions guarantee success. But pushing a yellow bug towards being a green one does make it more likely to be worked on and eventually fixed. And anyway, hopefully this helps to illuminate how development work in KDE happens, and why some bugs reports or feature requests linger for a long time.

Presentation at University of Macedonia: Making a Difference

Today I had the honor of delivering a virtual presentation with fellow KDE contributor Neofytos Kolokotronis at the University of Macedonia, the site of KDE’s 2023 Akademy conference. The subject was “Making a Difference: How to contribute and jump start your career in Free Software with the KDE Community”, making it especially relevant for those who have been looking to get started contributing to KDE and don’t yet know how. But even if you’re a seasoned KDE contributor, I bet you’ll learn a thing or two about KDE’s storied history or ambitious plans!

Check it out:

On hiring, and fundraising to make it more biggerer

This year at Akademy, I took the plunge and decided to run for a seat on the KDE e.V.’s board of directors.


What is the KDE e.V.? It’s the nonprofit organization that represents the KDE community in legal and financial matters. It has several paid employees who work on KDE stuff, most notably promotion & marketing, project management, and event planning. You can see more at https://ev.kde.org/corporate/staffcontractors.

By the way, in case you were wondering (as I did at one point), “e.V.” is short for “eingetragener Verein” which is German for “registered association”–basically a type of nonprofit entity.

For several years, I’ve believed and publicly suggested that the KDE e.V. needs to have more technical positions. We need to directly hire KDE community members so they don’t have to seek employment with a 3rd-party company, or even drift away from the community when they have less free time and age into positions of greater financial need. In fact the KDE e.V. has already been moving in this direction, but slowly, because the available budget is pretty small compared to the vastness of the KDE community and the scope of more ambitious hiring. You can get an idea by looking at the report of the Financial Working Group in the 2021 annual report.

So I ran on a platform of hugely increasing both fundraising and technical hiring. And I’m honored to report that I won the election and am now a member of the board!

i got board

To those of you who voted for me, thank you so much for your support. For those of you who didn’t, I hope I can represent you well anyway, and if you get ticked off with anything I’m doing… please tell me! I welcome feedback. This position is all about being a good representative, and that’s what I want to be.


So what does this mean?

It means that a majority of the KDE e.V. membership approves of these goals, so when it gets more money, the KDE e.V. has a mandate to do more hiring–especially for impactful technical positions. It means we will eventually be able to have the big names in KDE paid by KDE, so they can stay in KDE over the long haul! And it also means we need a lot more money to make this happen.

There are a lot of steps to this, including figuring out the legal technicalities of full-time hiring, and increasing the budget so we can make sure we’re always offering market wages. We’ll be investigating potential ways to boost fundraising: hiring a professional fundraising director; applying for a lot more grants; having more explicit fundraising campaigns; gamifying fundraising; sending out nudgey newsletters to people who have donated in the past; making it easier to donate on a recurring basis; and more.

But for now, if you want to see us do more hiring, the best way is to make a donation to the KDE e.V. at https://kde.org/community/donations. It helps. It really does! This money is going to transform KDE into a professional powerhouse with its own internally-employed cadre of world-class superstars. We’re going to take on the Big Tech dogs and win, and we’re going to let our heavy-hitters make a living within KDE while doing it. But it can’t happen without your help, so please consider making a donation today!