Category: FOSS culture

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:

Imperial Star Destroyer by topcat at Wallpapers.com — https://wallpapers.com/wallpapers/imperial-star-destroyer-hus8fir1xr6vldsn.html

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

Bull Image from FreePNGimg.com

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.

Legal obligations vs social contracts

My post about responsibility for bug reports on old software versions the other day stirred up quite some discussion, and I wanted to drill a bit more into what I think is the crux of the dispute: the difference between legal obligations and the social contract.

When you package and distribute free open source software (FOSS), you legally have to comply with the terms of the license: “make the source code available,” “don’t change the license,” and so on.

You might also notice the absence of a warranty, or silence about responsibility for bug reports.

So let’s return to the question:

Who’s responsible for bug reports on old software versions?

An accurate legal reading is “Nobody, unless you’ve signed a work contract with a developer or purchased a commercially-sold OS.” But it’s also not the whole picture, because there’s another potential non-obvious legal obligation:

Trademark

Trademark law varies across the world, but at least where I live in the USA, “unregistered trademarks” are a thing, and in a professional context, you’ve got a legal obligation not to violate a product’s trademark — registered or unregistered — by referring to it as something that it isn’t, or changing it and saying it’s still what it originally was.

Ah, but how much to you have to change it before that kicks in? That’s definitely not something that I — a non-lawyer — am qualified to assess. And my understanding is that this varies a lot across the world’s legal regimes, too.

But my layman non-lawyer perception is that applying bug fixes (especially backports of the developer’s own bug fixes) probably doesn’t count, while making visual or functional changes not from the developer probably does press closer to that fuzzy line.

Which brings me to what I think is the most important part:

Doing only the legal minimum

“Follow the terms of the license agreement.” “Don’t mis-represent trademarks you don’t control.” “Don’t steal.” “Don’t murder.”

These are good places to start. But what if that’s all anyone ever did — the bare legal minimum?

I think the world would be a pretty miserable place. There’s no law requiring anyone to love you or soothe your feelings when you’re upset. There’s no law requiring you to find a source of joy or direction in life, or help others unbidden.

What makes life worth living is everything beyond the legal minimum: politeness, kindness, friends, love, pleasure, purpose, art, music, entertainment, faithfulness, professionalism, and so on.

Everything desirable but not required by law comprises the social contract: a set of unwritten rules that, the more people follow them, the better their society is to live in. It helps personally, too: follow the social contract, and you’ll end up calmer and happier, be perceived more positively, and things will just kind of start going your way, as if by magic. Break it, and the opposite starts to happen.

Applying the social contract to this situation

Let’s say that I write an app, and someone distributes it with a feature patched in that I didn’t write, or a visual change that I didn’t make. How mad at them am I going to be?

If we have a bad relationship due to previous perceived violations of the FOSS social contract, I might be very mad. I might complain publicly, or even threaten to enforce my trademark and demand they change the branding to reflect the fact that they’ve created what I believe to be a derivative work that reflects poorly on the original.

No matter what, we can be sure it will escalate into a fight with a winner and a loser. And that loser might be me.

But if we have a good relationship and view each other as pro-social upholders of the FOSS social contract? I might be really happy about this, or at least tolerate it. Maybe I’ll even reach out and ask them to submit their change upstream and help maintain it. There’s a 0% chance I’m going to threaten to invoke trademark law or give them a hard time about it.

That’s the power of respecting the social contract that exists between us.

But what is the FOSS social contract?

Like the definition of “derivative work”, it’s unsatisfyingly fuzzy and nebulous. But like a cloud, even if we can’t contain 100% of it in a jar, we can probably identify many of its features. So here are some pro-social behaviors that I hope we can all agree are squarely within the “FOSS social contract”:

Using FOSS

  • If you didn’t pay any money, appreciate what you’ve gotten for free. It’s a modern miracle.
  • Understand the basic software lifecycle of the OS you’re using, and choose the one that suits your needs the best.
  • Accept the “no warranty” clause. Understand that support may be slow, and that if you need it fast, you’ll need to pay for it.
  • If you don’t like the software you’re using, use something else.

