Previously the GNOME release team agreed that almost everything should be removable, except Software and Settings (were there any others?). Making applications non-removable is just rude to users.

Sadly, nobody ever implemented this decision.

If this sounds OK, I can provide a list of considerations and talking points to get the process started.

Please do!

We will likely want to adopt the same considerations upstream as well. Javier Jardon has long wanted some sort of policy.

Sadly, nobody ever implemented this decision.

What does "implement" mean here?

Nobody ever worked on making it happen. We still have a bunch of nonremovable apps in GNOME Software to this day.

Nobody ever worked on making it happen. We still have a bunch of nonremovable apps in GNOME Software to this day.

Making them removable is just a matter of changing how they're configured, somehow, or is there more to it than that?

Two options:

• We could modify each application's appstream metadata to remove <mandatory_for_desktop>. We should probably do that regardless.
• We could modify gnome-software to no longer respect <mandatory_for_desktop>, and instead just remember that it shouldn't remove itself or gnome-control-center. Release team has previously requested this. We don't want apps to be able to mark themselves unremovable.

Two options:

We could modify each application's appstream metadata to remove <mandatory_for_desktop>. We should probably do that regardless.
We could modify gnome-software to no longer respect <mandatory_for_desktop>, and instead just remember that it shouldn't remove itself or gnome-control-center. Release team has previously requested this. We don't want apps to be able to mark themselves unremovable.

Ah yes, I remember! In the past I've objected to the fact that Software behaves differently from DNF. I do think that consistency would be a good goal here: it seems odd that you're able to remove an app with DNF but not Software.

Of course this creates other questions, like whether the same apps that are non-removable as packages should also be non-removable with Flatpak or as part of a Silverblue image.

The other question with regards to implementation is to what extent removability is designed, implemented and tested in the components themselves. For example: what happens to the weather integration in gnome-shell, if the Weather app isn't installed. Handling these exception cases is extra work and requires that designers and developers know that they have to anticipate an app not being present.

To be honest I'm a little sceptical that we have the capacity to test these types of integration when the relevant apps are not present. That could of course indicate that we shouldn't have integration like this in the first place, but the status quo is that we do.

I have some guidelines and recommendations that I can share with the WG. However, before we get on to that...

Currently, the non-removable apps are only defined in Software - you can still remove them from the command line. To me this doesn't make much sense - if an app is non-removable, it ought to be non-removable.

So, if we are going to put time and energy into defining which apps should be non-removable, I think that we should first agree on what our expectations are for the behaviour of non-removable apps.

If we can't enforce non-removability, then maybe we shouldn't think too hard about it.

The WG discussed the question here: https://meetbot.fedoraproject.org/teams/workstation/workstation.2020-04-07-09.52.html

I think the consensus was that non-removable apps should be non-removable from anywhere, and that gnome-software should stop respecting <mandatory_for_desktop> in appstream metadata.

I think that the following could be useful talking points for the WG, in order to provide direction on what the default and non-removable app set should be.

There are some basic guidelines that we can use when selecting preinstalled and non-removable apps, including quality, consistency, coherence of the set, and so on. That aside, there are a collection of higher-level reasons to potentially preinstall an app or make it non-removable:

1. To provide a basic set of functionality on a newly installed system (and in so doing, provide a good set of apps for common tasks, rather than requiring users to hunt for them)
2. To ensure that the system is always capable of basic, common functions. For example, so it's always possible to open a web link, a PDF, an image.
3. To ensure that the essential system functions can always be carried out. For example: changing system settings, installing apps
4. To provide a common set of expectations for support and documentation. So a tutorial can tell someone to launch the disks app, or a support person can ask someone to check ABRT
5. To ensure the presence of diagnostic and recovery tools, when problems occur. For example: always having a disk usage analyser, for when someone's disk gets full
6. To reduce bugs and design and engineering overhead, by reducing the number of interchangeable components. For example, requiring the clocks app to be installed, so the shell can always use it for its world times feature.
7. To provide a integrated, high-quality suite of apps for common tasks, well-rounded and integrated experience. This is the more maximalist approach, which we tended to follow in the past, which said you had to have a music app and a photo manager and an email client and so on. It's the "app suite" approach. A lot of this has been eroded by the cloud.

Within all this, it's worth being aware of multiuser and offline situations.

Potential reasons to limit the number of preinstalled and/or non-removable apps:

1. Reduce the size of install media
2. Allow users to free up disk space
3. Provide more space for personalization . An empty app grid can invite the user to populate it; removing apps allows someone to replace them with their own
4. Prevent frustration at not being able to remove apps

Suggestion for implementation (once the rpmlint bug is worked out):

Starting in Fedora 33, RPM now has another dependency directive: Requires(meta):. What it means is "this package requires some other package, but doesn't care installation order so long as it is installed on the system at the end of the transaction". We're planning to use this in the Server Edition to set minimum functionality requirements for the system to present itself as Fedora Server Edition. (e.g. removal of NetworkManager, Cockpit, firewalld, etc. would result in the system reverting to just being "Fedora" instead of "Fedora Server Edition").

