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.