From kde-community Wed Jan 15 20:47:17 2014 From: John Layt Date: Wed, 15 Jan 2014 20:47:17 +0000 To: kde-community Subject: [kde-community] Applications in KDE Generation 5 Message-Id: X-MARC-Message: https://marc.info/?l=kde-community&m=138981885928968 Hi, 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 Unmaintained. * 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 maintainers. * 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 * PIM * 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 re-organising: * 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 reorganising: * Admin (I think maintained, but only 3 non-essential apps, so close module and move to extragear) * Multimedia (split up into Frameworks/Workspace/Essentials/Extragear/Deprecated/Unmaintained) * Network (split up into Frameworks/Workspace/Essentials/Extragear/Deprecated/Unmaintained) * Utils (split up into Frameworks/Workspace/Essentials/Extragear/Deprecated/Unmaintained) * 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 Extragear/Unmaintained) 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 :-) John. P.S. Sorry it's so long, but brevity is not one of my strengths :-) [1] http://community.kde.org/KDE/Generation5 _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community