Today’s a big day for tech news! Hot on the heels of Redis announcing its return to open source, KDE—the beloved desktop environment used by millions—has just shared some equally exciting updates.
After a week of intense discussion and hacking at Graz, Austria, the KDE Plasma team has drawn a clear roadmap that rewrites some long-standing assumptions about its flagship desktop. According to developer Nate Graham, the group resolved to phase out dedicated Plasma LTS releases, tighten the release cadence, and introduce new safeguards for third-party content.
For years, Plasma offered a “Long-Term Support” branch that received bug-fix backports but little active testing. Participants at the sprint concluded that the limited scope of this arrangement raised expectations they could no longer meet. So, instead of a separate LTS line, every normal Plasma release will now enjoy one extra maintenance update—six bug-fix releases rather than five—extending support without fragmenting developer attention.
Although the label LTS disappears upstream, nothing stops distributions such as Kubuntu or SUSE from curating longer-lived stacks. The KDE team, therefore, plans to steer users of “enterprise” distros toward their vendors’ trackers, freeing KDE devs to focus on issues reproducible on the current code.
Moreover, the sprint revisited last year’s idea of trimming the major feature schedule from three releases per year to two. Aligning with Fedora’s and Kubuntu’s six-monthly calendars would turn each release into a de facto “mini-LTS,” giving downstream packagers more breathing room while concentrating quality-assurance resources.
The next big topic is telemetry. I know, I know—it’s not exactly a favorite word in the open-source world. But as with most things, there’s some nuance here.
It’s one thing to criticize the heavy-handed telemetry used by closed-source operating systems, browsers, and the like. It’s a completely different story when we’re talking about telemetry in an open-source project, where everything is out in the open and the data is handled in a fully transparent way. So, here’s the case.
Currently, KDE collects minimal usage data—opt-in only, off by default—and cannot easily adjust the questions it asks. Drawing inspiration from Valve’s Steam Hardware Survey, the team agreed to move toward periodic, tailored questionnaires that pop up after user consent. Why? Developers want richer data to guide design choices, yet they are keenly aware of the community’s long memory of “phone-home” controversies.
At the moment, developers often decide blindly because the dataset currently collected is tiny and static. Worse, the existing viewer is a half-broken GUI that ultimately dumps analysts into raw SQL.
In practice, the system still rides on the KUserFeedback libraries already embedded in Plasma and many KDE apps. What changes is the cadence and scope: from a fire-and-forget trickle of generic stats to time-boxed surveys that answer open product questions.
The plan is that, from now on, if, for example, developers debate dropping an obscure KWin effect, a one-off survey (a single click can accept, decline, or dismiss forever) could report real-world adoption and even capture free-text feedback from those who rely on the feature. Aggregated results would be published publicly, emulating Steam’s transparency.
More importantly, users will see the JSON payload transmitted before opting in. So, everything’s perfectly fine—there’s absolutely no reason to worry. In fact, this approach is something to feel good about, because it’s designed entirely with the end user in mind. Want an even better desktop experience? Then opt in and help the KDE developers determine where to focus their efforts. Yes, it’s that simple.
For more information, see Nate Graham’s post.
