decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
KDE on KDE 4.0
Friday, July 11 2008 @ 02:42 PM EDT

There has been a bit of a dustup about KDE 4.0. A lot of opinions have been expressed, but I thought you might like to hear from KDE. So I wrote to them and asked if they'd be willing to explain their choices and answer the main complaints. They graciously agreed.

I was a bit puzzled at some of the complaints, because I use KDE, and when I didn't like something, I would just change it. For example, if I didn't like the new menu, I could right click on the menu icon and it gave me an immediate choice to go back to the old one. How hard is that? Could it be that at least some of what we are seeing is our old friend Stick in the Mud?

I asked that because a friend of mine just switched to Linux, and she chose Mandriva 2008, so I explained to her how to change back and forth and asked her to try both and tell me what she preferred. She reports she greatly prefers the new menu. I asked why, and she said she didn't know. It seemed to her easier to find things, less confusing. For what it's worth.

I confess I find the old one easier so far, but then I'm used to it. I do like to see immediately everything I have installed, so who knows? It's part of my personality to love to try new things. So I'm enjoying watching KDE move forward into new things, and I'm trying everything. Of course, I love trying things because I know I'm not stuck anywhere. I think it's fair to say I'm biased, therefore. I confess I love KDE. I like their attitude, and I'm sticking with them.

As I looked into it, I found it wasn't quite as simple as just old habits getting in the way. For example, I learned that if you are using Kubuntu, you can't just right click the menu. There is a way to get back to the old, though, which dburns figured out, which we'll share with you. But that part isn't KDE talking. I've added a footnote to the article about it. But the KDE guys say that your best option in Kubuntu, and indeed in anything, is just to upgrade to 4.1. That solves a lot of problems, they tell me, and more solutions are on the way.

But there has also been quite a lot of mean things said about motives and why this design or that was chosen. I suspect at least some of the fuss is deliberately done by those with a point of view. Who knows? Whatever. So let's settle back, and down if we need to, and let Sebastian Kügler of KDE.org and representing the Board of Directors present the KDE point of view.

His article includes three screen shots, so that those who don't use KDE can see what this is all about. I include smaller versions of the screenshots in the article, so our friends on dialup don't have such a struggle, but you will find links to separate pages where the originals can be found. Enjoy.

Update: I got a request to make the images clickable to make them larger. I didn't know how, but Groklaw's grouch did, so I've altered them as per the request.

******************************

11 Myths About KDE 4
~ by Sebastian Kügler, KDE e.V. Board of Directors

Lately a lot has been said (or bemoaned) in the community about KDE 4, the 4.0 release and the KDE developers. In the following article we would like to address some common misconceptions about KDE 4 as we see it. As we firmly believe in KDE 4 and the future of the Free Desktop, we expected the heated discussions about KDE4 and especially the 4.0 release to go away - and we were wrong about that. As blogging about the issues raised didn't seem to reach the audience we intended, we took the opportunity presented by Groklaw for this article with both hands. We sincerely hope it sheds some light on why the KDE community did what it thought it had to do and we hope it shows we do take the criticism seriously.

1. "KDE4 is finished"

Actually, KDE 4.0 is just the beginning. KDE 4.0 has the beginnings of a publicly usable desktop and applications. KDE 4.0 also marks the stability of the libraries and their programming interfaces so application developers can actively start using them in their application. The new features and frameworks need some time to be implemented in a user-visible way. In that light, KDE 4.0 marks the beginning of the availability of KDE4-technology-based applications.

Assuming that KDE 4.0 delivers the full possibilities of its libraries and frameworks to the user is unrealistic. The merit of the infrastructural work that has led up to 4.0 will be seen in the coming releases, with KDE 4.1 showing first signs of an increased pace of development thanks to the new foundations.

KDE 4.0 is the starting line, not the finishing line.

2. "Releasing KDE 4.0 was a mistake"

Many of the official release announcements posted on kde.org contained the following text: "The aim of the KDE project for the 4.0 release is to put the foundations in place for future innovations on the Free Desktop. The many newly introduced technologies incorporated in the KDE libraries will make it easier for developers to add rich functionality to their applications, combining and connecting different components in any way they want."

