Off the Beat: Bruce Byfield's Blog

A basic tenet of organizational theory is that, whenever the formal structures are inadequate, other structures emerge to compensate. And that, in a sentence, may explain why KDE Neon has emerged.

KDE Neon is a project organized by Jonathan Riddell, the ex-community leader of Kubuntul. Its goal is to provide a repository for the latest KDE packages.

That sounds like a simple goal, but it was questioned almost immediately. In particular, podcaster and openSUSE marketer Bryan Landuke criticized KDE Neon as being basically Kubuntu under another name. Landuke also seized on a comment that KDE Neon was based on Ubuntu because it was "the best technology" as an insult to other Linux distributions. KDE Neon violated the usual distinction between desktops and distros, he suggested, and that blurring could cause trouble.

I suspect, however, that it's far too late to worry, because that blurring has already occurred. If it wasn't already happening, it started when Ubuntu withdrew from GNOME development to develop Unity. Ubuntu has done much the same in developing Upstart and Mir, preferring to develop its own backend tools rather than staying with its more traditional role as a packager of software and becoming a creator.

Both GNOME and KDE have flirted with the idea of their own distros, and for several years prominent KDE developers did their best to develop a free-licensed tablet -- a goal that Ubuntu is about to make a reality.

An argument can be made that free software projects should stick to what they know best for the sake of efficiency. However, after some six years of this blurring of functions, I suspect that anyone who carea is more or less used to it, whether it's a good idea or not. For instance, far from being insulted by KDE Neon's use of Ubuntu, I suspect contributors to other distributions will take the comment about "the best technology" to mean no more than the obvious fact that Neon's builders are most familiar with Ubuntu, and prefer to work with it.

Organization Compensating for Organization
As for KDE Neon, it has become necessary because KDE no longer uses a single release number for its software. Instead, since 2014, KDE divides its releases into KDE Frameworks, KDE Plasma (the desktop) and KDE Applications.

This division is convenient for developers. For example, instead of Plasma developers trying to sync their work with that of developers who work on various applications, everyone can go their own way without rushing to catch up with one sub-project, or waiting for another.

In the last few years, when KDE was transitioning to Qt5 and Plasma 5, I imagine that the arrangement made sense, especially with everyone eager to avoid the misunderstandings that surrounded the release of the KDE 4 release series in 2008. The arrangement makes it easier to prevent distributions from packaging software that is not meant to be in the hands of general users yet.

For users, however, the three different numbering systems is nothing except confusion. Should they care about an announcement of a new KDE Frameworks or Plasma? More importantly, how do they know that they're getting the latest software? Having three sets of version numbers makes answers difficult to come by.

The situation is especially confusing for reviewers or anyone outside KDE who wants or need to keep up to date about developments. In theory, they can download the latest code and compile it for themselves, but often these people have no time for compiling. They may also be unsure how to compile without looking up the procedure.

For such people, KDE Neon offers a relatively straightforward alternative. In 20-30 minutes, they can download and burn a CD, and start looking at the latest software.

Returning to the old numbering system might be even easier, but, I see no sign of KDE considering that solution. Besides, returning to a single version number would cause more confusion while the release numbers were re-synced, and users would still have to wait for their distribution of choice to install the latest versions.

By contrast, so long as KDE Neon meets its goals, users who need or want the latest of everything should be able to get want. Meanwhile, developers in any of the three sections of KDE development can continue to enjoy the advantages of this arrangement, the problem solved by the addition of another organization.

Very few, I suspect, will ever install KDE Neon on their hard drive -- or, perhaps, burn its latest image to DVD. Instead, many will not only install it on a virtual machine on a regular schedule, furiously taking notes all the way.