Bug reporting

  • Endeavor to report bugs in the right place, to the best of your ability.
  • Phrase your bug reports gently, and articulate a real problem to be solved, rather than making demands or suggesting solutions.
  • Be understanding of the fact that your request might be a big ask that might not get done soon, or might be better done in a different place or in a different way.
  • Treat people kindly with the benefit of the doubt, even if they don’t respond to your bug report in a timely manner, or at all.
  • If your needs are urgent, pay a person or company to address them; don’t make demands of people working for free.

Software development

  • Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
  • If you aren’t distributing your own software in a way that’s suitable for 100% of your users, appreciate the free efforts of distributors who are doing it for you, even if they aren’t doing it in exactly the way you would prefer.
  • Work with your distributors to help them showcase your software in the best light. They don’t know it as well as you do.
  • Don’t piss off too many of your users. You’re doing this for them, not just for yourself.
  • Only make your software publicly available via a FOSS license if you’re willing to accept people using it or distributing it in ways you might not have expected or preferred.

Software distribution

  • Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
  • Respect the reasonable wishes of the developers whose software you distribute. Keep up good relationships with them as much as possible.
  • Clearly communicate your OS’s software lifecycle and release schedule. Curate your users so everyone using your OS is within its intended audience.
  • If you meaningfully change the software you distribute (outside of backporting the developers’ own bug fixes or similar), accept that you’ve created a derivative work that needs to be presented accordingly: At the minimum, change the name, icon, and metadata (like the bug report URL).
  • If you distribute software that you know is or soon will be outside of its developers’ support window, change the bug report URL to your own, or remove it entirely if you don’t have the resources to offer support for old software.
  • Only create an OS in the first place if you’re willing to take responsibility for the support needs of the people who will use and depend on it.

Hopefully we can all agree that if everyone considered the above ideas to be part of the social contract they follow, our world would be a very friendly and pleasant place! We’d end up with way fewer arguments and disputes, and could more and more get on with doing the fun part of what we do. And it’s my hope that we can all aspire towards these ideal with our actions and words.

Who’s responsible for bug reports on old software versions?

Consider this hypothetical:

An operating system (OS) ships version 1.5 of a piece of software.

Meanwhile, the latest version of that software is 3.0.

A user on that OS experiences an issue in version 1.5, or has an idea for a new feature. Who should they contact?

This hypothetical becomes concrete due to the existence of discrete-release OSs, like Ubuntu, Debian, openSUSE Leap, and Linux Mint. These intentionally freeze on certain versions of the software they ship for a certain period of time — even if newer versions have already been released upstream of them.

It’s in the news right now because of a recent kerfuffle over in Linux Mint specifically; a developer of GNOME Calendar asked Linux Mint to patch out support links and change the branding, and later followed up with a fairly inflammatory blog post after the issue was locked for understandable reasons.

This saddens me because the miscommunication was preventable, and now a good portion of the discussion surrounding the topic is about tone rather than the topic itself — a predictable outcome of not caring about tone. But I digress.

I think it’s an important topic, so I thought I’d share my take on the situation.

Are software developers responsible?

Software devs wrote the software. The software broke. End of story.

If only life were that simple!

Having been on the receiving end of thousands of un-actionable bug reports about old versions of KDE’s software in discrete-release OSs for issues that were fixed months or years ago (but not backported by the OS distributor!)… I can tell you it’s very frustrating.

But we in the free, open-source software (FOSS) world make our software available via free software licenses; we need to be prepared for OSs distributing our software in ways we didn’t anticipate or aren’t thrilled about, and bug reports from their users. That’s life.

Our solution in KDE is a bot that automatically closes bug reports for versions of Plasma that are out of support, and we may eventually broaden the system to cover our apps and frameworks, too.

