Upstream adoption of AppData so far

By popular request, some update on the upstream adoption of AppData so far:

Applications in Fedora with long descriptions: 168 (9%)
Applications in Fedora with screenshots: 140 (7%)
Applications in GNOME with AppData: 60 (50%)
Applications in KDE with AppData: 1 (1%)
Applications in XFCE with AppData: 0 (0%)

You can look at a few ways:

  • We’ve made significant progress in the last year-or-so and many popular applications are already shipping the extra data.
  • There are a lot of situations where the upstream authors do not know what an AppData file is, don’t have time to add one, or simply do not care.
  • GNOME is clearly ahead of KDE and XFCE, probably because of the existing GNOME Goal and my nag emails to the desktop-devel mailing list. A little thing to bear in mind is that Apper (the KDE application installer) can also make use of the AppStream data, so this is a little disappointing for KDE users who probably don’t see any difference at the moment.

So where do we go from here? Clearly KDE and XFCE have some catching up to do, and I need someone familiar with those communities to lead this effort. There is also a huge number of upstreams that need a little push in the right direction, and I’ve been trying to do that for the last couple of months. Without help, this would be a never-ending battle for me. A little reminder: In GNOME 3.12 we are penalising applications that don’t ship AppData by including them lower in the search results, and in GNOME 3.14 we’re not going to be showing them at all.

If you’re interested to see all the applications shown by default in Fedora 20, I’ve put together this page showing a quick overview. If you see anything there that shouldn’t be an application and needs blacklisting, just let me know. If you see an application you care about without a long description or screenshots, then please file a bug upstream pointing them at the AppData specification page. Thanks.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

14 thoughts on “Upstream adoption of AppData so far”

  1. Steam is the most important non-free app. It will be included in RPMfusion for Fedora20. I would loooooove to do a few-click installation of RPMfusion and then a one click install for Steam. This could would win over 100,000 Ubuntu users to Fedora :) I hope you guys figure this out just like you are doing a great job on codecs installation.

  2. That is great news! Are you planning to do some kind of reach out to RPMfusion? They need it, Fedora user (might) need it. Oh and now it is time for complaint. I have never installed so many applications and games before. This “one-click and play” have filled my SSD, now I need a bigger one. I blame you for making software too damn easy to discover, install and enjoy! :)

  4. Used in GNOME only, extracted in GNOME only, translatable in GNOME only with GNOME tools only.

    Ends up similarly to Ubuntu install button project (with fine ~1% coverage), imho.

    I do not know the right solution (can you just use .desktop files?), but adding then translating .appdata.xml files in KDE project repos for GNOME only looks like a waste of time for me (just like GNOME-only package manager which then reads them).

  5. You know it’s only been about two months since you released the appdata spec, right? Hardly a year of progress. 9% in two months is not a bad start.

  6. > GNOME 3.14 we’re not going to be showing them at all.

    And thus a feature that will be mildly useful for one release becomes useless in the next. What’s the point of having an app search menu that capriciously doesn’t show apps based on the last time upstream bumped their software?

    1. We want to show good-quality applications, not abandon-ware. If an application hasn’t done a new release in 2 years, is it responsive to bug reports and feature requests? We can add extra AppData files to the fedora-appstream repo if there is an applications we want to “save”.

  7. FYI, Apper needs AppStream support enabled at compile time, and we currently aren’t enabling that. Looking at the absence of such data for KDE applications so far, it doesn’t seem to be of much use to do so right now. So KDE users definitely won’t see any difference at the moment.

  8. Have the other communities be notified respectively asked to provide the additional data?

    I can’t remember seeing any such posting to either kde-devel or kde-core-devel and my guess is that at least for KDE those would be the lists most developers read.

    Or did this go to the packager lists because it is not something app developers add?

      1. Ah, good.

        Unfortunately communicating so late, basically setting an ultimatum and making up irrelevant statistics is going to result in lots of politics that could have been easily avoided.

        But well, I guess it is one of the better late than never things.

Comments are closed.