applications: getting to good

alan cox, kernel developer cum mba and red hat fellow, was quoted today as saying that when it comes to the open source desktop, "What matters are the applications."

from a user's point of view, obviously he is correct. when i'm at a convention showing kde to people, for most users it's the apps that make their jaws drop and their feet run to the nearest kde ftp server. from a "getting work damone" perspective, just as your average user doesn't (or at least shouldn't) care what operating system they are using they probably couldn't care much about the underlying desktop technology that makes their email application and word processor go.

this doesn't mean that the desktop framework isn't important, however. now, whether or not the operating system and desktop environment is Free software is no small concern, and i'm fairly rabidly pro-open source; but even looking at it from a strictly nickels-n-dimes sense it becomes obvious that the desktop itself matters a lot because the applications are what matter.

good applications, and more importantly good sets of applications, come from a combination of two things: determined (primarily) and talented (secondarily, but still critical) application developers and a good development framework. you can have excellent app developers, but if you give them crap APIs and technology to work with they'll struggle to make something half decent and spend twice as long getting even that far. and you can forget about good sets of applications.

a quick diversion: what do i mean by "sets of applications"? very few applications get used on their own these days. the UNIX shell was the harbinger of this, of course, as it showed some 30 years ago that when applications work seamlessly together it makes for a most compelling environment. so today our instant messaging app is expected to work with our global address book; our web browser and our feed agregator should work together; our office apps should all integrate with each other (not to mention with the groupwware); calendaring and mail being workmates is a no-brainer today as is good groupware server support. this means that applications that stand on their own, while they do exist, are rarer and rarer and of increasingly lesser value than those that play well with others. extra points for apps that give the user a choice in which application and services it will work with. (ok, so that wasn't such a quick diversion)

a good application development framework lets app developers:

• produce less buggy code


• interfaces that conform to standards


• work quicker (less lines of code, fewer unexpected problems)


• integrate and interact easily with other applications

to that end, kde has one of the best development frameworks out there today. why? here are my thoughts on that:

the kde project has no corporate agenda like microsoft or apple who have a vested interest in protecting the application spaces they each play in. you think microsoft wants to make it easy for others to create competing word processors? nope. in contrast, kde is a community driven effort whose sole goals are to create awesome technology and get it out to as many users and developers as possible. that means we're incentivated (to use a horrid manageresque term ;) to make a good framework, even when it might help make a 3rd party app better than one of our own.

example: we ship with juk, a great little media player that is playlist centric, kicks ass at tagging and otherwise tries its best to stay out of your way while playing your music. meanwhile, amaroK is an application that is developed by people in our greater development community which is so amazingly killer in its network integration, hardware player support (think: iPod) and general eye candy and usability sweetness that the Ubuntu project actually bent their freeze date rules to allow it into their next release! and instead of fearing for juk's popularity, everyone (including the juk authors i know) cheer for this success. ask steve jobs what he'd think of someone competing with (and beating out feature-wise) iTunes on MacOS.

the kde project is committed to documenting our interfaces. due to the diligence of people such as the folks at the english breakfast network (yeah, i'm looking at you, ade :) and the hundreds of hackers who continue to keep their API docu up to snuff, we have comprehensive API documentation which is further supported with further developer-centric information. the Qt documentation is even more impressive.

and what's nice is that our docs tend to be accurate and we never try and purposefully obfuscate things. we couldn't hide if we wanted to: it's open source! and additions to our documentation are always accepted, making it a community effort.

not resting on our laurels, we've been talking to 3rd party developers and finding out what more they need to really rock the kasbah when developing and i think we have a pretty good handle on it now. things are a-brewing for KDE4 that will take us to the next level in documentation.

we have superb technology. and when i say superb, i mean really nice. from DCOP to KParts to "3 lines of code and you have fully user-customizable toolbars" to XML based configuration definition (complete with the code generation and the ability to drive your config dialogs with it) to zero-fuss network-transparent data access (think "every app can open and save via $NETWORK_PROTOCOL") to quick 'n easy network-distribution of configuration and data updates to consistent and clear API design to ... well, you get the idea.

and that's stuff that's available today in KDE3, which is a platform that's had some 5 years of use and maturation. we're already working on KDE4 which builds upon that and will be bringing even better support for things like multimedia, component technology and more.

you're the app developer, so you choose how you like to develop. prefer python or ruby to c++? hey, go for it! don't like IDE's? (we do have a great one in kdevelop if you do, though) then break out the kwrite/vim/emacs and have at it! don't like developing on linux? do it on pretty much any other UNIX then; and with KDE4 you'll have the option of native environment hacking on MacOS X and MS Windows. just because you write your app with kde libraries doesn't mean kde is going to try and dictate the mechanics of doing so to you.

it's all open source. this means not vendor lock in, no fear building on a toolkit today that you won't have access to tomorrow and every invitation to help refine the platform upon which you base your applications on.

i could go on for another few thousand words, i'm sure .. but that's the gist of it from my perspective. when i look at the amazing applications we have for KDE these days, it doesn't surprise me in the least: we have some awesome app developers out there and they have an awesome app framework to build their programs with.

so when wise people like alan cox say the applications are what matter, he also means is that we better have the best possible application development framework available going for us.