#203 GNOME Software is recommending proprietary software
Opened 2 years ago by aday. Modified a day ago

This is a continuation of #111, with a fresh ticket and fresh minds.

Problem description

The graphical banners that are shown at the top of the Software home screen are shipped as part of gnome-software itself, and currently include two proprietary apps (Dropbox and Slack). These banners are only shown when the corresponding apps are available, so Dropbox or Slack will only show up if the user enables a repo that contains them.

The appearance of these banners for proprietary apps has prompted objections.

Part of the issue is that it looks like the banners come from Fedora, and it isn't obvious that the appearance of the banners is a response to certain repos being enabled.

Potential solutions

Solutions that I can think of (there could be more).

1. Source labels

I previously proposed that we add a source label below each banner. However, when we discussed this at today's WG meeting, this prompted some concerns that it doesn't communicate who is responsible for the banner in the first place.

You could potentially replace the source label with a "recommended by" label. However, in this case I would say that we need to be honest - responsibility for the banner lies with us in the Fedora project, not GNOME.

2. Have repos provide banners

There has been some discussion about having repos provide the banners and associated metadata, rather than shipping them as part of the gnome-software package. If this were to happen, it could help to communicate where each banner is coming from (maybe you could have separate sections for each of the main repos - Fedora, Flathub, etc).

However, it should be noted that this doesn't make the debate about whether to feature free/proprietary apps go away. Nor is it clear how this arrangement would work with regards to the 3rd party repos.

3. Configuration option

It could be possible to add a user visible control to enable/disable promotion of proprietary software. This could perhaps be included in Initial Setup, alongside the option for 3rd party repos.

If we were to do this, we'd need more proprietary banners, in order to make the control worthwhile.

4. Move proprietary apps to editor's picks

In addition to the big graphical banners, Software also has some sections of app tiles on the home screen, that are manually selected downstream (source). One option might be to move the proprietary apps down to this less prominent position, which would allow them to still be noticed but not be so in your face.

The challenge with this option is that a) we haven't been actively updating the sets of apps in these sections and b) as a result, I've proposed upstream to remove these app tile sections. This could of course be reversed but it would require thought and energy.

There's potentially an issue here: if we populate the section with apps that are available without 3rd party repos, those 3rd party apps could get lost when the repos are enabled. Ideally we'd have a way to make the selections or the sections update to reflect which repos are enabled.

5. Remove all trace of the proprietary apps

This would be easy to do upstream and I don't think we'd encounter much resistance there. Personally speaking, I think there are two issues though.

First, the Workstation Working Group has worked - and continues to work - to make certain limited proprietary apps available. This currently includes Chrome, Steam and PyCharm. We are planning to expand this list of proprietary apps in the future. It would be odd to do this and then bury the results of our work. Ideally I would like us to be promoting the 3rd party apps that we've put effort into making available.

Second, my perspective is that there is value for users and for the platform in advertising that best in-class apps are available to install on Fedora, whether that's Spotify, Visual Studio Code, Steam, Chrome, and so on.

We can't assume that users know that these are available and, if it's something they would like to use, then showing that they're available improves their experience and makes Fedora better for them, and that makes the platform stronger.


Metadata Update from @catanzaro:
- Issue tagged with: meeting

2 years ago

Is there a way to promote the availability of these proprietary applications in Fedora, in a way that doesn't look like a recommendation or preference of the apps themselves?

Is there a way to promote the availability of these proprietary applications in Fedora, in a way that doesn't look like a recommendation or preference of the apps themselves?

The closest to that is probably option 4. That section on the home screen is currently headed "editor's picks" but we could change that to something less recommend-y ("Discover", "Available for Fedora", etc).

