All you people complaining about the state of Akonadi and the interconnectedness of KDE are missing an important part of the picture.

No matter what OS or desktop or GUI apps you have been using for the past 20 years, all of them have an implied conceptual data model underlying the collection of apps that you are using. For the most part, the "implied" bit has followed the old X11/Windows 2.0 "shared nothing" model, where bits and pieces of the data has been either replicated or ad-hoc shared (apps explicitly being aware of other apps and sharing data with them). This has worked okay for a long time, since users have assumed that this is the way it will always work.

Some of you folks may remember PalmOS, or are using Symbian and/or Android phones now. These platforms make the data model explicit, and all apps are aware of them. On an Android phone, the SMS, IM, Calendar and Contacts apps all know how to access the user's address book without knowing anything at all about each other. If you write a contacts sync backend, you don't need to care about any of those apps - you know how to access the contact data already from the database API.

What ends up happening is that YOUR DATA becomes the central focus of the platform. Not the app's data, or its storage format or anything like that. The apps are relegated to being clients of the larger data model. This is the correct approach for the future of the UI.

The KDE project has had its eye on this model of the future UI for a decade now. There has been bumbling and disorganization, miscommunication, dozens of key people coming and going, cat-herding and unfinished code. This is hardly surprising considering the size and nature of the KDE development team and its organization. Despite your irritations with the current state of a given KDE release, I think it's worth remembering what is being attempted here.

Of course, everyone's threshold is different and you may decide that being part of this massive experiment is not worth the headache. For you folks there are plenty of alternatives and I don't think anyone is going to be upset if you go back to the 80s-style UIs of other desktops such as KDE 3.x.

At the same time, don't be surprised if the KDE project doesn't make it a high priority to enable picking bits and pieces to run elsewhere; it's worthwhile, but it comes with a high opportunity cost that dilutes effort on the larger goals of the project.

The difference is that other contenders for the MMRCA contract will (apparently) come with source for the avionics software, while the F-16IN will not. It's not just India in fact; the UK is pissed about the "joint" F-35 for the same reason.

This is why I oppose the purchase of the F-16IN by India. It's a capable aircraft from what I understand and fits the MRCA requirements of the IAF, but I really really doubt that after facing its own gear in Gulf War I, the US is going to provide any country with sophisticated arms without a kill switch.

The other hero is the shepherd, who has bred the sheepdog since he was a puppy, has likely shared his home and food with him and made him part of the family, but will not hesitate to take him out the back with a rifle the moment he goes feral. We have plenty of sheepdogs, wish there were better shepherds around.

One of the major effects KDE 4 has had on the free desktop has been to light a fire under the metaphorical asses of Xorg and driver development. There has been tons of work going on in Xorg since the split, but until KDE 4 came along and proved that stuff like Composite could have a real effect on user experience (Compiz came first, yes, but that was more or less just bling until apps started using composite), there was not as much pressure and expectation from free desktop users.

Turn on desktop effects on any system using KDE 4 and if you have Xorg with good drivers, the difference in experience is startling.

The rate at which Xorg and some of the drivers are getting better is exciting, as is Qt and KDE itself, and this is in part due to the expectations that KDE 4 has set in the minds of free desktop users. Kudos to the Xorg and FOSS driver devs for stepping up. The next couple of years are going to be fun.

KParts is a non-unique concept implemented pragmatically, leading to KDE devs actually using it.

The entire framework, from querying, instantiating and integrating KParts is optimised for the common case, ie shared libraries used in-process on the local machine, which means it's easy to learn and use.

Other attempts such as Bonobo and the erstwhile KOM/OpenParts were designed for maximum flexibility but didn't catch on because they made developers' lives difficult for these common cases.