It’s not perfect, but it mostly works out. I can tell because most of the new Plasma bug reports I see these days are from users of rolling-release OSs like Arch, OpenSUSE Tumbleweed, and Fedora KDE (which is not truly rolling, but it’s close enough), and I’d say most are actionable.

It kind of stinks for users of discrete-release OSs, who get a robot telling them that the work they just put in to report the bug was useless. But they also benefit from rolling-release users effectively being their free quality assurance (QA). Trade-offs.

Are distributors responsible?

If my car breaks, I blame the car company — not the vendor who sold them the part that broke.

(well, maybe I blame them too if I’m a car nerd, but that’s the exception!)

Ultimately OS distributors are the car company here, assembling the final product. It’s their job to do adequate QA and work with their vendors (upstream software devs) to make sure that final product sparkles.

Of course, a new car costs many months’ salary and includes a multi-year warranty, while most FOSS OSs don’t and are distributed for free. So expectations need to be tempered a bit.

This is where I think communication breaks down. A lot of free-of-charge FOSS OSs advertise themselves really positively, promising the sun, the moon, and the stars. Whereas the truth for many is that they’re assembled by a small team with a shoestring budget (or none at all) from years-old software offered by grumpy developers they don’t have a great relationship with.

Users then don’t understand the full picture of who’s responsible for what, or the level of support they should expect and from whom.

This is the reason why KDE Linux includes tons of qualifiers and provisos in its marketing material. We don’t want to over-promise! It’s a small project built by a small team. I think every piece of free software should be clear about who should use it… and who shouldn’t. Don’t over-promise! It’s a recipe for frustration and disappointment on all sides.

And if you want an OS with professional backing, you’ll likely need to pay for it.

So what’s the solution?

As a distributor, I think you need to sort out what kind of relationship you want to have with the developers of the upstream software you ship.

Do you want to be able to have a distant relationship? Then I recommend abandoning discrete releases and adopting the rolling release approach.

In this model, you take upstream software the moment it’s released — or at least soon afterwards. Then the conflict disappears! Almost all bugs become upstream bugs, and you can direct users to upstream devs without getting any push-back from them. Everything remaining is an issue that you can fix in your OS.

Rolling release OSs can still have good relationships with their upstreams, of course. But it isn’t as critical.

Don’t want to be a rolling release? That’s fine. Then you need to work closely with your upstreams.

Communicate your users’ complaints and bugs upstream, help drive fixes, and then ship them. Many software developers already release bug-fix versions in addition to feature versions. If they do… ship them! Don’t ignore them; this will make your upstreams grumpier.

If any of your upstreams release a “long-term support” version of their software, ship that. If they don’t, you can even work with them to create one if they’re amenable to the idea, and help to support it.

This is more work, obviously. So if your team is small, it may not be feasible to do for every piece of software you ship. But you can try for the most important ones: the Linux kernel, systemd, Mesa, Libinput, PipeWire, NetworkManager, BlueZ, udisks, CUPS, and KDE or GNOME.

But that’s the important point: shipping a high-quality discrete release OS is more work than producing a competent rolling release. No way around it.

So a way to make this approach more feasible is to reduce your OS’s scope of concern.

For example, you can delegate app distribution to a third party like Flathub, the Snap store, AppImageHub, etc. This lets you focus on just the base OS and its desktop environment, while apps are rolling, which means they’ll accept bug reports about them. Personally, I think there’s a lot to like about this model.

It also helps if you don’t let the software get too out of date. Up to 6 months old? Your upstreams are likely fine with this, and will accept bug reports. 12 months? Mostly fine. 2 years? That starts to get painful for your upstream developers if users are still reporting bugs to them. 3 year or more? Very painful. We pretty much have to direct them to their OS vendor.

What’s not the solution?

Package 2+ year-old frozen releases of as much upstream software as you can, and then ignore the upstreams, their bug-fix releases, and their complaints about this.

This is the worst of all worlds!

  • Users get outdated software that’s full of bugs and security holes fixed long ago
  • Software developers get un-actionable bug reports from angry and confused users
  • Distributors get frustrated communications from software developers that damage or destroy important relationships

