KDE is All About the Apps
Open, Needs TriagePublic

Description

Goal proposal: KDE is All About the Apps

KDE has over 200 applications and countless addons, plugins and Plasmoids. We offer useful services to them as projects such as Git hosting, teams of translators, teams of artists and designers, some release management if they are part of KDE Applications. But much of the support we offer has fallen short, until recently there wasn't even an up to date website listing them all. There is no method of taking decisions on how these support services are provided and proposed changes often stall such as when the kde.org/applications did for a year.

With new packaging formats we will now be able to release apps directly to users on Linux, our main target platform. This means we need to review our processes and up our game many areas because no more will we be able to rely on 3rd parties to finish off our software and make it useful and attractive to users, we need to do that ourselves.

Some ideas for "what it will take"

  • Improve kde.org to better display all the KDE apps
  • Improve kde.org/applications to display non-Application projects such as KDE Connect or KIO GDrive, these projects are just as valid as standalone apps but they receive even fewer services from KDE
  • Improve kde.org/applications for more meta data such as maintainer names, matrix rooms, release versions and dates, windows and mac store URLs
  • Improve the Appstream metadata to get more download from various Linux stores (Discover, Flathub, Appimagehub, Snap store, ...)
  • README.md files are used by Gitlab and Github to describe a project but they often don't exist, script creating these from Appstream files where they don't exist
  • Make use of our project Mission and Visions in our promo material such as websites. The Plasma Vision was written but is currently not used anywhere.
  • Improve Flatpak, Snap and AppImage packaging to support all the KDE apps
  • Archived or improve some app websites (ex: yakuake.kde.org, utils.kde.org)
  • Renaming KDE Applications to something else. The name is confusing. But there is no way to build consensus around a new name.
  • Unify the version numbers of KDE Applications apps where the maintainers do not want to use their own version and increment them at releases
  • Add version numbers to appstream files as part of KDE Apps release and display that on kde.org/applications
  • Have a procedure for making bugfix and security updates which is clear to users and results in them getting the updates through their preferred packaging method
  • Document best practice and encourage app projects to use proprietary platform stores such as Steam and Windows Store
  • Create a process for app projects to take in money which is administered in the interests of that project and KDE
  • Make the forums half decent by changing to Discourse and link to them from kde.org/applications
  • Update the Manifesto to include modern advantages of being in KDE such as CI, binary factory, neon builds etc
  • Make moving to unmaintained easy. Just now the barrier is too high because it loses translations so translators do not want stuff moved to unmaintianed unless they really are never coming back. Fix that to make it easier.
  • Update repo-metadata categories so they use current terms and categorisations. These are not publically visible but they can be confusing to devs how they don't match reality.
  • Update translations so they easier follow repo-metadata changes. Currently this is a massive manual task for no good reason, make it automated or unnecessary.
  • Ensure Incubation process is welcoming in its docs and info on how to approach KDE and become part of KDE, ensure it does not get blocked during its process

Project Org

How we know we succeeded

  • More users of application made by the KDE community that aren't Plasma users (e.g. GNOME, i3, Windows and MacOS users)
  • People stop saying that they don't use Krita/Dolphin/... because they don't use Plasma
  • App projects will want to join KDE rather than use their own infrastructure or Github

Relevant links

https://www.reddit.com/r/linux/comments/bx1utu/updated_kde_applications_site_now_contains/

I am willing to put work into this

I am interested

jriddell created this task.Wed, Jun 19, 8:36 AM
ognarb updated the task description. (Show Details)Wed, Jun 19, 8:40 AM

Update repo-metadata categories so they use current terms and categorisations. These are not publically visible but they can be confusing to devs how they don't match reality.

