I often see software developers who use Qt looking for existing solutions and libraries. Developers using Qt want IMAP libraries, a way to create Tar files, and more.
Many such cool classes and features are part of the KDE libraries, but are rarely considered by developers using Qt. To them it seems that KDE is bloated, or maybe that depending on KDE just for creation of Tar files is unrealistic. To a large extent that is false, as libraries from KDE come in granular form already. The kdecore libraries take up just 2.5 MB of space. The kdeui libraries consume 3.7 MB of space. For comparison, QtGui is an 11 MB binary. Parts of the KDE libraries already depend only on Qt, such as Solid, the hardware abstraction.
So it is true that we’re not doing at all badly already, but there are still areas we can improve. Part of that extra work is in communication (*cough*), packaging and build system improvements which have already been happening across the whole contributorship. It’s really great that I can run a command like
debtree libkimap4 | dot -Tpng > kimap.png
and get an image showing just how few dependencies there are these days for KIMAP.
However, there are still some interdependencies in the KDE libraries that may make adoption more tricky. You can't have the plugin system or the asynchronous Job APIs without pulling in the localization system and the configuration system. This is the case largely for historical reasons and to some extent it is also possible to lessen that impact, but the currant state is that people who want to use parts of the KDE libraries fork the parts they want, and leave the rest.
I recently came across a word the Germans use to recognize situations like this in just a single word: Rosinenpickerei, translated as raisin picking. At first I thought, wow - The Germans have taken the concept of 'Choosing the required/desired parts of a whole, and leaving the rest behind' and squeezed it into a single word. Then I realized it was just like cherry-picking in English, so nothing to get all stereotypical about.
Turning it up to 11
Recognizing room for improvement, the KDE community organized a developer sprint meeting to focus on the platform and libraries right across the board. We've been running on 10 all the way up to now, and have come to the question of where can we go from here? We need that extra push over the cliff, so y'know what we do? We turn it up to 11. We have a in person face to face meeting for an entire week to tackle issues such as how we can improve Qt to make KDE software better. How we can improve KDE libraries to make the lives of Qt developers easier, and how we can improve the KDE platform to increase consistency among KDE applications.