By Jake Edge
January 28, 2009
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.
(
Log in to post comments)