The KDE project has released the fourth beta of KDE 4.0, and with it a call for end-user testing. The project faces a major challenge in getting this major release stable and functional enough to meet users' expectations in time for release. The reason for this lies not only in the extent of the changes made to the underlying platform libraries that we looked at last week, but also in the collision of ground-breaking new development and a mass user base.
A good example is Plasma, which in the eyes of many users treads a fine line between promise and hype. The desktop design calls for the combination and composition of panels, applets, icons and menus, featuring scalable graphics, separated data and presentation, and scriptability to allow access to applications, data ,and online services. This flexibility and power has the potential to meet KDE's needs in a landscape where Free Software has to compete with proprietary alternatives not only on stability and features, but also on usability and appearance. It is, however, a tool being built from scratch without direct foundations in existing software, and this shows in the number of missing and limited features seen when the current Plasma code is compared with Kicker and KDesktop, its predecessors from KDE 2 and 3. These shortcomings present a dilemma to the project, given the evolution of the Linux community, which is larger and encompasses a far broader range of users than at the time of the last major KDE release.
The success and undeniable growth of the Linux Desktop into the mainstream exposes KDE to a bigger audience, which uses it not just as hackers and enthusiasts do, but who depend on it for daily enterprise and personal needs. Their participative relationship with developers allows for open criticism and skepticism. As a result, some voices within the KDE community feel that KDE 4.0 in its present state does not provide the quality expected of it and the release, already delayed, should be put back further.
Other KDE developers, including old hands from the early days, point out that the only way to create the momentum and pressure needed to perfect KDE 4 is to brave the release process, and get a "dot-zero" release out there and installed on adventurous users' computers. The reality is that a community project does not deliver perfection as a fait accompli but approaches it gradually, with the iterative refinement that mass use and feedback bring.
Parallels are being drawn with the Linux kernel release process, where a stable major kernel release in its .0 form contains so many new and unproven features that distributions only provide it as an option. As a result, acceptance is growing for making a release that has neither every feature of the previous stable version, nor complete implementations of the technologies that have kept hackers awake at night and inspired their blogs for months, but will form a stable platform for the years to come.
Introspection and reflection is emboldening the project to break with discarded approaches and past technologies, and present its efforts to users, but with KDE Beta 4 the project is looking towards the stream of bug reports coming from users installing it from distro packages, in order to make RC1 in two weeks, and 4.0 in little over a month, as solid as possible.
reader comments