KDE celebrates 20th birthday and goes LTS

The story of KDE started in October 1996 when Matthias Ettrich started a post in various Linux and X11-related newsgroups. “We quickly assembled 40 or so developers and started hacking together. Since then, the project has grown a lot, both in terms of contributors and in terms of users. And most certainly in terms of the number of applications and lines of source code,” Ettrich once told me.

Ettrich further added that, “The time was just right in 1996. Linux was popular enough that it had plenty of developers and users who were interested in graphical user interfaces, as opposed to the early console-only hackers, as Microsoft shocked the Free Software world with Windows 95. It may sound unbelievable, but back then many hackers thought something like Windows 95 could never be matched with Free Software. How wrong they were!”

Fast forward to 2016 and today KDE is one of the most modern free and open source projects; it’s also one of the biggest.

Recently the KDE community announced that it is working on a long term support (LTS) version of Plasma. I caught up with Sebastian Kügler of the KDE project to understand more about their LTS plan, which kind of syncs with the project’s 20th anniversary. Here is an edited version of that interview:

What led to the creation of the LTS version of Plasma? I understand that core components like kernel and OS may make more sense to be supported for a longer timeframe or duration, but what was the need to create LTS of a desktop? Shouldn’t desktop be getting as many updates as possible to keep it fresh and modern?

This depends on the user, and on the rate of change the users want to cope with, and deployment practicalities.

Plasma 5 has matured very well since its 5.0 release two years ago. For many professional and private users, Plasma today works really well and is fully sufficient for their needs. Most of our users do not get our software directly, but for example through a Linux distribution. At that level, the whole stack matters since distributions are interested in putting together a coherent stack that has been tested and proven to work in that combination. Software updates higher up in the stack may require newer versions below them; Plasma for example may require a newer version of Qt framework. Therefore, distributions are usually very reluctant to shipping newer versions of Plasma during their product life-cycle.

In some cases, distros do not even ship our bugfix updates as regular updates, that means that the users get stuck on old version of Plasma and KDE upstream has no way of fixing these users’ problems. We hope that by providing a stable LTS with reliable updates, we make it easier for distros to get our fixes out to the users.

With Plasma 5.8 we can reduce the effect of newer requirements on the software stack while still providing bug-fix and security updates with minimal risk of regressions. Importantly, Plasma 5.8 is also dependency-frozen, which means that Plasma updates will not require feature updates of underlying components.

Aside from that, with Plasma 5.0 we have introduced much shorter development cycles. The Plasma 4 series shipped two featured releases yearly, with Plasma 5 we have doubled that, and as a result of this pace, Plasma 5 has matured rapidly. The amount of fixes that went into 5.8 make it a very nice release, which we’re confident to support for a longer period. That said, the 18 months of upstream support for Plasma 5.8 that we’re currently planning is not actually that much — we realize that. Many users do not update their systems even that often. On the other hand, we wanted to be be conservative here and not promise support we’re not sure we can deliver in two years time. KDE is  volunteer-driven organization in the end, which makes longer-term resource planning a bit harder. We will learn from this experience and feedback we receive, which is going to help us planning into the future.

What are the clear advantages of moving to LTS?

Plasma 5.8 focuses on stability and fixes many annoying bugs. In the last cycle, we didn’t add many new features, but concentrated on stability and bug-fixing. Especially the multi-screen usage patterns have received extensive testing and bug-fixing, and hooking up new monitors, docking stations and TV’s works much more reliably now.

So will there be two releases of Plasma — LTS and regular?

Essentially, yes. After the release of Plasma 5.8, we will follow it up with stable updates, 5.8.1, 5.8.2, etc.. These updates will not contain new features, and are bugfix only. Visual changes are avoided as much as possible (though you can always install new themes yourself of course). It will also receive security fixes, and translation updates. Over the course of its life-time, it won’t change much, but receive bugfixes.

As usual, after the release of Plasma 5.8, we will start the work on Plasma 5.9, which will be another evolutionary step. After 5.8, we are not planning any radical architectural changes other than adding support for Wayland. After 5.9 there will be 5.10, and so forth. We consider backporting work on the newer releases based on their impact, risk for regressions and testability. These newer releases will of course receive new features and changes and improvements under the hood.

