[kde-community] Applications in KDE Generation 5

John Layt jlayt at kde.org
Wed Jan 15 20:47:17 UTC 2014


It's time we talked about Applications.  With the Frameworks and
Plasma Tech Previews out the door we have applications starting to
port to the hot new stuff, and we need to start discussing now how all
the decisions being made around Frameworks and Plasma (such as the new
Plasma naming scheme) will impact our Applications.  What does it mean
to be a "KDE Application"?  How will we organise their development and
release?  How will we describe and promote them?  The reason I'm
raising this on the Community list rather than the Devel or Release or
Promo lists is this really is a discussion about how we organise our
community. I've talked about this with a few people at KDE events over
the last year, and there seems a rough consensus that our current
module organisation and the SC concept no longer reflects the way our
community works both socially and technically, and so needs an
overhaul to better reflect how we actually work today and to present
our users a more compelling and co-ordinated vision for the future.

At the core of everything are the modules.  These are partially an
artefact of our use of SVN to organise groups of people with similar
interests to attack app domains that needed FOSS solutions.  They
usually revolved around a community mailing list and bugzilla
category.  Some modules were created simply because we had to have an
SVN repo for code to go into.  If we look at the modules now, while
some are still thriving active communities with well-maintained apps,
others are moribund or effectively dead with their apps slowly
bit-rotting from lack of attention (and a lack of visibility to the
wider community that this is an issue).  Some hover somewhere between
the two.  This might not be so bad if the bit-rotting apps weren't
also a part of the SC where they give users a poor impression of KDE
Applications, as well as contributing to the sense of 'bloat' when
people go to install a "full KDE desktop experience" and get a
million-and-one small and mostly useless utilities.  Some of these
apps hardly seem relevant to a modern end-user experience, or
integrate poorly with our modern workspace.

We can do better than this.

With all the work around KF5, Plasma 2, the separate git repos, and
possible separate release cycles for Frameworks, Workspaces and
Applications we have a chance to do a through review on the state of
the modules and apps to ensure that our next major release is one that
meets both the needs of our developer community and the needs of our
users, today and for the next 5 years.  What does a modern
desktop/tablet/mobile *really* need?  What is essential for a
workspace, and what are just "extras"?  How do we organise this all?
And what the heck do we call it?

The main points I think most people I talked to agreed on were:

* A number of our apps and utilities really have had their day and
need "retiring", e.g. KsCD, Kppp, KFloppy.  There's no point keeping
low-quality or unmaintained apps around just to try ship a "complete
desktop experience", especially if there are other better apps out
there (even if not KDE ones).  Being part of the official release
should be a stamp of quality: make apps work for it.  Lets go through
the existing apps and agree what needs dropping to Extragear or

* There are a lot of high-quality utils, apps and libraries in
Extragear that better deserve to be in the main release, lets go
through them and see what deserves to be "promoted".  Things like the
NetworkManager plasmoid, Ktp, and KScreen are already on the list to
move, but what else is there?  Lets have a look and talk to their

* Can we have a clearer split between Workspace and Application?
Perhaps it's time we moved Workspace essential tools like KMix from
being the responsibility of a module to being part of Workspaces?
(i.e. don't move the NetworkManager plasmoid from Extragear into the
Network module, move it to Workspaces).  This ensures the Workspaces
community have better visibility and control of they things they
really need, especially if they split release cycles.

* Do we need small utilities like KCalc as stand-alone apps, or do
they belong in Workspaces, perhaps as Plasmoids?  Where do we draw the
line between them?  And if there's both a Plasmoid and an App for
something, which goes in the main release?

* Application domain-specific libraries such as libkipi or libkcddb
may now be better organised under Frameworks rather than their
modules, where they could gain a wider user base and a clearer
maintenance viability.  Can we have a Frameworks category for non-api
stable libraries?

* We have things like thumbnailers, kio slaves, dolphin plugins and
strigi analyzers under each module, would these be better organised
into meta-groups in Extragear so they're easier to find?

* Can we create a "proper" KDE SDK?  We have the SDK module which is
really a mix of general development related apps and KDE-specific dev
tools, and we have Examples, and we have a few other bits-and-pieces
scattered around.  Can we split the apps off to stand on their own
repos in Extragear, and merge Examples and the other tools into SDK?

* What "essential" apps or utilities are we now missing for a modern
user?  What do we need a "call-to-action" to try get people to work
on?  Lets make a list, not a long one though, just what is really
really really essential.

I think those are fairly uncontroversial, but I feel that's not quite
enough, it's just cleaning up the existing modules.  I'd like to see
something more radical: I'd abolish the Software Collection, the
Modules and Extragear.