Please don’t do this. It isn’t sustainable over time, and will cause a leak of the most desirable users who make an active choice to use your OS.

How do I know this?

Well, I don’t, but I can make an educated guess based on some of the few statistics we do have. A big one is the OS market share on ProtonDB as compiled by BoilingSteam, which counts Linux gamers:

In 2019, the “rolling and rolling-ish (e.g. Fedora)” OSs made up a little over 36% of the total users.

In 2026, they’re up to 71%.

This isn’t everyone, of course; only gamers using ProtonDB. But still, it’s quite a change. Clearly gamers believe rolling-release OSs cater to their needs better than discrete-release OSs do.

So, if you ship a discrete release OS, and you don’t want to or can’t switch it to a rolling or semi-rolling release cadence, please please please work with your upstreams! As a (sadly now only merely occasional) upstream KDE software dev, I can tell you my favorite distributors to work with are the ones who engage with KDE and help get problems solved. It’s a lot of fun when all parties focus on problem-solving.

“Long-Term Support” doesn’t mean what you think

My last post about good beginner-friendly KDE-focused operating systems sparked some discussions about the concept of “Long-Term Support” (LTS) releases.

But what does this term mean? It’s a bit generic-sounding, making it easy to interpret as meaning almost anything. So let’s go to the source: how the term is defined by the operating systems using it! Here are the non-commercial ones:

Debian Stable says:

Security updates are provided by Debian security team for three years. This generally means that each stable release is supported for its whole life plus an extra year (or so) after a new version of stable is released. In addition, further security support is provided by the LTS and LTS/Extended projects.

Ubuntu says:

LTS stands for long-term support — which means five years of free security and maintenance updates

Kubuntu says:

The latest Long Term Support (LTS) version of the Kubuntu operating system for desktop PCs and laptops, Kubuntu 26.04 [is] supported with security and maintenance updates, until April 2029.

(I didn’t include openSUSE Leap because its marketing material doesn’t use this term, though what it offers is fairly similar in practice)

So these operating systems are fairly consistent about what “Long-Term Support” means to them:

  • Each discrete OS release will continue receiving updates for a certain number of years.
  • Those updates will include fixes for security issues.
  • Those updates may include whatever “maintenance” means; Ubuntu & Kubuntu promise this, Debian doesn’t say.
  • Those updates will not include any new features, UI improvements, or other non-bug-fix releases from the software’s developers. That is to say, each piece of software is effectively locked to a specific version for the life of the release.

That’s it! So let’s look at what’s NOT promised:

  • Lack of bugs
  • Lack of crashes
  • Fixes for non-security issues
  • Personal support for issues you encounter
  • Support for newer hardware devices (Ubuntu offers “hardware enablement” kernels for desktop installs by default, but they come with no stated guarantees and don’t cover the parts of hardware support that go beyond the kernel)

That doesn’t mean an LTS release of Debian, Ubuntu, or Kubuntu will be devoid of these things. It just means they aren’t promised. Probably you’ll get a lot of them anyway, but there’s no guarantee.

I think this is where some of the persistent confusion around the LTS topic comes from.

LTS releases are fairly reliable as long as you use the most popular software from their included software repositories. So in the circumstances when this stops being the case, I think sometimes people can feel betrayed. They think, “I thought this was supposed to be stable! Why didn’t anyone fix this bug yet? Where’s my long-term support?”

But Debian, Ubuntu, and Kubuntu never promised any level of reliability or absence of bugs. They promised that the version-locked software in their repos would receive security fixes for a certain number of years. Ubuntu and Kubuntu also offered a certain amount of non-guaranteed best-effort hardware compatibility improvements and non-security bug fixes.

That’s it!

So it’s important to understand what you’re actually getting with an LTS-style OS. And maybe it’s not for you. There are plenty of other options for people with different desires:

I want newer software

