KDE 4, distributors, and bleeding-edge software

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

Buried deep inside a recent interview with Linus Torvalds was the revelation that he had moved away from KDE and back to GNOME—which he famously abandoned in 2005. The cause of that switch was the problems he had with KDE 4.0, which seems to be a popular reaction to that release. Various media outlets, Slashdot in particular, elevated Torvalds's switch to the headline of the interview. That led, of course, to some loud complaints from the KDE community, but also a much more thoughtful response from KDE project lead Aaron Seigo. While it is somewhat interesting to know Torvalds's choice for his desktop, there are other, more important issues that stem from the controversy.

Never one to mince words, Torvalds is clear in his unhappiness: "I used to be a KDE user. I thought KDE 4.0 was such a disaster, I switched to GNOME." But, he does go on to acknowledge that he understands, perhaps even partially agrees with, the reasons behind it:

[...] but I think they did it badly. They did so [many] changes, it was a half-baked release. It may turn out to be the right decision in the end, and I will retry KDE, but I suspect I'm not the only person they lost.

There has been a regular stream of reports of unhappy KDE users, with many folks switching to GNOME due to KDE 4.0 not living up to their expectations—or even being usable at all. Part of the problem stems from Fedora's decision to move to KDE 4 in Fedora 9, but not give users a way to fall back to KDE 3.5. When Torvalds upgraded to Fedora 9, he got a desktop that "was not as functional", leading him to go back to GNOME—though, he hates "the fact that my right button doesn't do what I want it to do", which was one of the reasons he moved to KDE in the first place.

One facet of the problem, as Seigo points out, is the race between distributions to incorporate the most leading—perhaps bleeding—edge software versions. It is clear that KDE did not do enough to communicate what it thought 4.0 was: "KDE 4.0.0 is our 'will eat your children' release of KDE4, not the next release of KDE 3.5" is how Seigo described it when it was released. That message, along with the idea that KDE 4 would not be ready to replace 3.5 until 4.1 was released, didn't really propagate though. It was hard for users, distributions, and the press to separate the KDE vision of the future from the actual reality of what was delivered.

There clearly were users, perhaps less vocal or with fewer requirements, who stuck with KDE through the transition. The author notes that he went through the same upgrade path in Fedora without suffering any major problems. Reduced functionality and some annoyances were certainly present, but it was not enough to cause a switch to a different desktop environment. It is impossible to get any real numbers for users who switched, had a distribution that allowed them to stick with 3.5, or just muddled through until KDE 4 became more usable. But, without a doubt, the handling of the KDE 4.0 release gave the project a rather nasty black eye.

Seigo also minces few words when pointing to the distributions to take a large part of that blame:

I have to admit that it's really hard to stay positive about the efforts of downstreams when they wander around feeling they should be above reproach while simultaneously hurting our (theirs and ours) users in a rush to be more bad ass bleeding edge than any other cool dude distro in town. I hope this time instead of handing out spankings, the distros can sit back and think about things and try and figure out how they played an unfortunate part in the 4.0 fiasco.

There is no real substitute to distributions and projects like KDE working together to determine what should be packaged up in the next distribution release. It is unclear where exactly that process broke down for Fedora 9, but it certainly led to much of the outcry about KDE 4. But, if they had it to do all over again, how would KDE have handled things differently? Projects want to make their latest releases available to users, so that testing, bug reporting, and fixing can happen. That is the service that distributions provide. But users rightly expect a certain base level of functionality in the tools that get released.

To some extent, it is a classic chicken-and-egg problem. In his defense of the 4.0 release process, Seigo notes that releases, as opposed to alphas or betas, are the only way to get attention from users and testers:

Between the rc's and the tagging of 4.0.0 the number of reports from testing skyrocketed. This is great, and shows that when I assert "people don't test when it's alpha or even beta" I'm absolutely correct. This is not about tricking people either: people seem to forget that the open source method is based on participation not consumption. So testers look for a cue to start testing; that is their form of participation. "alpha" and even "beta" is often not enough of a cue, especially today when so many of our testing users are not nearly as technically skilled with the compiler, debuggers, etc as the typical Free software user was 10 years ago.

It would be easy to just fault KDE for releasing too early, but Seigo does have a point about "participation". Likely due to their exuberance at what they had accomplished for KDE 4, the developers were blinded to the inadequacies of the release for day-to-day use—at least for some users. The project needed to clearly get the message out that it might not be usable by all and it failed to do that. It's a fine line, but for something as integral as a desktop environment, it would have been better to find a way to release with more things working. The flip side, of course, is that it takes testing to figure out what isn't working—which is part of the service users provide back to the projects.

This is not the first time we have seen this kind of thing. Red Hat, and now Fedora, have always been rather—some would say overly—aggressive about including new software into releases. Some readers will likely remember the problems with the switch to glibc-2.0 in Red Hat 5. Others may fondly recall Red Hat 7, which shipped an unreleased GCC that didn't build the kernel correctly.

We may be seeing something similar play out with the recently announced plans to include btrfs in Fedora 11. While it has been merged into the mainline kernel for 2.6.29 (due in March), it is most definitely not in its final form. There are likely to be stability issues as well as possible changes to the user-space API. There is even the possibility of an on-disk format change, though Chris Mason and the btrfs developers are hoping to avoid it.

Much like with KDE 4, btrfs will likely benefit from more users, but there is the risk that some will either miss or ignore the warnings and lose critical data in a btrfs volume. Should that turn out to be some high-profile developer who declares the filesystem to be a "disaster", it could be a setback to the adoption of btrfs.

KDE 4.2 has just been released, and early reports would indicate that it is very functional. With the problems from the KDE 4.0 release—now a year old—fading in the memory of many, a rekindling of those flames is probably less than completely welcomed by the project. But the lessons they learned, even if solutions are not obvious, are important for KDE as well as other projects. Because free software is developed and released in the open, much can be learned from other projects' mistakes. It is yet another benefit that openness provides.