This has been consistent in all communications. We only failed with KDE 4.0 if we measure the work based on others' criteria, not our clearly stated goals. We're glad that so many people eagerly anticipated the 4.0 release, but in some cases the expectations were heightened despite our efforts. We do understand the excitement that built up over 2 years, but we've actually had discussions on trying to meter/throttle people's exuberance and expectations for 4.0 so that they would not feel let down when 4.0 was released.

On another note, remember that we were also working in parallel on the 3.5 series, which is still available. KDE 3.5.10, a new bugfix and translation update is coming in August. We encouraged users that were not ready to be early adopters of new technology still in heavy development to continue enjoying the 3.5 series.

So why did we release KDE 4.0 in January?

Let's look at it from a broader perspective for a while. Let's see it in the Grand Scheme of Things to Come. The big question that should come up is: couldn't we have released what will now be KDE 4.1 as KDE 4.0? If that would have been possible, it would surely have been the right choice. But it was not possible, because of several reasons.

Release early, release often. One of the pillars of Free Software development is to release your software as soon as it is useful to others, so people can jump in.

Nobody has ever promised that KDE 4.0 would be functionally equivalent to KDE 3.5. With KDE 4.0 we have delivered a stable set of libraries and a basic functional desktop. 4.0 in technical terms means: From this point on, our libraries will remain binary compatible until 5.0. Not releasing 4.0 at that point means holding back hundreds of application developers from porting and releasing their applications. Not releasing would hurt these applications - they wouldn't receive the attention to detail they deserved. We're talking about core applications like Dolphin, but also whole parts of KDE like the Educational applications, Graphics applications, and the games. Not releasing them would also mean less new contributors and users than they deserved - another thing we didn't want.

Yet the publicly perceived quality of KDE seems to concentrate on Plasma, the newest, but most visible component of KDE 4. For this kind of new technology, it simply takes a bit of time and feedback from users until the user experience we could deliver in the past can be reached.

A second issue is packaging. KDE 4.0 is relatively hard to package, not due to it being that difficult - packaging it is far easier and faster than KDE 3.x. But it is new, and new things always require an adjusting period. CMake, SVN, many new dependencies, many new architectural pieces, changes in the internal structure of the major KDE packages like KDElibs and KDEbase...it'll take a while for packagers to get used to those. We probably can't expect distros to put out KDE 3.5.x-quality packages for at least a few months. By the time 4.1 is released, though, they will have some experience, and will hopefully get it done rather quickly. (If you want the proof - just check out a few different KDE 4.0 distributions...they differ wildly in terms of stability, features, default setup, and more.)

A third reason is for finding rare, obscure, or corner-case issues. Many of the problems in KDE 4.0 can and will be fixed by the KDE hackers. But many can't. By pushing the boundaries of technology, you'll be pushed back. We've exposed issues in drivers, architectural issues in X, window management, Qt, and more. Without an earlier release to start getting user feedback, these simply would've appeared in the delayed first release, and would've bit users just as hard as they're biting now.

And finally, KDE is a very complex beast, technically and socially. It consists of hundreds of applications, an extensive development framework and a desktop on top of that and literally hundreds of contributors with diverse backgrounds. It is plain impossible that all those things happen to be finished at the same time. We were able to release a basic first version of the desktop along with the development framework and an already very good looking set of applications. We did fail in communicating well enough this complex situation. But then, we're software developers, we create software ...

3. KDE needs a fork

Forking software is always a last-resort alternative. Even though it's an option open to any software developer, it carries a hefty price and responsibility, which explains why it fortunately seldom happens. It's a last-ditch option to be used when the directions and management of a given software no longer match the vision that a developer or a group of developers have.

We do not think we're anywhere near that point. A fork is a necessity only when other alternatives have failed. Yet people are calling for a fork of KDE without even trying those alternatives. We call that irresponsible.

The KDE community is extremely open to new ideas, new contributors, and new directions. Any current contributor will vouch for that. Those people who feel that their needs aren't being tended to or who feel the direction KDE is going are more than welcome to join the mailing lists and voice their opinions.