Does the KDE neon project play any role?

The KDE neon project allows us to provide more than one release in parallel and test it properly. The technology we use to build KDE neon allows us to build different flavors directly from our git sources. The user can pick the flavor based on their needs, the latest stable, the latest bleeding edge code from git master, or the rock-stable enterprise / LTS flavor. KDE neon’s technology, continuous build, integration and delivery allow us to test and deploy multiple branches concurrently at a faster pace and higher quality.

How do you define an LTS release of Plasma? How long will it be supported and how long is the current branch being supported? What’s the release cycle of LTS?

Plasma 5.8 receives long-term support, that means that KDE will provide upstream Plasma support in the form of bug-fixes, security and translation updates for 18 months after the release of 5.8.0. We’re using a Fibonacci sequenced release rhythm, which means that we plan to issue updates less frequently over time. Important fixes, however, may mean that we issue updates as-needed. As our support for running Plasma in a Wayland session is not mature and feature-complete yet, we exclude the Wayland features from our support promise. Users who want to use Wayland will be better off running the latest Plasma release in the next years, as there is still a lot of rather essential development going on in that area.

Running Plasma on X11 is of course fully supported.

Are there enterprise customers who need LTS? What kind of users are demanding LTS of Plasma?

We have been discussing this topic also with some of our enterprise users: They welcome this longer support cycle as it reduces their own cost of running the desktops, less churn on our side means less churn on theirs. In these use-cases, continuity often matters more than frequent feature updates.

Finally, there’s a large number of our users for whom Plasma does its job perfectly well. Especially with the amount of polish that has gone into 5.8, this is a very smooth desktop.

Won’t it add extra work to maintain LTS release plus regular release?

In short, yes. On the other hand, we think this overhead is manageable due to the degree of automation of the whole release process we have reached and the tools we use.

On the development side, it will also introduce a bit more overhead, which is however easier to manage in our git-based source code control system.While doing a new release is a little more involved than “hitting a release button”, the release and deployment process does not actually add that much overhead — we do it many times daily already through KDE neon’s continuous build, integration and delivery system, other distros (such as openSUSE’s “Krypton” flavor) do similar things.

How does it affect developers and integration with other components? For example what if a user wants to use that new feature of Kmail or Dolphin that’s introduced in regular release?

It’s important to keep in mind that the user will still be able to install newer versions of software (at least to the degree the distro allows it). There will be cases, where the user has to make a choice between advantages of newer versions and the convenience of a system that doesn’t change too much. We offer both, so the user gets to pick.

I am assuming there will be two releases of Plasma, will mixing apps from different releases break the system?

Not necessarily, but it may differ per app. If an app is happy with the same Qt and Frameworks version, it should be just fine, so it’s mostly a matter how a given distro solves the dependency chain.

Do you work closely with distros like openSUSE or Fedora to ensure that the new release of Plasma is synced with the new release of the distro?

A few weeks back, we were asked by the openSUSE guys if we could slightly change our schedule as to allow Plasma 5.8 into the schedule for their stability-focused Leap version. We have actually been talking with our downstreams about these ideas already a few months back and involved them in how we plan to make this LTS Plasma happen. It works both ways of course, so by providing this kind of additional support, we have an attractive Plasma release for distros with a longer support cycle.

Any other thoughts?

I’m especially happy how the planning across the stack falls into place. With Qt LTS releases, frameworks and Plasma LTS we have similar support cycles from these important upstream components, adding this on top of distros with longer support cycles shows how we can work across the stack effectively on a shared timing. It’s of course not perfectly synced.

After a while, we’ll see how this LTS Plasma works out, we’ll likely make some smaller changes to the release model as we go along. For longer-term planning, I think we should seek opportunities to align support cycles across the whole stack even more. It helps us to make more users happy. Looking further ahead, we’re not facing major architectural changes for some time to come. First of all, Qt 6 won’t be a thing for at least a few years, there will likely be another Qt LTS release in about two years, which could be a good base for a future LTS Plasma. Second, the move to Frameworks and the QtQuick-driven Plasma 5 has lead to a very modern, architecturally sound and future-proof system. It provides a stable core that is incredibly easy to extend to 3rd party sources.