KDE and the Naming of Parts

Off the Beat: Bruce Byfield's Blog

KDE concluded long ago that names were an important part of branding. However, looking at the latest changes, I am genuinely undecided whether the effort to brand through names is worth the effort, or is only likely to cause confusion.

The concern with names goes back to the earliest days of KDE, when every application began with a "K" (Kate, K3B, Konsole), or at least contained a "k" somewhere in the name (Amorok). By the release of KDE 4, this convention had been dropped, but the new modular sub-systems were all given names (Akonadi, Plasma), few of which except for Phonon, the sound controls, had even a hint of their functions.

In 2009, KDE announced a change in its branding. KDE would refer to the community and its common technology, KDE Plasma to the desktop, KDE Applications to the utilities and KDE-specific software, and KDE Software Compilation to the release of all together. More recently, these names have been revised to reflect the current reality, so that while KDE still refers to the community and the technology, the divisions are now Framework, Desktop, and Applications, all of which are released when they are ready, which does away with the Software Compilations. These may be prefaced with KDE for clarity, in the same way that people used to talk about Mozilla Firefox.

Building the foundation after the house
These changes and the latest set of names are probably easy to follow if you are a regular KDE contributor. In fact, they may seem a simple reflection about how the community operates.

However, to end-users, I wonder whether the current crop of names is more anti-branding rather than branding. That is, instead of clarifying the KDE brand, they may very well muddy it.

The trouble with the latest set of names is that it makes distinctions that users are not accustomed to making. Part of the trouble may be users' innate conservatism -- they are used to "KDE" referring to everything the community does, and never mind if the community's activities have outgrown that simple designation.

However, just as importantly, the names make distinctions that users care or understand little about. That means that, when one of the three categories is released in the foreseeable future, the KDE community is likely to be fielding queries about where the rest of the release is. Alternatively, end-users may puzzle over exactly what is being released, and simply shrug and ignore it.

There is also the problem of convincing editors  to use the changed terminology. As with the debate over "GNU/Linux" and "Linux," the majority of editors are going to choose the terminology with which most users are familiar. In other words, they are going to continue to use "KDE" for everything, adding to the confusion with inaccuracy.

Yet another potential problem is what happens if the numbering of the Framework, Desktop, and Applications is out of sync by even a few months? When everything has the same version number, users can easily see what they should install. But how do users evaluate whether they should use Framework 5.18 with Plasma 5.12 or Applications 5.14? Since each will apparently be released on its own schedule, a divergence in the release numbering seems sooner or later inevitable unless some care is taken.

From a development viewpoint, separate releases of Framework, Desktop, and Applications makes sense. A set release schedule for all the software is artificial and difficult to coordinate, and it seems only fitting that the changes in development should be reflected by changes in the name. Perhaps, too, the separate releases will prevent any replay of the user revolt over KDE 4.0. But the distinctions are apt to be lost to outsider, and promote incomprehension rather than clarity. The developers, users could easily conclude, are out of touch again.

The need for promotion
None of this would be insurmountable if KDE did more than announce the changes. Rebranding an already long-established product is far more difficult than branding a new one (and rebranding for the second time in five years more difficult still) yet little more has been has been done than announcing the changes in a blog or two.

To have the latest round of changes widely used, KDE needs to do far more than it is doing. Its publicists need to explain one on one to journalists and editors why they should adopt the new nomenclature. They need to promote the story behind the change, making clear that it is more than a geeky obsession.

Most of all, KDE needs to talk to distributions and encourage them to answer what is probably end-users' most basic concern: When should they upgrade? Each time a new Framework, Desktop, and Application is released? Or can users assume that a Live CD for an Application release will include the latest compatible Framework and Desktop? Even if the answer is to consult with your distribution, users need to be told far more than they are hearing now. The answers are not difficult, and some users may be able to guess them, but they need to be told how to respond.

The new names are not merely an academic exercise; they reflect substantial changes in how KDE software is name and produced. But the KDE community needs to do far more than it currently does to explain the necessity. Otherwise, the name changes could potentially leave KDE in less clarity than intended.