It might be worth considering a similar approach for Workstation.

Tagging this for Tuesday;s meeting per request and putting it last on the agenda. Allan, since you're assignee, is this ready for an status report/follow-up? Or punt?

Allan might not be here tomorrow, so let's punt this to next week.

I've got a straw man proposal here, for how we could update the default app set:

https://etherpad.gnome.org/p/fedora-default-apps

It's intended as a vehicle for discussion and applies a small number of principles:

• Preinstalled apps should be decent quality
• The default app set should be logically coherent
• We shouldn't be constrained by the old idea that we need to have default apps for local file stores (key examples: music and photos apps)
• Non-removable apps should only include:
  • Diagnostic and recovery apps
  • Essential system apps
  • The file manager [1]

Depending what we decide in our meeting, I can write up a more detailed version of this.

In the proposal I've made some changes to the default app set, but some questions and issues remain:

• Is Videos sufficient as the default audio player?
• Contacts makes sense in the company of a default Mail app, but it's a bit unclear what its role is without it
• Boxes is an oddity; it would make more sense if there were similar complementary apps in the default set apps that might complement it. There's been some talk of a separate remote desktop app recently, for example.

Additionally, while I don't think the goal should be to have a large number of default apps, if we're reviewing the app set we should probably consider what kind of default apps we'd like to see in the future. My personal list would probably include:

• Notes (with cloud sync and a corresponding mobile app)
• A simple image editor, capable of crop, rotate, annotations
• A screen recorder (or screen recording added to the screenshot tool)
• A camera app, to replace Cheese?
• A Fedora developer guide?

Any other ideas?

[1] I'm also counting the simple viewer/editor apps as essentially being part of the Files app

Essential system apps

How do you define "essential system apps"? Is there a criteria used to decide this? Or are these utilities like Terminal and Logs?

Thanks Allan! I think this proposal looks generally quite nice, particularly with respect to default apps. I would still like to consider significantly reducing the number of non-removable apps relative to what you have proposed, since users find it frustrating to discover an app is nonremovable, and since dnf will allow removing these apps regardless.

I'll point out that all the default app changes look equally suitable for upstream as well, so we can continue to mostly synchronize changes between GNOME core apps and Fedora Workstation default apps, as I've been doing for several years now.

Is Videos sufficient as the default audio player?

