personally i divide the software we release as "kde" (e.g. "kde 3.5") into three groups in my head: development framework, workspace, applications. the workspace is stuff like kdesktop, kicker, kwin, kcontrol, konqueror. applications include kcalc, juk, kooka, kalzium, etc. these are not official definitions, they are just how i personally organize the chaos.
looking back at kde2 and kde3 and how our application set grew, i've been wondering if the process could be improved. right now we require that the application has wide appeal (it can't be niche), must use KDE libs, has to be reasonably feature complete, needs to be maintained and can't have legal or security problems. that's actually a fairly low bar and it doesn't really touch on a number of important issues.
obviously, documentation and HIG compliance need to be added to this. but it's more than just that. whenever we add an app to the official kde application bundle (we so need a name for that), we end up stifling third party projects in that same category. we also allow someone to march in with a 1.0 version of an application and put it into svn without it being proven first.
this didn't matter so much when the majority of people who wrote kde software worked within the main kde project and when there were a limited number of kde software projects out there. but that's not the case anymore. today we have a huge community of developers, we have kde extra gear and we have kde-apps.org.
imagine if we had picked a cd burning app for inclusion in kde back when there were four (or more?) kde cd authoring apps in development. would we have picked k3b? would k3b have become as popular? would we have picked one of the other apps that later became unmaintained?
on the flip side, we have apps that went into kde right away. some of them got me really excited as they brought capabilities to kde. but some of them didn't really take off much and remain problematic to this day. now i wish that we'd let them sit out in kde extra gear for a while and see how it went: were they maintained? did competition arise? what did the users pick?
after a while it becomes obvious which apps to bundle: kopete and superkaramba are two examples of this process. k3b, digikam and amarok are probably ready for this now as well.
perhaps with kde4 instead of saying to people "if you're willing to maintain it, commit it!" we ought to instead start our apps out in kde extra gear and migrate the best of the best into our app bundles.
this may end up changing how our release and development cycles look when it comes to applications, however. our app bundles may become snapshots of the last stable release of many apps, while they continue to be developed on their own (and perhaps faster) development cycle. or perhaps we make it easier for apps to branch for a release and continue development. both kopete and kontact have done this in the past.
it's interesting that most distributions already include apps outside of our app bundles (e.g. k3b) as a standard part of their kde offering. so why have app bundles at all? to help guide and direct users, developers and vendors as to what can and should work well together. it's a service of selection we offer to downstream users, and it helps our documenters, translators and developers know what pieces of software to prioritize their efforts towards.
now, obviously, some apps are "must haves" and we can't wait for a longer trial period (particularly elements of the workspace), but for most applications this should work out well.
the goal should be to have high quality, well maintained applications shipped with kde and those are metrics that take a couple of releases to assess, IMHO.