If you’re a software developer or a technology enthusiast, you may want to get software on or closer to its developers’ release schedules. This will give you a stream of new features, UI improvements, and fixes for bugs. In this case, the better option is a rapidly-updating OS like Arch Linux, openSUSE Tumbleweed, Fedora KDE, or one of their children.

The trade-off here is that you may have to live with some things that are currently working getting broken after updating. In other words, the bugs are unstable, unlike in an LTS OS where the bugs are stable.

I personally fall into this group, which is why I use a rapidly-updating OS and not an LTS OS.

I want fewer bugs

I think a lot of people choose an LTS OS to experience fewer bugs, but this is generally not a strength of the LTS product. When an LTS OS freezes on a specific set of software, all the bugs in those versions of the software are frozen, too. Unless the LTS OS provider fixes any of those bugs themselves or backports fixes for them, users will be exposed to them for the lifetime of the release.

With a rapidly-updating OS, when software developers fix bugs in their software, you’ll get those bug-fixes quickly. As long as the software itself is becoming less buggy over time, a rapidly-updating OS shipping software close to its developers’ release schedules will likewise become less buggy over time.

It’s not all puppies and rainbows, though. A fast pace of change means more opportunities for those developers to accidentally introduce new bugs, and also for the introduction of integration issues: bugs caused by software being mis-configured or incompatible with other software. LTS OSs excel at minimizing integration issues between software, because a frozen set of software isn’t a moving target for QA testing.

So in a lot of ways, this choice boils down to whether you’re more bothered by software bugs or by integration issues.

I want better hardware support

If the manufacturer of your device didn’t provide much or any Linux software support for it, a rapidly-updating OS is likewise a better option here. You’ll quickly get all the components that improve hardware support, not just the parts in the kernel.

I want a true reliability guarantee

If time is money for you, this makes sense. And to get it, you’ll need to pay for a commercially-supported operating system. For example, Canonical offers “Ubuntu Pro” with a level of support that includes the following:

Build with confidence with 24/7/365 phone and ticket support. Get prompt help when something breaks on any of the packages in the Ubuntu Main and Universe repositories, including the most widely used open source applications and toolchains. Our 24/7 plans now include SLAs not only for initial response times, but also for ongoing follow-up updates ensuring continuous visibility and faster remediation throughout the lifecycle of your support case.

Wow! Now that’s support. It costs $300 per year for workstations (servers are over 5x as much).

Red Hat and SUSE offer similar services at similar prices.

And they aren’t cheap! But if time is money, those prices may look pretty reasonable. And you’ll get to talk to a perky and friendly person over the phone when you encounter a covered problem, and someone will to take direct responsibility for getting a fix delivered.

What about Flatpak and Snap?

In principle, these technologies allow an LTS-style OS to offer the best of both worlds: a stable base with apps updating more rapidly.

In practice, what you get is a mixing of both worlds. The base OS retains its LTS characteristics, while apps become rapidly-updating, giving you some exposure to breakage coming from new versions alongside more features, UI improvements, and fixes for existing bugs.

We’re spoiled for choice in our ecosystem, which means everyone can find a free software operating system that matches their needs and desires. But you have to know what those needs and desires are, and also successfully map them to the available options! Hopefully this blog post has helped explain what the LTS-style operating systems offer, and who should use them.

While you support others, who supports you?

The world of free and open-source software (FOSS) is full of big-hearted, altruistic people who love serving society by giving away their labor for free. It’s incredible. These folks are supporting so many people by providing the world with high quality free software, including in KDE, my FOSS community of choice.

But while they do it, who’s supporting them? We don’t talk about this as much.

A recent Reddit post by a volunteer developer burning out reminded me of the topic, and it’s not the first one. Denis Pushkarev of core-js wrote something similar in 2023, and we’re probably all familiar with this XKCD comic:

The topic is also not limited to the FOSS world; it’s broadly applicable to all volunteer activities. Can’t feed the homeless in a soup kitchen if you’re sick and sneezing into the soup! Can’t drive to the library to teach adult reading classes if your car’s broken down.