Forking carries a hefty price in maintaining the forked code. KDE is a complex set of interconnected applications and libraries, totaling well over 3 million lines of code (according to Coverity's Scan). It's a no-brainer conclusion that, the more people working on it, the lighter the load. So it's definitely better to work with the current developers than to gather a new group.

Forks for KDE have been proposed in the past and have failed. Whenever those forks were proposed, the KDE community met with skepticism yet welcomed the would-be-forkers, inviting them to join the community instead. Even when code was published, the community responded by offering to work together and incorporate the improvements. In all cases so far, the invitation was not accepted, the forkers did not join the KDE community and simply abandoned their ideas.

Forking KDE 3 and porting it again to Qt 4 is a monstrous job. It took the KDE team almost 3 years to do it. We don't believe that any group of developers is willing to undertake that task again. However, the code is open. Should anyone want to attempt, we'll even provide commit rights to our servers.

4. "KDE needs to drop Plasma"

Most of the gripes about KDE 4 so far concentrate on Plasma. The rest of the desktop, the rest of the applications, and the libraries and frameworks are generally are very well received by end users, and certainly by those willing to adopt those new technologies early. Since forking all of KDE is out of the question on technical grounds (see above), some call for just dropping Plasma and resurrecting kicker and kdesktop. The people calling for a fork are invited to resume working on kicker. As on previous occasions, the KDE community welcomes those developers and we will provide them with accounts on our Subversion server if they wish to undertake that work. The code for those applications has been partially ported to the new KDE 4 libraries already much earlier in the development process towards KDE 4.0.

The KDE team has no plans to resurrect kicker or kdesktop, however.

5. "Plasma lacks functionality"

Plasma is a new development from the ground up. This was necessary because of severe scalability problems of the old KDE3 codebase containing kdesktop, kicker and the minicli (the Run Command dialog you get when you press ALT+F2). Also, the requirements for a desktop system have changed in terms of user expectations. Those components can now use new graphical capabilities such as compositing and animations, which was either very hard to do or plain impossible with the KDE3 technology.

Plasma in KDE 4.0 consisted of a basic traditional desktop with a panel and an application launcher menu. It was not meant to fully replace all functionality that has matured in KDE3 for several years. Plasma does however make it relatively easy to replace those components, so it can be extended with applets and code to be very powerful indeed.

The perceived lack of functionality is mostly due to the default settings and applets available in 4.0. As the technology matures and KDE 4.1/4.2 are released, we think that this complaint will become obsolete.

6. "I cannot put files on my desktop"

The folderview plasmoids (which are enabled by default) show files on your desktop and let you interact with them as if you were using a filemanager. Although it provides the functionality of "icons on the desktop," it is actually far more powerful. It lets you show arbitrary folders on your desktop, even network resources, and interact with the files as if they were locally stored. The user can also display folders other than ~/Desktop, filter certain filetypes, and so on.

Folderview enters KDE in KDE 4.1, replacing the somewhat clunky support for icons on the desktop in KDE 4.0. In KDE 4.2, it is planned to set a folderview as "desktop background".

folder view

The folderview Plasmoids lets you put files on your desktop

7. "The whole KDE4 desktop interface is radically new"

While the underlying technology provides lots of new means to interact with computers and will have even more ways of working with different sets of users on different devices, the desktop interface in KDE 4.0 and KDE 4.1 is mostly backwards compatible with desktops as we've seen them in the last 20 years, containing a panel to switch between applications, a menu launcher, and several bits of functionality such as the clock. Users are not forced to learn new paradigms unless they want to take advantage of new features such as the dashboard and applets.

The desktop interface has not been radically redesigned in the last twenty years. The KDE team is working on laying the groundwork for new and innovative ways of dealing with the desktop while providing the traditional ways of interacting with the desktop so current users are not alienated.

folder view

The folderview Plasmoids lets you put files on your desktop

8. "I am forced to use the kickoff menu"

KDE 4.0.4 and KDE 4.1 both provide the possibility to easily switch from the kickoff applications launcher to the classic menu style known from KDE3. To switch back to the classic menu, the user right-clicks on the K-menu button and chooses "Switch to Classic Menu Style".1

folder view

From kickoff's context menu, you can easily switch to the classic menu style

9. "The KDE team does not listen to its users"

KDE, as a Free Software project, is more open to its users than any other comparable software team. All mailing lists are open to suggestions, development can be closely followed through SVN, and developers are usually easily reachable for interested parties, either through their mailing lists, on IRC, or directly via email.

The developers do depend on precise information, however. Vague statements such as "I don't like the new foobar" are hard to address. Precise reports detailing current and expected behavior along with use cases (and sometimes a bit of patience) increase the odds of issues being addressed. Insulting, whining, or spreading FUD does no good to a developer's motivation to address issues; instead the usual effect is to cause the developer to become demotivated in regards to fixing a particular issue. Users that would like certain functionality in KDE 4 should be collaborative and helpful and open to new solutions.

A common understanding of acceptable and effective behavior in communicating with developers is expected, especially considering that the developers do not have an obligation to help and usually do it voluntarily.

In some cases, we need to balance out when to listen to certain users or not. After all, we are probably leaving some people comfort zone. There is always resistance to change, yet change is necessary for survival. A certain amount of room for innovation is needed, and in fact lies at the heart of Free Software. KDE 3.5 wouldn't be the stable product it is now without ignoring some of the voices once in a while, and KDE 4 would never become reality.

10. "KDE 4 vs 4.0 is confusing"

With "KDE 4" we refer to the complete lifecycle of technologies such as Phonon, Plasma, Solid, and so on. "KDE 4" spans the whole lifecycle. KDE 4.0 is the first release in this lifecycle, exposing new technologies to the public. Subsequent releases (such as KDE 4.1 and 4.2) build on the "Pillars of KDE4". The technologies that are there, but not yet visible surface as KDE 4 is around longer. Users, especially Free Software users who are typically considered more familiar with software options and availability, have generally had little problem understanding OS X and its subsequent versions, Windows XP and its service packs, Linux 2.6 and its point releases, and so on. KDE 4 is the new major software paradigm in the KDE project, and KDE 4.0 is simply the very first release. It makes sense that for the release, we have focused on the technical underpinnings and architecture to future-proof KDE 4 for years to come.

11. "KDE should just have ported KDE 3.5 to Qt 4 and not add all that other experimental stuff right away"

This is not a stupid idea and it was heavily considered. The problem with it is two-fold: social and technical.

Socially speaking, it assumes redirecting development effort is effective. To a certain extent it is, but for quite a few developers not developing features often means not developing at all. Not everybody is good at low-level stuff (or willing to do it). This has bitten us and other projects in the past and present. The development of KDE 4 has been slower than it would've been if we would be able/willing to force developers to work on whatever some top-down managers think is good...but it's just not how FOSS works.

Technically speaking, two arguments. First, an only-ported release would in time have to be reworked again, so we couldn't promise binary compatibility, and the first release would be useless for development of third-party applications. It would really be nice for users, but a total waste of time from the point of view of developers - the progress of KDE as a development environment would be minimal at best. And that development environment happens to be the major focus of KDE 4.0 - we want to push the Free Desktop further (long-term vision).

A second problem would be the fact the developers would have to port a huge amount of old code which wouldn't be needed on the new platform. Prime example here are KDesktop and Kicker. Many users asked the KDE developers to port Kicker and KDesktop to Qt 4, but they didn't because it would be a huge job and in the long run unmaintainable anyway. In other words, it would delay the release of Plasma by at least another year, with no long-term benefit at all. The same goes for audio and video capabilities, all chat and PIM related capabilities, etc. In other words, a LOT.

Innovation in technology will never go without changes. Changes will never go without naysayers. As much as we try to respect both sides, the desktop has hardly seen any real innovation in the last 15 to 20 years. The KDE developers need some room for new ideas to be able to push the Free Desktop to the next generation of computers and computer users.


1 The dburns workaround: In Kubuntu right clicking does not work the way it does in Mandriva. After looking at my options for a while I opened up the "Add Widgets..." option again and *then expanded the window*. The Traditional Menu based application launcher was now a selection. You could not tell the old menu was there unless the window was expanded. This was not here before, but there were a few things I downloaded for KDE4 the other day and the option might have been installed then.


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )