Why KDE Matters (and Why It Still Doesn't)
- Why KDE Matters
- Why KDE Still Doesn't Matter
- The Verdict
- Special Thanks
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Why KDE Matters
While doing research for my book Special Edition: Using Linux (Que, 2000, ISBN 0-7897-2543-6), I had the pleasure of following the KDE project very closely. I compiled the source regularly on the way to 2.0, read the mailing lists, and even contributed a few patches and comments. In addition, I've followed and participated in several other open source projects and worked in professional software development for several years now. I'm convinced that KDE is one of the best-run open source projects I've run into, and it fares extremely well against most professional software development that I've seen.
Schedule
Probably the most telling detail in any software-development group is the capability to define and keep a schedule. The KDE schedules aren't perfect, but the developers have done a good job of trying to keep to them. The most important thing is that there is a clear release plan, including a defined beta cycle and feature list. As the release date approaches, there is a willingness to push features into the next release rather than allow the current release to stretch on forever.
Vision
KDE is fairly strictly controlled by a relatively small number of like-minded individuals. Very little of the infighting often seen in other large projects occurs in the KDE group. Naturally, some disagreements arise, but typically the core KDE developers agree on the direction for the project. This prevent them from having the same arguments repeatedly.
Openness
Despite the fairly strict control that the core developers maintain over KDE, getting patches in is generally fairly easy, as long as you don't violate the component's vision.
Sometimes vision and openness are at odds. When this happens, the core developers have displayed the ability to explain why a patch is being rejected without creating a yelling match. When these issues start discussions, the discussions tend to remain civil and generally come to a successful conclusion. The same cannot be said on many open source mailing lists. Having had patches rejected both by the KDE team and by other groups, I can say that I far prefer the KDE team's tone.
User Focus
The KDE team has always focused on the novice user. There is a growing interest in simplifying the user interface to make Linux a less intimidating place. This is where open source projects often fail because they seldom do usage testing. Only time will tell whether the KDE team follows through with interviewing novice users and incorporating their comments back into the system. The fact that the team is trying, however, is unusual in the volunteer programming world.
This user focus has paid off in an interface that nontechnical users can feel comfortable with. There's still some distance to go, but the basis is all there.
KParts
The KPart component model has been extremely successful throughout KDE. By creating a collection of embeddable components, KDE prevents a lot of duplicated effort. Even more importantly, it allows for incredibly flexible tools such as Konqueror.
Konqueror is one of my favorite applications and, by far, my favorite Linux Web browser. It has features seldom seen elsewhere. For example, Konqueror enables me to manage my cookies on a per-site basis. I can accept cookies from slashdot.org but reject them from doubleclick.net. This doesn't solve all the cookie problems, but it does as much as the client side can do.
Using KParts, Konqueror can display all kinds of information in the same window. Some of the components could still use some work, but bringing them together in one window is incredibly useful, especially when using Konqueror as a file manager.
Responsiveness
The KDE team is incredibly responsive to bug reports. Bugs are often fixed within hours. More importantly, however, feature requests are handled well. Recently, a user submitted a feature request, and one of the developers complained that it wasn't a good request because it would require reimplementing a lot of code. Another developer stepped in and explained that the implementation details don't determine whether a request is good. Requesters don't (and shouldn't) care how the feature is implemented. Implementation details might prevent the feature from going in, but that's not the requestor's fault.
On some open source lists, a feature request is expected to be accompanied by code. This completely shuts out nonprogrammers and focuses the product more on only the needs of its developers.
The KDE developers are much more open to feature requests. Feature demands will not likely get you anywhere—feature requests with code, of course, are the most likely to get implemented. Still, the developers' willingness to discuss features in the absence of code is far from universal in the open source world.
If you have suggestions or bug reports for the KDE project, check out http://bugs.kde.org. First make sure that the suggestion or bug report hasn't been made before (the search engine makes this fairly easy), and then remember that you will catch more programmers with honey than vinegar.