In order to support others, you need support yourself! Who can provide that support? Here are a bunch of cases that work:

  • Yourself in the present (with a job — related or unrelated to your FOSS work)
  • Yourself in the past (retired)
  • Your partner in the present (married to a primary or sole income-earner)
  • Your partner in the past (partner left you lots of money after death or divorce)
  • Your parents in the present (you’re their dependent)
  • Your parents in the past (born rich or received a big inheritance later)
  • The state (disabled, a student, or on a similar program)

All these cases work. They provide enough money to live, and you still get to work on FOSS!

There are lots of other good options, but here are some of the bad ones that don’t work:

  • Other people via donations: you never get enough donations, and if you put the effort into fundraising required to make it work, that becomes your job.
  • Yourself in the future: if you’re living off loans, you’re screwing over future you!
  • Nobody: if you’re eating up your savings, you’ll eventually run out of money and be destitute. If you’re fortunate enough to live in a place where “The state” is an option, it will be at a diminished standard of living.

We must always answer for ourselves the question of how we’re going to be supported while we continue to contribute to the digital commons. If you don’t do it for a living, it’s a critically important question. Never let anyone guilt-trip you into doing volunteer work you don’t have the time or money for! It’s a sure road to burnout or worse.

Airplane safety briefings tell people to “put on your mask before helping others.” Why? Same reason as what we’re talking about here: you can’t support others if you’re not first supported yourself. If you try, you’ll fail, either immediately, or eventually. You must be properly supported yourself before you can be of use to others.

Tools that Just Work™ …until they don’t

As a former Apple guy, it pains me a bit to say this, but I’m coming to believe that the whole “It Just Works” thing is a temporary illusion.

Oh, it can be achieved! But the real trick lies in keeping it. This came to mind while I was watching a video about one of Bambu Labs’ very impressive-looking Apple-style “It Just Works” 3D printers, and felt myself drawing a parallel between the world of 3D printing and our more familiar KDE world.

As I mentioned recently, my first real introduction to the world of free software was 15 years ago with 3D printers, back when the field was dominated by RepRap hackers designing open hardware and software. And last year, I bought a new printer for the first time in over a decade. After drooling over a bunch of very cool Vorons, I eventually settled on a Prusa Mk4 instead of a different Bambu printer that looked very impressive at the time: printing faster, having an enclosed chamber and smoother wireless functionality, being cheaper, and looking prettier.

But the Prusa felt like KDE: simple by default, but powerful when needed. Big friendly community. Built by a company led by one of the early RepRap hardware hackers. Buying it was investing in the people helping to keep their part of the industry open, rather than private. No spyware, no lock-in, no phone app or internet connection needed. Can’t be bricked if the company goes out of business. Open, hackable, humane, trustworthy.

I’m making this sound like the decision was some sort of ideological compromise, but the Prusa Mk4 is also excellent. It’s as good or better in many ways, almost as much in others, and its UX still pretty polished. Maybe it’s not Apple polished, but it’s very easy to use and produces great prints. I did have to invest a bit more time and money into the Prusa upfront, but now I have a tool I can truly rely on, not because it’s got a seamless auto-updating cloud-based AI-enabled UI, but because it doesn’t.

And since then, both companies went in exactly in the directions I expected: Prusa released a new version of their printer that’s cheaper and better, plus a $100 kit for existing owners so they don’t have to buy a whole new thing… while Bambu released a firmware upgrade that lets them control how your Bambu printer can be used.

It Just Works… until it doesn’t.

I’m glad I went with the Prusa, the same way we’re all glad we went with KDE over Apple or Microsoft. In KDE we know this well, so it’s up to us to spread the message to everyone else: resist the lure of “easier now, screwed later.” This is where the big commercial offerings start to fail: anything proprietary and closed source that Just Works may simply stop working at any time. You’ll invest in it, and it’ll work out great for a while, but then start to worsen, break, or exploit you.