It could be suitable if we were to rename it to Media Player and display some generic music icon when playing music (like it used to do), instead of just displaying a totally black screen. Those seem like straightforward tweaks to make, if Bastien is OK with them. (If we want to keep calling it Videos, then I would say no it's not suitable.)

Contacts makes sense in the company of a default Mail app, but it's a bit unclear what its role is without it

We should either add Geary or remove Contacts. It just doesn't make sense to keep Contacts otherwise. I've been long hoping to add Geary, since it's nicer than webmail, since having a preinstalled email client encourages users to try it out, and since a slick and reliable email client can create a positive user experience for Fedora relative to webmail. But Geary still has some severe bugs that seem unlikely to be fixed anytime soon, so quality is really not where it needs to be yet. That suggests we should remove Contacts instead... but that's an awkward thing to do if we hope to install Geary sometime soon.

All that said, I see this question as a detail to figure out, not something that affects the merit of the overall proposal. We could go either way here and still wind up with a good overall result.

P.S. If we remove Contacts, then we should probably also remove mail and contacts integration from gnome-online-accounts. (And the photos integration should also go if we remove photos. I assume we don't want to maintain integration for apps that we don't install by default?)

Boxes is an oddity; it would make more sense if there were similar complementary apps in the default set apps that might complement it. There's been some talk of a separate remote desktop app recently, for example.

Another detail that doesn't affect the overall proposal. I think I'd lean towards keeping it -- I use Boxes a lot, and it's useful to nudge developers toward our supported virtualization platform (as opposed to, say, VirtualBox), and virtualization is a nice feature to have built-in especially for developers -- but VMs and remote desktop connections are admittedly a bit niche compared to music or videos, and it's easy enough to install manually. So again, I think we could go either way on Boxes and still wind up with a good result.

Essential system apps

How do you define "essential system apps"? Is there a criteria used to decide this? Or are these utilities like Terminal and Logs?

That category currently includes Settings, Software and Files. The former two follow the logic of being unique (ie. equivalents don't exist) and allowing basic system functionality.

Files is a bit different - alternatives do exist. In my mind it's a matter of it being integral to the experience and there's an expectation from other apps (and documentation) that it will exist.

Thanks Allan! I think this proposal looks generally quite nice

Thanks Michael. I think we can discuss most of your points in the WG meeting.

Another detail that doesn't affect the overall proposal. I think I'd lean towards keeping it ...

Just to clarify - I wasn't suggesting that we should remove Boxes from the default install. Rather, I was thinking that it would be good if there were additional complementary apps in the default set.

We discussed this at today's WG meeting. It was a bit hard to judge exactly what the consensus was, but I think we can say:

• The group was happy with the proposed default app list, which means:
  • Removing Photos and Music from the default set now - #164
  • Removing Archive Manager once we're satisfied that Files provides the necessary - #167
  • Swapping out Cheese for a more generic Camera app when we can - #166
• There was some agreement that a small set of essential apps should be non-removable through DNF. This includes gnome-control-center, gnome-software, gnome-terminal and yelp (since a lot of apps rely on it). People also seemed to agree that gnome-shell shouldn't be removable. - #165

The story for making other non-removable apps wasn't entirely clear, to me at least. Some people seemed to think that it would be OK to have a bigger set of apps that are non-removable in Software only, but there was also a lot of push back against the idea of non-removable apps in general.

I'm personally strongly against making apps non-removable just in Software. Adding layers of logic only at the graphical layer turns it into a pseudo system in its own right. It's very odd, and it's fragile.

Other than the other issues I've linked to here, I think the only outstanding action item for this ticket is to document our decisions and inclusion logic, for reference in the future. I'll try and do that soon.

My understanding is that this ticket is just waiting for me to write some guidelines based on our previous discussion.

Draft for review:

Pre-installed app selection guidelines

The following provides guidance regarding the selection of apps for inclusion in Fedora Workstation installs.

Basic functional requirements for the default app set

The default app set should provide a basic set of functionality that users require from a desktop. This includes:

• Functionality that is essential to managing and operating the system. This includes the ability to install and remove apps, install system updates and change system settings.
• Basic system features, including the ability to browse the file system, view disk configuration, and execute terminal commands.
• Basic user features, such as viewing a PDF, playing an audio or video file, browsing the web.
• Basic system utilities, for when the user needs help or when something goes wrong. This includes user docs and diagnostic and recovery tools (for example a disk usage analyser and system monitor).

Beyond these basic requirements, the default app set can be selected based on the kind of apps that users tend to expect from a desktop. In general, niche apps should be avoided, and the emphasis placed on generic, commonly recognised app types.

Design requirements for each app

Apps that are pre-installed should generally have the following:

• Quality should be good: the UI should look good, the app should work well, it should have a good quality app icon, should work with accessibility features, be translated, and so on.
• Consistency: the app's UI should be consistent with the others in the default app set.
• Integration: where appropriate, the app should be integrated with the system and with other default apps. Apps should use standard system services and should respect system settings.
• Generic identity: by and large, apps should have generic, unbranded names and icons. For example, Music, Videos, Calendar, as opposed to Rhythmbox, VLC, Thunderbird.

Additional goals for the default app set

When making decisions about the composition of the pre-installed app set, the following considerations should be kept in mind:

• The default app grid should look good:
  • All rows on the first page should be populated.
  • Avoid uneven grid layouts: pages should have a good number of apps on them, rows shouldn't have more than a couple of apps.
  • Avoid having too many apps (likely not a problem).
• Be consistent in how classes of apps are treated - for example, if there's a music app, logically there should probably be a videos app too. Or if there's an image viewer, a user might expect there to be a document viewer.
• In some cases, it is necessary to consider collections of apps as a single entity. This particularly applies to apps that have functional interdependencies: for example, calendaring, contacts and email often go together.

Legal and practical requirements

• Obviously should be open source.
• Should have active development community, with which Fedora has a good relationship.

Looks good to me Allan! The general question that I have is will there be a general place (wiki, ..) when we will list all the currently preinstalled applications and the reasons why they're preinstalled? And also list some common asks (Rhythmbox, ..) and list there the reasons why they are not preinstalled?

Generic identity: by and large, apps should have generic, unbranded names and icons. For example, Music, Videos, Calendar, as opposed to Rhythmbox, VLC, Thunderbird.

Should we explicitly list the exceptions for this rule? The most obvious one is Firefox - it's preinstalled, but the Web is taken by GNOME Web aka Epiphany (that is not preinstalled).

Looks good to me Allan! The general question that I have is will there be a general place (wiki, ..) when we will list all the currently preinstalled applications and the reasons why they're preinstalled? And also list some common asks (Rhythmbox, ..) and list there the reasons why they are not preinstalled?

I could certainly put that together, if it would be useful. Will it be useful?! My main hesitation is keeping that documentation up to date...

Generic identity: by and large, apps should have generic, unbranded names and icons. For example, Music, Videos, Calendar, as opposed to Rhythmbox, VLC, Thunderbird.

Should we explicitly list the exceptions for this rule? The most obvious one is Firefox - it's preinstalled, but the Web is taken by GNOME Web aka Epiphany (that is not preinstalled).

Good idea - I can add something about Firefox and LibreOffice, to clear up any confusion.

ACTION: Allan to weaken the requirement that software should use generic names, to make it a suggestion rather than a requirement. Allan to find an appropriate permanent location for this policy to live.

I've created a wiki page and adjusted the content based on feedback from the working group: https://fedoraproject.org/wiki/Workstation/Default_App_Guidelines

Can we call this closed, or are there other steps that need to be taken?

Yes, thanks!