Instead, lets just talk of our Communities and Applications and
organise things by categories.  Communities could be at a topic-domain
level, or just at a single app level, there should be no difference in
the way we treat or consider them, and there is no need for all their
apps to be released at the same time, or the same time as the rest of
KDE's products.  Applications are not *in* or *out* of a Software
Collection, there is no distinction with Extragear apps, there are
just KDE Applications.  There should be no difference in the way we
treat or consider Applications other than where they are on the
application maturity cycle and what release cycle they follow.  This
emphasises the clear separation between Workspace and Applications,
you can install a KDE App with a minimum of dependencies on any
workspace you want.  We can still have a regular KDE Applications
Release, but it is then up to individual communities or applications
to opt in to that release cycle, or to decide to release on their own
cycle.  Strong communities with a distinct identity in the wider FOSS
world, like PIM or Games or Calligra, may find it better to have their
own separate release cycles and promo efforts, but I suspect most will
stay with the regular release cycle.

What then takes the place of the Software Collection?  I'd propose a
new collection of apps called KDE Essential Applications.  This would
be a collection of high-quality applications that are considered
essential to a modern user experience and that the KDE community as a
whole guarantees to maintain to the highest standards.  These would be
apps like Kate, Dolphin, Gwenview, Okular, Konsole, Ktp, etc, those
tools that you need to use every day and want to work well.  Distros
and users would then know that this is a group that they need to
always install, with the other apps in the common release cycle being
optional but still of decent quality.  Rather than these apps being
maintained separately inside their old module communities, they would
be organised into a new community that takes a shared responsibility
for ensuring they are maintained to the highest level with a
consistent user experience.  The effect I'd hope would be to emphasise
that while we have a huge range of great apps, many of which may get
released on the same day, there's only a small subset that are
Essential to install.  It should also help with emphasising the
separation between installing a single KDE app and having to use the
entire Workspace and ecosystem.  It may even attract more apps to be
KDE hosted if they see it doesn't carry the old baggage of being part
of the KDE Desktop Experience.

If that seems a slightly anarchic free-for-all, I think that's half
the idea :-)  The dream of a monolithic KDE world domination is over,
we live in a world where everyone mixes and matches desktops and apps,
choosing the best in category or what works best for them, and this
would help free our app developers to better compete and innovate.  To
help keep it all under control we would need to have some quality
metadata system to organise what category, maturity and release cycle
an app falls under, but that's an implementation detail.

One other thing I would do is change our app lifecycle slightly.  I'd
introduce a new status of Deprecated that lies between Released and
Unmaintained, for apps like Kopete and KPPP that are no longer
relevant for most people or are being replaced, but may still have
limited use and so need to be kept alive for a while.  I'd envision a
new lifecycle metadata attribute that looks something like
Experimental -> Incubator -> Stable -> Deprecated -> Unmaintained,
with only Stable apps eligible to be included in the regular
Applications release cycle.

At this point, I need to emphasise that any such reorganisations need
to be with the active agreement of the involved communities and
application maintainers, and that active maintainers have the final
say for their apps.  The same people would still have the same
responsibilities, we would just organise how those people work
together differently.  In the absence of an active maintainer the
wider community needs to take responsibility.

I've gone through all the modules and apps in the SC and made a guess
at their status and what we should do with them.  You can see a long
list of my guesses at [1], along with more details on how I see the
app lifecycle working.  Feel free to correct my inevitable mistakes
through ignorance, and fill in maintainer names.

Here's how I see the state of the various modules and how I think they
could be reorganised.

The following modules have healthy active communities who can pretty
much carry on as they want:
* Edu
* Games
* Workspace / Plasma-addons

The following modules have some well-maintained apps and some
appearance of a semi-active community but could perhaps do with some
* Accessibility
* Base-Apps (split apps and move to Frameworks and Essentials?)
* Bindings (no idea of status)
* Graphics (split some parts off into Frameworks, Workspace, and
Essentials, but not much left then?)

The following modules while having some well maintained apps appear
almost completely dead as communities, or redundant, or needing total
* Admin (I think maintained, but only 3 non-essential apps, so close
module and move to extragear)
* Multimedia (split up into
* Network (split up into
* Utils (split up into
* SDK (mix of real SDK and dev apps, split up, make apps stand-alone,
merge rest with Examples as proper sdk)
* Toys (only 3 small non-essential utils, split up and move to

I'd like to hear from these communities if they think my assessment is
fair or not.  How healthy is your module as a *whole* community?  How
do you think your community could be working better?  Where do you see
your module heading in Generation 5?

OK, so maybe that isn't that radical after all, it's just a natural
extension of what people have been discussing for a few years now and
a natural consequence of moving to Git.  I don't really expect all
this to happen, it's more to get people thinking about the issues and
to get a discussion going.  I'd be happy if we just sees a clean-up of
the modules and apps, a blurring of the Modules/Extragear split, and a
smaller set of higher-quality apps in the main Release.  What do
people think?    I await your comments :-)


P.S. Sorry it's so long, but brevity is not one of my strengths :-)

[1] http://community.kde.org/KDE/Generation5

More information about the kde-community mailing list