We could also think about policies we want in place. Maybe we could have a rule that we always include an equivalent free/libre app (if one's available), so it doesn't look like we're recommending proprietary apps over free/libre ones.

It would be odd to do this and then bury the results of our work. Ideally I would like us to be promoting the 3rd party apps that we've put effort into making available.

But what about all the non-third-party apps that Fedora has also worked on making available? Promoting some applications necessarily means not promoting others. There are many apps worth promoting that also happen to be less controversial to promote; there are enough of them to fill all the slots and banners in the Explore section in Software.

And, whether any app is best in class is super subjective, because none of them does well on all objective metrics. For example, Chrome is fast (according to browserbench.org) and supports web standards well (according to wpt.fyi), but it also has poor system integration and no native support for Wayland. So is it best in class (on Workstation, which is what matters)?

Popularity is one indicator of quality and usefulness, and even contributes to them in some ways (e.g., it might mean more extensions available, more incentives for website compatibility, more people you can talk with), but it hardly accounts for everything and search costs ensure it usually lags some years behind and favors apps available on many platforms. Surely one of the main purposes the recommendations in Software can serve for users is to overcome the costs of searching for better apps than the ones they already know? Such could be done more effectively by promoting good apps like Foliate and Apostrophe that are not very well known than by promoting Dropbox, which everybody already knows about.

There are many apps worth promoting that also happen to be less controversial to promote; there are enough of them to fill all the slots and banners in the Explore section in Software.

I don't think that's correct.

We are a long way from having to choose some apps over others. The explore page is supposed to be dynamic and be constantly updating, in order to make it engaging and enable discovery. That page in turn is supposed to be a jumping off point for other sections of dynamic content. That provides plenty of capacity to present large collections of content (as other platforms do, which have vastly more apps than we do).

Our major problem at the moment is that we don't have enough high quality apps to fill the space we have available.

It's also worth bearing in mind that what's being proposed here is quite limited - the addition of a restricted number of key apps, which will be significantly outnumbered by existing content.

Action: Allan to propose a mockup for a design that reduces the emphasis on proprietary applications.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

2 years ago

Action: Allan to propose a mockup for a design that reduces the emphasis on proprietary applications.

Adding pending-action for this.

Metadata Update from @aday:
- Issue tagged with: pending-action

2 years ago

I've attached the promised mockup, which gives an idea of what an "Available for Fedora" section could look like. This is a modified version of the latest mockups for Software, which are somewhat different from the current version. There is an ongoing effort to implement them.

It seems that the new UI has a section for the most popular apps. I'm not sure how feasible that is to implement, but if it does happen, it might be that we don't need the extra "available for Fedora" section. (Presumably many of the apps that would go into the "available" section would naturally bubble to the top of the most popular category.)

explore-page-fedora.png

Metadata Update from @aday:
- Issue untagged with: pending-action

2 years ago

The working group discussed the above mockup yesterday. In general it seemed that people were positive. There were some questions and suggestions about the section title and showing the source of each app; I think we can return to those at a later date.

We might want to see if the most popular section makes its way into Software before proceeding with this design proposal. Relevant upstream tickets for that are #1111 and #427.

If we do decide to go ahead, there are a couple of pieces that we might need to get in place first. The first is the filtered Flathub view (#108). The second thing might be to retire the existing downstream maintained "editors picks" selection, since this would in effect replace it. The upstream issue for that is #747.

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

2 years ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting-request
- Issue tagged with: pending-action

2 years ago

I see the pending-action tag here. What is that action and to whom is it assigned?

Action is for GNOME Software developers to implement your mockups.

Note you need to fix the application licenses first. The Software changed the way it detects the license, it relies on as_license_is_free_license. Many core applications are recognized as proprietary, because they have set in the appdata licenses for the code and for the documentation, or they have otherwise broken license field, which makes the license unrecognized as free by the as_license_is_free_license function. One example is GNOME Mahjongg, which is currently shown as Proprietary license. See (currently closed) https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1200 .

For the design itself, the https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1021 doesn't seem to be updated.

For the design itself, the https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1021 doesn't seem to be updated.

The mockup for this issue is here.

Allan marked the upstream bug as "Needs Design" 3 months ago, from which I guess the above mockup is obsolete. In any case, what is here doesn't matter, the work is done upstream.

There's been a lot of UI churn in GNOME Software this cycle and GNOME UI freeze is now in effect (see below for a screenshot of the current explore page). If we have enough apps available through the 3rd party repos, we could aim to add the "Available for Fedora" section in GNOME 42 / Fedora 36.

software-explore-f35.png

I couldn't see an upstream ticket for the latest design proposal (the "Available for Fedora" section), so have created one: #1409

The action that's pending here is to implement that proposal for GNOME 42 / Fedora 36.

Metadata Update from @aday:
- Issue untagged with: pending-action
- Issue assigned to aday
- Issue set to the milestone: Fedora 36

a year ago

So to be clear: under the new design, proprietary software could appear under the Available for Fedora section, but no longer in the large banner at the top of the window? That sounds good to me.

So to be clear: under the new design, proprietary software could appear under the Available for Fedora section, but no longer in the large banner at the top of the window? That sounds good to me.

That's the plan.

Something that needs to be decided on the WG side is which apps to include there: should it just be apps from the 3rd party repos, or are there other apps we'd like to include?

We also need to decide on how to maintain the "available for Fedora" app list. My hope was to have an XML definition that could live in a repo that's owned by the WG... do you think that would be possible, @mcrha ?

My hope was to have an XML definition that could live in a repo that's owned by the WG... do you think that would be possible

Yes, of course. The changes https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/967 for https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1409 expect the same format as https://gitlab.gnome.org/GNOME/gnome-software/-/blob/main/data/assets/org.gnome.Software.Featured.xml , except instead of the GnomeSoftware::FeatureTile is expected key GnomeSoftware::DistroFeatured. More details can be found here: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1409#note_1265711

The change is not accepted by the upstream yet, and it's slightly more complicated due to the translations of the "Available for Fedora" string, which should be provided by the distro as well, from my point of view.

The change is not accepted by the upstream yet, and it's slightly more complicated due to the translations of the "Available for Fedora" string, which should be provided by the distro as well, from my point of view.

Can't it use the distro name from the usual place (os-release?) rather than having it in the gnome-software string?

Can't it use the distro name from the usual place (os-release?) rather than having it in the gnome-software string?

It can use the os-release, but then it'll generate sometimes weird string, like Available for Fedora Linux, Available for Debian GNU/Linux, and who knows what's in other distros.

The string Available for Fedora is not in the gnome-software sources, it's supposed to be provided by the distribution, with translated variants, in a separate file (as the current merge request is done).

This will be better discussed upstream.

The string Available for Fedora is not in the gnome-software sources, it's supposed to be provided by the distribution, with translated variants, in a separate file (as the current merge request is done).

It's not going to happen. Won't be translated at all if you expect the translation to be added in downstream. Not on Fedora, and probably not on 95% of other distributions.

If we really can't include this string upstream, then please change it somehow to not include the OS name. "Available for your system" or something.

"Available for your system" or something.

@aday That's up to you. I can do the change, just tell me what it's supposed to be. It will be simpler code, thus the upstream will benefit as well.

"Available for your system" or something.

@aday That's up to you. I can do the change, just tell me what it's supposed to be. It will be simpler code, thus the upstream will benefit as well.

That it's probably best to discuss the heading in the upstream ticket...

The upstream changes landed few days ago. If someone provides me with the needed files (see the Deployment Featured Apps section there), I can add them to the gnome-software package. Or it can be distributed in a different package (which would be better (maybe in fedora-release-workstation), only an update of those files requires gnome-software restart).

Thanks Milan! I think Allan will tackle this when he returns. Adding pending-action tag.

Metadata Update from @catanzaro:
- Issue tagged with: pending-action

6 months ago

Metadata Update from @aday:
- Issue set to the milestone: Fedora 37 (was: Fedora 36)

6 months ago

I'll work on a list of apps that we'd like to show in this section. In the meantime, could you provide a few screenshots, @mcrha ?

Screenshot of what specifically, please? It's only a new section, at the bottom of the Explore page, the same as "Editor's Choice" and "New & Updated", just below the last app set ("New & Updated" in this case), titled as the .ini file says.

I've tested the new "deployment featured" feature now. It looks like this:

Screenshot_from_2022-06-21_01-32-04.png

It is a simple section containing 12 app tiles. If fewer than 12 apps are specified, the section isn't shown. If more than 12 are specified, @mcrha tells me that a random selection will be chosen each day.

This looks good to me, and I think that it will be good to use this feature in Workstation, in order to advertise the following types of apps:

  • the most well-known and popular apps that are available for Fedora (both because it's likely that someone will want to install them, and because it speaks to the overall attractiveness of the platform)
  • the 3rd party apps that we've put the work into making available
  • apps which speak to our focus on developers and creators

The third party repos currently contain 9 apps and I'm sure we can find 3 more apps to make up the numbers (so far I used RStudio, Ardour and Blender).

There is a question here about what we do if and when we open up more of Flathub (#300). In that case, we could have many more apps to choose from. But maybe we just cross that bridge when we get to it.

It would be good to get approval from the working group before we enable this - adding the meeting tag.

Metadata Update from @aday:
- Issue untagged with: pending-action
- Issue tagged with: meeting

6 months ago

The working group discussed this on Tuesday, and is happy for this feature to be enabled in F37.

I've updated my own configuration to include the following apps:

  • From the 3rd party repos:
    • Bitwarden
    • Discord
    • Google Chrome
    • Microsoft Teams
    • Minecraft
    • Postman
    • PyCharm Community Edition
    • Skype
    • Steam
  • From the Fedora repos:
    • Ardour
    • Audacity
    • Blender
    • Qt Creator
    • RStudio

These were selected using the following criteria:

  • Include all the third party apps
  • Other apps should:
    • have a good level of brand awareness
    • generally fit with Workstation's focus on developers and creators
    • not overlap with existing featured apps

I expanded the list from the minimum of 12 to 14, just in order to make it a bit more robust. (With a list of only 12, if one can't be found, then the whole section disappears.)

Here is the configuration file: org.gnome.Software.DeploymentFeatured.xml

Metadata Update from @aday:
- Issue untagged with: meeting

6 months ago

Here is the configuration file

You need also the deployment-featured.ini file with the translations of the section name.

Which package will these files be distributed by, please? Maybe fedora-workstation?

You need also the deployment-featured.ini file with the translations of the section name.

If we could get the section name upstream, that would be ideal. E.g. to keep it distro-agnostic you could do something like: g_strdup_printf (_("Available for %s"), g_get_os_info (G_OS_INFO_KEY_NAME))

If it's just a downstream config file then it will not be translated, which would be a shame.

If we could get the section name upstream, that would be ideal. E.g. to keep it distro-agnostic you could do something like: g_strdup_printf (_("Available for %s"), g_get_os_info (G_OS_INFO_KEY_NAME))

It had been decided upstream to do it the way it is done. It has its advantages.

Honestly Allan, I would give up at this point. We should not add this feature if there won't be upstream translations for it.

Presumably, the question of whether the string goes upstream or downstream is down to whether this string would be wanted for other distros and deployments? We could ask around and see what Datto or Red Hat might want to use for their internal deployments.

If the "Available for Fedora" string lives as part of a Fedora package, what are the prospects of getting it translated?

Sounds like you would have to manually contact translators and have them give you translations to paste into the config file. Sounds like a lot of effort for one string: certainly not worth it. Realistically, all translated strings need to be upstream or they'll be English-only, just like our GNOME Terminal patches from nearly a decade ago are still English-only.

I've already provided my suggestion for upstreaming the string in a distro-agnostic way.

So for Fedora we wanted a very neutral heading which was clearly not an endorsement, hence why we went with "Available for Fedora", but a different organisation might want something stronger, like "Recommended for FooCorp Associates" or "Essential FooCorp Apps".

Solution: just add all variants that you want to support to the upstream codebase.

Solution: just add all variants that you want to support to the upstream codebase.

No. I do not see a reason why should upstream care of anything specific to a single distro. Not about me, upstream itself doesn't see that reason either.

OK, I suggest closing this issue then. Adding the new UI is less important than avoiding untranslated strings.

Or alternatively: redesign so that allowing downstreams to choose different headings is no longer a goal.

I agree that Fedora shouldn't be pushing its own strings into the GNOME project, in order to get its translators to do our work for us.

That said, while the existing "Available for Fedora" heading was designed to meet Fedora's needs, it could potentially be relevant to other distros. Likewise, if this feature is explicitly intended to be used by smaller scale deployments, then it might make sense for GNOME to support a number of different strings that they can use out of the box.

One thing I don't understand though - why are we assuming that Fedora couldn't translate this string? I see other Fedora components being translated...

I see other Fedora components being translated...

Like what? Are you sure they are translating downstream patches, and not entire projects where Fedora controls the entire translation? You'd then need to merge the translation into this configuration file that would be maintained in our dist-git. I'm sure it's not impossible, but doesn't seem worth the effort.

I spoke to @mcrha about the this issue last week.

Regarding the translation, it seems that there's a preference amongst the upstream maintainers to not have the string upstream. We could try and revisit that, but the timing isn't great: people are away on vacation, the GNOME 43 beta is out the door, and F37 is coming together.

@mcrha 's suggestion is to create a new project to store the configuration for the deployment featured configuration, and to hook this up to Fedora's translations infrastructure. it is a simple, single string that needs translating, so we can probably fill in the translations ourselves if needs be.

That seems like a workable approach to me.

The second issue is which package to use to distribute the configuration. @mcrha 's suggestion is to use the appstream-data package. Alternatives might be to use gnome-software itself, or fedora-release.

Opinions?

The second issue is which package to use to distribute the configuration. @mcrha 's suggestion is to use the appstream-data package. Alternatives might be to use gnome-software itself, or fedora-release.

The idea behind the appstream-data package is that it already contains tweaks for the gnome-software, thus it would make sense to put it there, to have the tweaks on a single place.

We also spoke about the fedora-release package, which I suggested, but Allan had a good catch about having a problem to provide this for the other spins and/or the Silverblue, thus instead of it a common package for all the spins/variants would be better, which the appstream-data package is.

@mcrha I think we should probably just go ahead with the plan you described, assuming there's still time to implement it for F37...

I think we should probably just go ahead with the plan you described, assuming there's still time to implement it for F37...

If I'm not mistaken, there's nothing left on the gnome-software side, just provide the files in the correct place and that's it. Correct me if I'm wrong, please.

If I'm not mistaken, there's nothing left on the gnome-software side, just provide the files in the correct place and that's it. Correct me if I'm wrong, please.

I can set up a project containing the configuration files, and I can maintain it. However, I'm a bit lost when it comes to setting up the translations.

However, I'm a bit lost when it comes to setting up the translations.

In what sense? If how to write it into the deployment-featured.ini file, then it's quite similar to what you can see in many /usr/share/applications/*.desktop files. Say you have:

Title=Featured by Fedora Linux

as the default text, which will be used when the respective locale is not found (aka keep it in the file). Then you add lines with the translations:

Title=Featured by Fedora Linux
Title[bs]=Predstavlja Fedora Linux
Title[ca]=Presentat per Fedora Linux

and so on.

The tricky part, at least for me, is to map the code with an actual locale name. Files like /usr/share/iso-codes/json/iso_639-2.json can help (there are more files in that directory).

I'll just add we could solve this problem in about five minutes by committing the "Featured by %s" string upstream. Then we wouldn't have needed to spend months discussing it.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

5 days ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue tagged with: pending-action

a day ago

Login to comment on this ticket.

Metadata
Attachments 3