Seth Nickell wrote a blog entry about the relation between Gnome and KDE. The short summary is that Gnome and KDE are just two flavours of the free desktop(.org) that are technically too different to be merged, but work toward a common higher goal and should thus share as much components and standards as possible.

I disagree. While I see reasons why freedesktop.org is necessary (integrations with platforms like Wine and Java, legacy apps and everything else that is not available for KDE yet), a free desktop is not the ultimate goal for me. A free, well-integrated, high-level platform is the goal. Gnome is not the target, Java and .Net are.

I want to use Qt and its derivates, like KDE and OPIE, as a platform for everything from handhelds to servers. If I like KDE's functionality for writing desktop applications there is no reason why I should not use it when writing software running on a web server or extending an ERP system. Free software lacks a coherent and comprehensive API that would allow efficient development of high-level applications. There is a huge selection of free low-level C libraries that do not follow a common coding, naming or documentation standard. There are specialized libraries for languages like Python that are pretty useless for everybody else. There are clones of the class libraries for proprietary VMs like Java and .Net, but you can not easily use them from compiled languages and their developer's goal is compatibility, not a good API. KDE could be the missing framework that allows free software to reach a similar or even better developer productivity.

Becoming a complete platform is inevitable. A desktop platform that is able to compete with .Net needs at least 80% of what a complete platform has anyway. You need a good XML framework, networking, web services, access to directory services, a security framework, database access, telephony APIs... it would be stupid to produce such a huge amount of code and then just use it for desktop applications.

There are, of course, a few pieces missing in KDE. The most important is a good way to access KDE/Qt APIs from scripting and VM-based languages, without having to maintain wrappers manually. Also important, if KDE's APIs are destined to grow, they need a better structure.

When you see KDE as a platform, and not just as some code that implements a nice desktop, at least my stance on many proposed freedesktop components changes. When you want a desktop that mixes KDE and Gnome applications, a unified virtual file system with components written in low-level plain C (like DBus) may make sense. But when your goal is a platform this is less important, and there is a huge disadvantage: such a system would require KDE developers who want to add a new plugin or debug the virtual file system to learn another programming framework. And, when plain C is used, one that is less productive. There are cases when using C components is necessary, because the cost of producing a replacement is prohibitive, or nobody is interested in implementing it using KDE technology. XFree is a good example of that. But in general the goal should be to have at least good integration with KDE at both the API and UI level, and ideally it should be implemented in KDE-style, for the sake of debuggability and code re-use.

Qt/KDE's APIs still need many features before they can be a competitive platform. A lot of Posix functionality is not available without accessing low-level C APIs, the XML implementations have a feature set that is comparable to 1999's Java or MSXML APIs, there is no suppport for security and encryption APIs, and I could probably go on and on (just look at Java's package list). But it is a solid foundation, actually a better foundation that everything that I have seen so far, and there is no competitor in sight.