Give KDE 4.0.0 love, time and bug reports only
There have been a host of articles and comments around the blogosphere, written after the launch of KDE 4.0.0 criticizing it for being released at the time it has and being just “oh-so-buggy”. Let me begin with this OSNews article on KDE 4.0.0. The review is fine when it comes to reporting a few kinks here and there even groaning about the fonts which might not be visibly appealing to everyone (I mean, opinion varies). And of course, its again the situation when users review three or four exciting features of KDE 4 without reminding or telling readers that there is more hidden treasure underneath in the form of the excellent new framework and technical backend.
Amidst the reactions to this article were a few comments that caught my attention, beginning with this one by dagw:
The KDE team obviously shot themselves in the foot with calling it 4.0. I’m sure they had a reason for not calling it Beta or Developer release, but whatever the reason it was a bad one. Especially since every complaint is met with a response of “well what did you expect, it’s a Beta software”. No matter which way I look at it, the KDE team screwed up this release, and it would probably be in their best interest to admit it and just flat out say, we jumped the gun.
What’s weird is how it is self-contradictory when he goes on to add, “That being said I’m in no way criticising the underlying technology. I’ve looked at the new framework and libraries, and they look pretty damn amazing.” Now in case any of you are planning to review the KDE 4.0.0 release or try it out, then keep these KDE 4.0 Review Reminders in mind.
To address the release timing point, I would say that if KDE 4.0.0 had not been released now and had been put off for a 4.1 release with those very features then it could result in a delay for other KDE applications as well. Once the KDE 4.0.0 team has presented a basic desktop with the developer framework in place, it serves to help developers of Amarok, Kopete and other KDE applications, if not in a large way considering that they would have to focus on their own features and stability, but to atleast help them finish the applications. It would also mean that people can take up new and current projects early on and eventually converge to a point when we have one amazing, complete desktop. One of the readers of the OSNews article gave the right details to describe what I’m talking about:
Amarok was ported in 2 days to OSX and could have been ported faster, according to developers. Phonon allows a media player to use GStreamer or Xine on Linux/BSD, Quicktime on OSX and DirectShow on Windows without changing code. Same goes for Solid, which will allow use of removable devices, Bluetooth, WiFi, ACPI on all supported OSes. And have a look at the impressive Decibel framework.
There’s much to be said about KDE4 besides Plasma and SVG rendering, but reviewers aren’t looking in the right place.
The Road to KDE 4: Phonon Makes Multimedia Easier
The Road to KDE 4: Solid Brings Hardware
Configuration and Control to KDE
The Pillars of KDE 4: Decibel
The Pillars of KDE 4: Decibel Definitions and Benefits
Jos Poortvliet, a KDE volunteer points out in his response to the article that packaging is also a tricky issue with there being a time period required to adapt to the release, which eventually we have to do. He also shares the point that other applications would be affected, primarily the ones in the main KDE desktop right from basic applications like Kate or Juk to the KDE-Edu project.
The community would suffer the most with a later release date - this is what most users do not realize. The community consists of contributors broadly of two types - users and developers. Users submit their feedback and the bugs they moan about on the blogs but sometimes don’t bother to officially report thinking its already done (yes, it tends to be a common perspective). They are also the ones who are mainly waiting for the finished product. The developers are the ones behind the project and receive the users’ feedback, adding new features and fixes and responding to the user community. So simply put, a later release would mean a longer time to review, which in term would mean a longer time required to fix bugs and keep rolling in the features.
KDE 4.0.0 is in a state where it can be used. After all the warnings you must have received or received here, it is probably clear KDE 4.0.0 is not ready for full-time usage but it will certainly crash less and let developers carry out their work and probably allow you to contribute. If 4.0.0 for some reason just refuses to run on your computer then wait a bit longer for 4.0.1 or 4.0.2 (which I cannot say will be officially announced, but you can always ask on IRC or check the repositories of your distribution that has KDE 4.0.0). This release will ultimately attract more users even if it does happen to temporarily put them off with features being unstable or “not ready” according to them, because watching the efficiency with which things get fixed and new stuff appears will keep make them stick around.
You might have also realized that there are just a handful of distributions that are offering KDE 4.0.0 in their repositories or development releases. I’ve seen a couple of requests on the Arch Linux Forums for putting KDE 4.0.0 in testing but I do not think that it would make sense. The big guns like openSUSE, Ubuntu and Fedora have a good number of developers to test and package this release and true stability would be witnessed in KDE 4 when the majority of the distributions start adopting it as their main or secondary KDE version.
Calling KDE 4.0.0 a step backwards is a little too strong for a couple of complaints about the theme so I do hope this pretty lame situation improves. If you want to hear it from the boss himself, Aaron Seigo’s post on why KDE 4.0 should be release now is a great read. Till then just give this sparkling new desktop environment a little time and patience even if you cannot love it (how you cannot love it is beyond me but then again we’re all different!). Stand up and be counted by getting involved in the process. Learn a programming language like C++ or Python or brush up your existing skills (as in my case), try to see if you can find bugs and learn how to report them here.
While you do all this just remember to leave the reality for once, and live the dream!
Leave a Reply