The repo-metadata categories are visible to users in docs.kde.org :(

ngraham updated the task description. (Show Details)Wed, Jun 19, 9:10 AM
ngraham added a subscriber: ngraham.
jriddell updated the task description. (Show Details)Wed, Jun 19, 12:05 PM
scarlettclark added a subscriber: scarlettclark.
jrioux added a subscriber: jrioux.Fri, Jun 21, 2:12 AM

Personally, I prefer using KDE apps as packages of my system. They are up-to-date that way. I tend to forget to upgrade flatpak and snaps. Flatpak and snaps should be more of a sandbox and I use it for unsecured/closed source applications. I see no reason to leave distribution's repo for other store.

Improve kde.org to better display all the KDE apps
Improve kde.org/applications to display non-Application projects such as KDE Connect or KIO GDrive, these projects are just as valid as standalone apps but they receive even fewer services from KDE
Improve kde.org/applications for more meta data such as maintainer names, matrix rooms, release versions and dates, windows and mac store URLs
Unify the version numbers of KDE Applications apps where the maintainers do not want to use their own version and increment them at releases
Make moving to unmaintained easy. Just now the barrier is too high because it loses translations so translators do not want stuff moved to unmaintianed unless they really are never coming back. Fix that to make it easier.
Update translations so they easier follow repo-metadata changes. Currently this is a massive manual task for no good reason, make it automated or unnecessary.

I do like and am in favor of those !

Create a process for app projects to take in money which is administered in the interests of that project and KDE

Yes, donations to devs and creating bounty pools (for new features).

crozbo added a subscriber: crozbo.Fri, Jun 21, 4:14 AM

If 'KDE is All About the Apps', do better incubation of third party applications is part of this goal? Making KDE more attractive and easier to third party applications developers, and how to KDE be more progressive to identify and approach good project to be part of KDE.

jriddell updated the task description. (Show Details)Fri, Jun 21, 12:43 PM

If 'KDE is All About the Apps', do better incubation of third party applications is part of this goal? Making KDE more attractive and easier to third party applications developers, and how to KDE be more progressive to identify and approach good project to be part of KDE.

Yes good idea, updating the manifesto would be part of that and I've added in:

  • Ensure Incubation process is welcoming in its docs and info on how to approach KDE and become part of KDE, ensure it does not get blocked during its process

Personally, I prefer using KDE apps as packages of my system. They are up-to-date that way. I tend to forget to upgrade flatpak and snaps. Flatpak and snaps should be more of a sandbox and I use it for unsecured/closed source applications. I see no reason to leave distribution's repo for other store.

The advantage is for the developers of an App, they can make one package that works for everyone instead of relying on 3rd party projects to make it installable.

ervin added a subscriber: ervin.Sun, Jun 23, 12:29 PM

If 'KDE is All About the Apps', do better incubation of third party applications is part of this goal? Making KDE more attractive and easier to third party applications developers, and how to KDE be more progressive to identify and approach good project to be part of KDE.

Yes good idea, updating the manifesto would be part of that and I've added in:

  • Ensure Incubation process is welcoming in its docs and info on how to approach KDE and become part of KDE, ensure it does not get blocked during its process

Not sure it requires updating the manifesto TBH. For sure it requires finishing the organization of the incubator, it kind of opened half-done. It's baffles me that it's been working so well so far. :-)

martinsotirov added a subscriber: martinsotirov.EditedMon, Jun 24, 1:27 PM

Regarding two of the success benchmarks:

  • More users of application made by the KDE community that aren't Plasma users (e.g. GNOME, i3, Windows and MacOS users)
  • People stop saying that they don't use Krita/Dolphin/... because they don't use Plasma

... isn't the easiest solution that these just stop being KDE apps? Like VLC is a Qt app but no one objects to using it on Gnome or macOS.

To me an OS (don't like the word DE) should be about the OS, not about user land apps. I want a stable window manager, not a KDE branded browser or media player.

This seems directly relevant to T9776, can you take a look @jriddell? Perhaps we can merge these two objectives or some overlapping aspects of them regarding Applications?

I was already considering proposing a sprint particularly for redesigning the Get Involved page as part of the Streamlined Onboarding goal.

Regarding two of the success benchmarks:

  • More users of application made by the KDE community that aren't Plasma users (e.g. GNOME, i3, Windows and MacOS users)
  • People stop saying that they don't use Krita/Dolphin/... because they don't use Plasma

... isn't the easiest solution that these just stop being KDE apps? Like VLC is a Qt app but no one objects to using it on Gnome or macOS.
To me an OS (don't like the word DE) should be about the OS, not about user land apps. I want a stable window manager, not a KDE branded browser or media player.

This is a sign of failure. This goal would be a success if people saw KDE as a community for all end-user projects regardless of which desktop they happen to like using.

This seems directly relevant to T9776, can you take a look @jriddell? Perhaps we can merge these two objectives or some overlapping aspects of them regarding Applications?

This goal is more about the output of KDE rather than how people get into KDE.

feverfew added a subscriber: feverfew.EditedThu, Jul 18, 2:20 PM

Also would like to see a push for advertising KDE Apps on Windows and Mac OS, where possible. This will bring us a wider audience, and can even help switch people to Linux.

Ideally, autogenerating binaries for inclusion into the Windows Store