Even as we invest in making our software easier to use, we need to level the playing field by advertising our advantages in ownership, privacy, personalization, and freedom. Our software is trustworthy because it can’t be taken away by us or anyone else; you’ll be able to use it over the long term, developing skills and efficiencies over time. Investing in KDE is investing in yourself, rather than someone else’s bottom line.

25 ways you can contribute to KDE

In honor of KDE’s impending 25th birthday tomorrow, here are 25 ways you can get involved to help make KDE software the best in the world!

  1. Be kind. Most KDE people are either volunteers, or paid employees who work on KDE stuff far beyond their working hours. These folks put their heart and soul into KDE, and often the most impactful thing you can do is to express appreciation to someone you see going above and beyond the call of duty. Be positive, not negative. KDE is made by people with feelings, like you!
  2. Submit code to fix bugs, implement new features, or improve the accessibility of KDE software!
  3. File a bug report for every problem you encounter! You might be surprised by how many people don’t do this, and assume that KDE’s developers are already aware of your issue. We become aware through bug reports!
  4. Help translate KDE software into your native language!
  5. Volunteer to work on sysadmin stuff. KDE’s sysadmins are always terribly overworked and in need of assistance!
  6. Subtly advocate for FOSS in general and KDE software specifically to the people in your social circle who depend on you for technical advice and support. Don’t be pushy, but make it clear you’re willing to help them migrate once they get sick of Windows, macOS, software that’s riddled with ads or tied to a paid subscription, and proprietary file formats that lock you into one app. Admit it, you’re the nerd who your friends and and family rely on! Your words have power! Use it wisely. 🙂
  7. Work on KDE’s formal promo efforts to get the word out about KDE software!
  8. Donate money to the KDE e.V. to support hiring more employees and paying for development sprints!
  9. Help maintain and expand KDE’s web presence!
  10. Design new icons to fill some of the gaps in the Breeze icon theme!
  11. Help work on the visual design of KDE software!
  12. Purchase FOSS hardware in general, and specifically, hardware with KDE Plasma preinstalled!
  13. Help a local school or small business install a Plasma distro on aging hardware so they don’t need to buy new stuff at high cost!
  14. Start contributing in your distro of choice to help them integrate KDE software better, ship a more appropriate set of default applications, update old themes which have drifted out of sync with what they were forked from, and so on!
  15. Triage bug reports to help developers focus on real issues!
  16. Answer KDE users’ user questions on social media and help people get the most out of KDE software!
  17. Review merge requests in projects you’re familiar with. This is an under-appreciated but very important way to contribute, even if you don’t consider yourself a technical expert. But you can test the changes to see if they work as described, and I bet you can also spot misspellings, obvious code errors, and weird user interfaces that could stand to be improved!
  18. Improve documentation–especially if you used the documentation and found something wanting. The best candidate to fix bad documentation is someone who just read it and found problems with it or didn’t find it as helpful as it would have been!
  19. Help manage stuff. KDE is desperately in need of “big picture people” capable of seeing things from a 10,000 foot view and helping strategically important work move towards completion!
  20. Be nice to other FOSS projects. We may be here for KDE, but GNOME is a good project too. There’s room for more than just one, and in fact healthy competition between projects is a good thing! Do don’t hate on GNOME if you’re a KDE person. They do a lot of things right and they produce quality software. Be a good ambassador!
  21. Start a local KDE user group. You might make some new friends and discover more local users of KDE software than you thought!
  22. Volunteer at your local school or university to teach students about programming or the importance of software freedom–with a KDE tilt, of course! 😉
  23. Attend Akademy, KDE’s yearly conference. Eventually it will be an in-person event again, and let me tell you, it’s a lot of fun to spend several days around members of your digital tribe!
  24. Install Plasma on as many of your home devices as possible! Experience more freedom, as well as testing more esoteric use cases. This is valuable because there is only so much hardware the core developers can test again, we rely on our users to provide reports about problems with the full diversity of what’s available out there!
  25. Don’t sweat it if things aren’t perfect–like this list of 25 things that basically ends at 24. 🙂