Nowadays, I mostly volunteer to improve accessibility throughout GNOME apps, either by enhancing the user experience for people with disabilities, or enabling them to use them. I helped make most of GNOME Calendar accessible with a keyboard and screen reader, with additional ongoing effort involving merge requests !564 and !598 to make the month view accessible, all of which is an effort no company has ever contributed to, or would ever contribute to financially. These merge requests require literal thousands of hours for research, development, and testing, enough to sustain me for several years if I were employed.

I would really appreciate any kinds of donations, especially ones that happen periodically to increase my monthly income. These donations will allow me to sustain myself while allowing me to work on accessibility throughout GNOME, essentially ‘crowdfunding’ development without doing it on the behalf of the GNOME Foundation or another organization.

Introduction

There is no calendaring app that I love more than GNOME Calendar. The design is slick, it works extremely well, it is touchpad friendly, and best of all, the community around it is just full of wonderful developers, designers, and contributors worth collaborating with, especially with the recent community growth and engagement over the past few years. Georges Stavracas and Jeff Fortin Tam are some of the best maintainers I have ever worked with. I cannot express how thankful I am of Jeff’s underappreciated superhuman capabilities to voluntarily coordinate huge initiatives and issue trackers.

One of Jeff’s many initiatives is gnome-calendar#1036: the accessibility initiative, which is a big and detailed list of issues related to accessibility. In my opinion, GNOME Calendar’s biggest problem was the lack of accessibility support, which made the app completely unusable for people exclusively using a keyboard, or people relying on assistive technologies.

This article will explain in details about the fundamental issues that held back accessibility in GNOME Calendar since the very beginning of its existence (12 years at a minimum), the progress we have made with accessibility as well as our thought process in achieving it, and the now and future of accessibility in GNOME Calendar.

Calendaring Complications

Note

On a desktop or tablet form factor, GNOME Calendar has a month view and a week view, both of which are a grid comprising of cells representing a time frame.

In the month view, each row is a week, and each cell is a day.

In the week view, the time frame within cells varies on the zooming level.

There are mainly two reasons that made GNOME Calendar inaccessible: firstly, GTK’s accessibility tree does not cover the logically and structurally complicated workflow and design that is a typical calendaring app; and secondly, the significant negative implications of accessibility due to reducing as much overhead as possible.

Accessibility Trees Are Insufficient for Calendaring Apps

GTK’s accessibility tree, or rather any accessibility tree, is rendered insufficient for calendaring apps, mainly because events are extremely versatile. Tailoring the entire interface and experience around that versatility pushes us to explore alternate and custom structures.

Events are highly flexible, because they are time-based. An event can last a couple of minutes, but it can as well last for hours, days, weeks, or even months. It can start in the middle of a day and end on the upcoming day; it can start by the end of a week and end at the beginning of the upcoming week. Essentially, events are limitless, just like time itself.

Since events can last more than a day, cell widgets cannot hold a meaningful link with event widgets, because otherwise event widgets would not be capable of spanning across cells. As such, event widgets are overlaid on top of cell widgets and positioned based on the coordinates, width, and height of each widget.

As a consequence, the visual representation of GNOME Calendar is fundamentally incompatible with accessibility trees. GNOME Calendar’s month and week views are visually 2.5 dimensional: A grid layout by itself is structurally two-dimensional, but overlaying event widgets that is capable of spanning across cells adds an additional layer. Conversely, accessibility trees are fundamentally two-dimensional, so GNOME Calendar’s visual representation cannot be sufficiently adapted into a two-dimensional logical tree.

In summary, accessibility trees are insufficient for calendaring apps, because the versatility and high requirements of events prevents us from linking cell widgets with event widgets, so event widgets are instead overlaid on top, consequently making the visual representation 2.5 dimensional; however, the additional layer makes it fundamentally impossible to adapt to a two-dimensional accessibility tree.

Negative Implications of Accessibility due to Maximizing Performance

Unlike the majority of apps, GNOME Calendar’s layout and widgetry consist of custom widgets and complex calculations according to several factors, such as:

• the size of the window;
• the height and width of each cell widget to figure out if one or more event widgets can perceptibly fit inside a cell;
• the position of each event widget to figure out where to position the event widget, and where to reposition all the event widgets around it if necessary;
• what went wrong in my life to work on a calendaring app written in C.

Due to these complex calculations, along with the fact that it is also possible to have tens, hundreds, or even thousands of events, nearly every calendar app relies on maximizing performance as much as possible, while being at the mercy of the framework or toolkit. Furthermore, GNOME Calendar supports smooth scrolling and kinetic scrolling, so each event and cell widget’s position needs to be recalculated for every pixel when the user scrolls or swipes with a mouse or touchpad.

One way to minimize that problem is by creating custom widgets that are minimal and only fulfill the purpose we absolutely need. However, this comes at the cost of needing to reimplement most functionality, including most, if not all accessibility features and semantics, such as keyboard focus, which severely impacted accessibility in GNOME Calendar.

While GTK’s widgets are great for general purpose use-cases and do not have any performance impact with limited instances of them, performance starts to deteriorate on weaker systems when there are hundreds, if not thousands of instances in the view, because they contain a lot of functionality that event widgets may not need.

In the case of the GtkButton widget, it has a custom multiplexer, it applies different styles for different child types, it implements the GtkActionable interface for custom actions, and more technical characteristics. Other functionality-based widgets will have more capabilities that might impact performance with hundreds of instances.

To summarize, GNOME Calendar reduces overhead by creating minimal custom widgets that fulfill a specific purpose. This unfortunately severely impacted accessibility throughout the app and made it unusable with a keyboard, as some core functionalities, accessibility features and semantics were never (re)implemented.

Improving the Existing Experience

Despite being inaccessible as an app altogether, not every aspect was inaccessible in GNOME Calendar. Most areas throughout the app worked with a keyboard and/or assistive technologies, but they needed some changes to improve the experience. For this reason, this section is reserved specifically for mentioning the aspects that underwent a lot of improvements.

Improving Focus Rings

The first major step was to improve the focus ring situation throughout GNOME Calendar. Since the majority of widgets are custom widgets, many of them require to manually apply focus rings. !563 addresses that by declaring custom CSS properties, to use as a base for focus rings. !399 tweaks the style of the reminders popover in the event editor dialog, with the addition of a focus ring.

We changed the behavior of the event notes box under the “Notes” section in the event editor dialog. Every time the user focuses on the event notes box, the focus ring appears and outlines the entire box until the user leaves focus. This was accomplished by subclassing AdwPreferencesRow to inherit its style, then applying the .focused class whenever the user focuses on the notes.

Improving the Calendar Grid

Note

The calendar grid is a 7×6 grid of buttons representing each day. The horizontal axis represents the day of the week, and the vertical axis represents the week number.

The calendar grid on the sidebar suffered from several issues when it came to keyboard navigation, namely:

• pressing ↹ would focus the next cell in the grid up until the last cell;
• when out of bounds, there would be no auditory feedback;
• on the last row, pressing ↓ would focus a blank element; and
• pressing → in left-to-right languages, or ← in right-to-left languages, on the last column would move focus to a completely different widget.

While the calendar grid can be interacted with a keyboard, the keyboard experience was far from desired. !608 addresses these issues by overriding the Gtk.Widget.focus () virtual method. Pressing ↹ or Shift+↹ skips the entire grid, and the grid is wrapped to allow focusing between the first and last columns with ← and →, while notifying the user when out of bounds.

Improving the Calendar List Box

The calendar list box had several problems in regards to keyboard navigation and the information each row provided to assistive technologies.

The user was required to press ↹ a second time to get to the next row in the list. To elaborate: pressing ↹ once focused the row; pressing it another time moved focus to the check button within the row (bad); and finally pressing the third time focused the next row.

Row widgets had no actual purpose besides toggling the check button upon activation. Similarly, the only use for a check button widget inside each row was to display the “check mark” icon if the calendar was displayed. This meant that the check button widget held all the desired semantics, such as the “checkbox” role and the “checked” state; but worst of all, it was getting focus. Essentially, the check button widget was handling responsibilities that should have been handled by the row.

Both inconveniences were addressed by !588. The check button widget was replaced with a check mark icon using GtkImage, a widget that does not grab focus. The accessible role of the row widget was changed to “checkbox”, and the code was adapted to handle the “checked” state.

Implementing Accessibility Functionality

Accessibility is often absolute: there is no ‘in-between’ state; either the user can access functionality, or they cannot, which can potentially make the app completely unusable. This section goes in depth with the widgets that were not only entirely inaccessible but also rendered GNOME Calendar completely unusable with a keyboard and assistive technology.

Making the Event Widget Accessible

Note

GcalEventWidget, the name of the event widget within GNOME Calendar, is a colored rectangular toggle button containing the summary of an event.

Activating it displays a popover that displays additional detail for that event.

GcalEventWidget subclasses GtkWidget.

The biggest problem in GNOME Calendar, which also made it completely impossible to use the app with a keyboard, was the lack of a way to focus and activate event widgets with a keyboard. Essentially, one would be able to create events, but there would be no way to access them in GNOME Calendar.

Quite literally, this entire saga began all thanks to a dream I had, which was to make GcalEventWidget subclass GtkButton instead of GtkWidget directly. The thought process was: GtkButton already implements focus and activation with a keyboard, so inheriting it should therefore inherit focus and activation behavior.

In merge request !559, the initial implementation indeed subclassed GtkButton. However, that implementation did not go through, due to the reason outlined in § Negative Implications of Accessibility due to Maximizing Performance.

Despite that, the initial implementation instead significantly helped us figure out exactly what were missing with GcalEventWidget: specifically, setting Gtk.Widget:receives-default and Gtk.Widget:focusable properties to “True”. Gtk.Widget:receives-default makes it so the widget can be activated how ever desired, and Gtk.Widget:focusable allows it to become focusable with a keyboard. So, instead of subclassing GtkButton, we instead reimplemented GtkButton’s functionality in order to maintain performance.

While preliminary support for keyboard navigation was added into GcalEventWidget, accessible semantics for assistive technologies like screen readers were severely lacking. This was addressed by !587, which sets the role to “toggle-button”, to convey that GcalEventWidget is a toggle button. The merge request also indicates that the widget has a popup for the event popover, and has the means to update the “pressed” state of the widget.

In summary, we first made GcalEventWidget accessible with a keyboard by reimplementing some of GtkButton’s functionality. Then, we later added the means to appropriately convey information to assistive technologies. This was the worst offender, and was the primary reason why GNOME Calendar was unusable with a keyboard, but we finally managed to solve it!

Making the Month and Year Spin Buttons Accessible

Note

GcalMultiChoice is the name of the custom spin button widget used for displaying and cycling through months and/or years.

It comprises of a “decrement” button to the start, a flat toggle button in the middle that contains a label that displays the value, and an “increment” button to the end. Only the button in the middle can gain keyboard focus throughout GcalMultiChoice.

In some circumstances, GcalMultiChoice can display a popover for increased granularity.

GcalMultiChoice was not interactable with a keyboard, because:

1. it did not react to ↑ and ↓ keys; and
2. the “decrement” and “increment” buttons were not focusable.

For a spin button widget, the “decrement” and “increment” buttons should generally remain unfocusable, because ↑ and ↓ keys already accomplish that behavior. Furthermore, GtkSpinButton’s “increment” (+) and “decrement” (-) buttons are not focusable either, and the Date Picker Spin Button Example by the ARIA Authoring Practices Guide (APG) avoids that functionality as well.

However, since GcalMultiChoice did not react to ↑ and ↓ keys, having the “decrement” and “increment” buttons be focusable would have been a somewhat acceptable workaround. Unfortunately, since those buttons were not focusable, and ↑ and ↓ keys were not supported, it was impossible to increment or decrement values in GcalMultiChoice with a keyboard without resorting to workarounds.

Additionally, GcalMultiChoice lacked the semantics to communicate with assistive technologies. So, for example, a screen reader would never say anything meaningful.

All of the above problems remained problems until merge request !603. For starters, it implements GtkAccessible and GtkAccessibleRange, and then implements keyboard navigation.

Implementing GtkAccessible and GtkAccessibleRange

The merge request implements the GtkAccessible interface to retrieve information from the flat toggle button.

Fundamentally, since the toggle button was the only widget capable of gaining keyboard focus throughout GcalMultiChoice, this caused two distinct problems.

The first issue was that assistive technologies only retrieved semantic information from the flat toggle button, such as the type of widget (accessible role), its label, and its description. However, the toggle button was semantically just a toggle button; since it contained semantics and provided information to assistive technologies, the information it provided was actually misleading, because it only provided information as a toggle button, not a spin button!

So, the solution to this is to strip the semantics from the flat toggle button. Setting its accessible role to “none” makes assistive technologies ignore its information. Then, setting the accessible role of the top-level (GcalMultiChoice) to “spin-button” gives semantic meaning to assistive technologies, which allows the widget to appropriately convey these information, when focused.

This led to the second issue: Assistive technologies only retrieved information from the flat toggle button, not from the top-level. Generally, assistive technologies retrieve information from the focused widget. Since the toggle button was the only widget capable of gaining focus, it was also the only widget providing information to them; however, since its semantics were stripped, it had no information to share, and thus assistive technologies would retrieve absolutely nothing.

The solution to this is to override the Gtk.Accessible.get_platform_state () virtual method, which allows us to bridge communication between the states of child widgets and the top-level widget. In this case, both GcalMultiChoice and the flat toggle button share the state—if the flat toggle button is focused, then GcalMultiChoice is considered focused; and since GcalMultiChoice is focused, assistive technologies can then retrieve its information and state.

The last issue that needed to be addressed was that GcalMultiChoice was still not providing any of the values to assistive technologies. The solution to this is straightforward: implementing the GtkAccessibleRange interface, which makes it necessary to set values for the following accessible properties: “value-max”, “value-min”, “value-now”, and “value-text”.

After all this effort, GcalMultiChoice now provides correct semantics to assistive technologies. It appropriately reports its role, the current textual value, and whether it contains a popover.

To summarize:

• The flat toggle button was the only widget conveying information to assistive technologies, as it was the only widget capable of gaining focus and providing semantic information. To solve this, its semantics were stripped away.
• The top-level, being GcalMultiChoice, was assigned the “spin-button” role to provide semantics; however, it was still incapable of providing information to assistive technologies, because it was never getting focused. To solve this, the state of the toggle button, including the focused state, carried over to the top-level to allow assistive technologies to retrieve information from the top-level.
• GcalMultiChoice still did not provide its values to assistive technologies. This is solved by implementing the GtkAccessibleRange interface.

Providing Top-Level Semantics to a Child Widget As Opposed to the Top-Level Widget Is Discouraged

As you read through the previous section, you may have asked yourself: “Why go through all of those obstacles and complications when you could have just re-assigned the flat toggle button as “spin-button” and not worry about the top-level’s role and focus state?”

Semantics should be provided by the top-level, because they are represented by the top-level. What makes GcalMultiChoice a spin button is not just the flat toggle button, but it is the combination of all the child widgets/objects, event handlers (touch, key presses, and other inputs), accessibility attributes (role, states, relationships), widget properties, signals, and other characteristics. As such, we want to maintain that consistency for practically everything, including the state. The only exception to this is widgets whose sole purpose is to contain one or more elements, such as GtkBox.

This is especially important for when we want it to communicate with other widgets and APIs, such as the Gtk.Widget::state-flags-changed signal, the Gtk.Widget.is_focus () method, and other APIs where it is necessary to have the top-level represent data accurately and behave predictably. In the case of GcalMultiChoice, we set accessible labels at the top-level. If we were to re-assign the flat toggle button’s role as “spin-button”, and set the accessible label to the top-level, assistive technologies would only retrieve information from the toggle button while ignoring the labels defined at the top-level.

For the record, GtkSpinButton also overrides Gtk.Accessible.get_platform_state ():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
static gboolean
gtk_spin_button_accessible_get_platform_state (GtkAccessible              *self,
                                               GtkAccessiblePlatformState  state)
{
  return gtk_editable_delegate_get_accessible_platform_state (GTK_EDITABLE (self), state);
}

static void
gtk_spin_button_accessible_init (GtkAccessibleInterface *iface)
{
  …

  iface->get_platform_state = gtk_spin_button_accessible_get_platform_state;
}

To be fair, assigning the “spin-button” role to the flat toggle button is unlikely to cause major issues, especially for an app. Re-assigning the flat toggle button was my first instinct. The initial implementation did just that as well. I was completely unaware of the Gtk.Accessible.get_platform_state () virtual method before finalizing the merge request, so I initially thought that was the correct way to do. Even if the toggle button had the “spin-button” role instead of the top-level, it would not have stopped us from implementing workarounds, such as a getter method that retrieves the flat toggle button that we can then use to manipulate it.

In summary, we want to provide semantics at the top-level, because they are structurally part of it. This comes with the benefit of making the widget easier to work with, because APIs can directly communicate with it, instead of resorting to workarounds.

The Now and Future of Accessibility in GNOME Calendar

All these accessibility improvements will be available on GNOME 49, but you can download and install the pre-release on the “Nightly GNOME Apps” DLC Flatpak remote on nightly.gnome.org.

In the foreseeable future, I want to continue working on !564, to make the month view itself accessible with a keyboard, as seen in the following:

However, it is already adding 640 lines of code, and I can only see it increasing overtime. We also want to make cells in the week view accessible, but this will also be a monstrous merge request, just like the above merge request.

Most importantly, we want (and need) to collaborate and connect with people who rely on assistive technologies to use their computer, especially when everybody working on GNOME Calendar does not rely on assistive technologies themselves.

Conclusion

I am overwhelmingly satisfied of the progress we have made with accessibility on GNOME Calendar in six months. Just a year ago, if I was asked about what needs to be done to incorporate accessibility features in GNOME Calendar, I would have shamefully said “dude, I don’t know where to even begin”; but as of today, we somehow managed to turn GNOME Calendar into an actual, usable calendaring app for people who rely on assistive technologies and/or a keyboard.

Since this is still Disability Pride Month, and GNOME 49 is not out yet, I encourage you to get the alpha release of GNOME Calendar on the “Nightly GNOME Apps” Flatpak remote at nightly.gnome.org. The alpha release is in a state where the gays with disabilities can organize and do crimes using GNOME Calendar 😎 /j

What do concern trolls and privileged people without visible or invisible disabilities who share or make content about accessibility on Linux being trash without contributing anything to projects have in common? They don’t actually really care about the group they’re defending; they just exploit these victims’ unfortunate situation to fuel hate against groups and projects actually trying to make the world a better place.

I never thought I’d be this upset to a point I’d be writing an article about something this sensitive with a clickbait-y title. It’s simultaneously demotivating, unproductive, and infuriating. I’m here writing this post fully knowing that I could have been working on accessibility in GNOME, but really, I’m so tired of having my mood ruined because of privileged people spending at most 5 minutes to write erroneous posts and then pretending to be oblivious when confronted while it takes us 5 months of unpaid work to get a quarter of recognition, let alone acknowledgment, without accounting for the time “wasted” addressing these accusations. This is far from the first time, and it will certainly not be the last.

I’m Not Angry

I’m not mad. I’m absolutely furious and disappointed in the Linux Desktop community for being quiet in regards to any kind of celebration to advancing accessibility, while proceeding to share content and cheer for random privileged people from big-name websites or social media who have literally put a negative amount of effort into advancing accessibility on Linux. I’m explicitly stating a negative amount because they actually make it significantly more stressful for us.

None of this is fair. If you’re the kind of person who stays quiet when we celebrate huge accessibility milestones, yet shares (or even makes) content that trash talks the people directly or indirectly contributing to the fucking software you use for free, you are the reason why accessibility on Linux is shit.

No one in their right mind wants to volunteer in a toxic environment where their efforts are hardly recognized by the public and they are blamed for “not doing enough”, especially when they are expected to take in all kinds of harassment, nonconstructive criticism, and slander for a salary of 0$.

There’s only one thing I am shamefully confident about: I am not okay in the head. I shouldn’t be working on accessibility anymore. The recognition-to-smearing ratio is unbearably low and arguably unhealthy, but leaving people in unfortunate situations behind is also not in accordance with my values.

I’ve been putting so much effort, quite literally hundreds of hours, into:

1. thinking of ways to come up with inclusive designs and experiences;
2. imagining how I’d use something if I had a certain disability or condition;
3. asking for advice and feedback from people with disabilities;
4. not getting paid from any company or organization; and
5. making sure that all the accessibility-related work is in the public, and stays in the public.

Number 5 is especially important to me. I personally go as far as to refuse to contribute to projects under a permissive license, and/or that utilize a contributor license agreement, and/or that utilize anything riskily similar to these two, because I am of the opinion that no amount of code for accessibility should either be put under a paywall or be obscured and proprietary.

Permissive licenses make it painlessly easy for abusers to fork, build an ecosystem on top of it which may include accessibility-related improvements, slap a price tag alongside it, all without publishing any of these additions/changes. Corporations have been doing that for decades, and they’ll keep doing it until there’s heavy push back. The only time I would contribute to a project under a permissive license is when the tool is the accessibility infrastructure itself. Contributor license agreements are significantly worse in that regard, so I prefer to avoid them completely.

The Truth Nobody Is Telling You

KDE hired a legally blind contractor to work on accessibility throughout the KDE ecosystem, including complying with the EU Directive to allow selling hardware with Plasma.

GNOME’s new executive director, Steven Deobald, is partially blind.

The GNOME Foundation has been investing a lot of money to improve accessibility on Linux, for example funding Newton, a Wayland accessibility project and AccessKit integration into GNOME technologies. Around 250,000€ (1/4) of the STF budget was spent solely on accessibility. And get this: literally everybody managing these contracts and communication with funders are volunteers; they’re ensuring people with disabilities earn a living, but aren’t receiving anything in return. These are the real heroes who deserve endless praise.

The Culprits

Do you want to know who we should be blaming? Profiteers who are profiting from the community’s effort while investing very little to nothing into accessibility.

This includes a significant portion of the companies sponsoring GNOME and even companies that employ developers to work on GNOME. These companies are the ones making hundreds of millions, if not billions, in net profit indirectly from GNOME (and other free and open-source projects), and investing little to nothing into them. However, the worst offenders are the companies actively using GNOME without ever donating anything to fund the projects.

Some companies actually do put an effort, like Red Hat and Igalia. Red Hat employs people with disabilities to work on accessibility in GNOME, one of which I actually rely on when making accessibility-related contributions in GNOME. Igalia funds Orca, the screen reader as part of GNOME, which is something the Linux community should be thankful of. However, companies have historically invested what’s necessary to comply with governments’ accessibility requirements, and then never invest in it again.

The privileged people who keep sharing and making content around accessibility on Linux being bad without contributing anything to it are, in my opinion, significantly worse than the companies profiting off of GNOME. Companies are and stay quiet, but these privileged people add an additional burden to contributors by either trash talking or sharing trash talkers. Once again, no volunteer deserves to be in the position of being shamed and ridiculed for “not doing enough”, since no one is entitled to their free time, but themselves.

My Work Is Free but the Worth Is Not

Earlier in this article, I mentioned, and I quote: “I’ve been putting so much effort, quite literally hundreds of hours […]”. Let’s put an emphasis on “hundreds”. Here’s a list of most accessibility-related merge requests that have been incorporated into GNOME:

• GNOME Calculator: !180 and !186
• GNOME Calendar: !331, !332, !333, !335, !336, !337, !344, !348, !358, !360, !362, !387, !388, !390, !421, !435, !489, !559, !563, !564, !569, !576, !587, and !588
• GNOME Contacts: !230
• GNOME Settings: !3017, !3018, and !3027
• GNOME Software: !1519 and !1570
• Papers: !119, !122, and !527
• libadwaita: !1243 (superseded by !1327) and !1245

GNOME Calendar’s !559 addresses an issue where event widgets were unable to be focused and activated by the keyboard. That was present since the very beginning of GNOME Calendar’s existence, to be specific: for more than a decade. This alone was was a two-week effort. Despite it being less than 100 lines of code, nobody truly knew what to do to have them working properly before. This was followed up by !576, which made the event buttons usable in the month view with a keyboard, and then !587, which properly conveys the states of the widgets. Both combined are another two-week effort.

Then, at the time of writing this article, !564 adds 640 lines of code, which is something I’ve been volunteering on for more than a month, excluding the time before I opened the merge request.

Let’s do a little bit of math together with ‘only’ !559, !576, and !587. Just as a reminder: these three merge requests are a four-week effort in total, which I volunteered full-time—8 hours a day, or 160 hours a month. I compiled a small table that illustrates its worth:

To summarize the table: those three merge requests that I worked on for free were worth 9,393.60$ CAD (6,921.36$ USD) in total at a minimum.

Just a reminder:

• these merge requests exclude the time spent to review the submitted code;
• these merge requests exclude the time I spent testing the code;
• these merge requests exclude the time we spent coordinating these milestones;
• these calculations exclude the 30+ merge requests submitted to GNOME; and
• these calculations exclude the merge requests I submitted to third-party GNOME-adjacent apps.

Now just imagine how I feel when I’m told I’m “not doing enough”, either directly or indirectly, by privileged people who don’t rely on any of these accessibility features. Whenever anybody says we’re “not doing enough”, I feel very much included, and I will absolutely take it personally.

It All Trickles Down to “GNOME Bad”

I fully expect everything I say in this article to be dismissed or be taken out of context on the basis of ad hominem, simply by the mere fact I’m a GNOME Foundation member / regular GNOME contributor. Either that, or be subject to whataboutism because another GNOME contributor made a comment that had nothing to do with mine but ‘is somewhat related to this topic and therefore should be pointed out just because it was maybe-probably-possibly-perhaps ableist’. I can’t speak for other regular contributors, but I presume that they don’t feel comfortable talking about this because they dared be a GNOME contributor. At least, that’s how I felt for the longest time.

Any content related to accessibility that doesn’t dunk on GNOME doesn’t foresee as many engagement, activity, and reaction as content that actively attacks GNOME, regardless of whether the criticism is fair. Many of these people don’t even use these accessibility features; they’re just looking for every opportunity to say “GNOME bad” and will 🪄 magically 🪄 start caring about accessibility.

Regular GNOME contributors like myself don’t always feel comfortable defending ourselves because dismissing GNOME developers just for being GNOME developers is apparently a trend…

Final Word

Dear people with disabilities,

I won’t insist that we’re either your allies or your enemies—I have no right to claim that whatsoever.

I wasn’t looking for recognition. I wasn’t looking for acknowledgment since the very beginning either. I thought I would be perfectly capable of quietly improving accessibility in GNOME, but because of the overall community’s persistence to smear developers’ efforts without actually tackling the underlying issues within the stack, I think I’ve justified myself to at least demand for acknowledgment from the wider community.

I highly doubt it will happen anyway, because the Linux community feeds off of drama and trash talking instead of being productive, without realizing that it negatively demotivates active contributors while pushing away potential contributors. And worst of all: people with disabilities are the ones affected the most because they are misled into thinking that we don’t care.

It’s so unfair and infuriating that all the work I do and share online gain very little activity compared to random posts and articles from privileged people without disabilities that rant about the Linux desktop’s accessibility being trash. It doesn’t help that I become severely anxious sharing accessibility-related work to avoid signs of virtue signalling. The last thing I want is to (unintentionally) give any sign and impression of pretending to care about accessibility.

I beg you, please keep writing banger posts like fireborn’s I Want to Love Linux. It Doesn’t Love Me Back series and their interluding post. We need more people with disabilities to keep reminding developers that you exist and your conditions and disabilities are a spectrum, and not absolute.

We simultaneously need more interest from people with disabilities to contribute to free and open-source software, and the wider community to be significantly more intolerant of bullies who profit from smearing and demotivating people who are actively trying.

We should take inspiration from “Accessibility on Linux sucks, but GNOME and KDE are making progress” by OSNews. They acknowledge that accessibility on Linux is suboptimal while recognizing the efforts of GNOME and KDE. As a community, we should promote progress more often.

Recently, the Linux Mint Blog published Monthly News – April 2024, which goes into detail about wanting to fork and maintain older GNOME apps in collaboration with other GTK-based desktop environments.

Despite the good intentions of the author, Clem, many readers interpreted this as an attack against GNOME. Specifically: GTK, libadwaita, the relationship between them, and their relevance to any desktop environment or desktop operating system. Unfortunately, many of these readers seem to have a lot of difficulty understanding what GTK is trying to be, and how libadwaita helps.

In this article, we’ll look at the history of why and how libadwaita was born, the differences between GTK 4 and libadwaita in terms of scope of support, their relevance to each desktop environment and desktop operating system, and the state of GTK 4 today.

What Is GTK?

First of all, what is GTK? GTK is a cross-platform widget toolkit from the GNOME Project, which means it provides interactive elements that developers can use to build their apps.

The latest major release of GTK is 4, which brings performance improvements over GTK 3. GTK 4 also removes several widgets that were part of the GNOME design language, which became a controversy. In the context of application design, a design language is the visual characteristics that are communicated to the user. Fonts, colors, shapes, forms, layouts, writing styles, spacing, etc. are all elements of the design language.^(Source)

Unnecessary Unification of the Toolkit and Design Language

In general, cross-platform toolkits tend to provide general-purpose/standard widgets, typically with a non-opinionated styling, i.e. widgets and design patterns that are used consistently across different operating systems (OSes) and desktop environments.

However, GTK had the unique case of bundling GNOME’s design language into GTK, which made it far from generic, leading to problems of different lexicons, mainly philosophical and technical problems.

Clash of Philosophies

When we look at apps made for the GNOME desktop (will be referred to as “GNOME apps”) as opposed to non-GNOME apps, we notice that they’re distinctive: GNOME apps tend to have hamburger buttons, header bars, larger buttons, larger padding and margins, etc., while most non-GNOME apps tend to be more compact, use menu bars, standard title bars, and many other design metaphors that may not be used in GNOME apps.

This is because, from a design philosophy standpoint, GNOME’s design patterns tend to go in a different direction than most apps. As a brand and product, GNOME has a design language it adheres to, which is accompanied by the GNOME Human Interface Guidelines (HIG).

As a result, GTK and GNOME’s design language clashed together. Instead of being as general-purpose as possible, GTK as a cross-platform toolkit contained an entire design language intended to be used only by a specific desktop, thus defeating the purpose of a cross-platform toolkit.

For more information on GNOME’s design philosophy, see “What is GNOME’s Philosophy?”.

Inefficient Diversion of Resources

The unnecessary unification of the toolkit and design language also divided a significant amount of effort and maintenance: Instead of focusing solely on the general-purpose widgets that could be used across all desktop OSes and environments, much of the focus was on the widgets that were intended to conform to the GNOME HIG. Many of the general-purpose widgets also included features and functionality that were only relevant to the GNOME desktop, making them less general-purpose.

Thus, the general-purpose widgets were being implemented and improved slowly, and the large codebase also made the GNOME widgets and design language difficult to maintain, change, and adapt. In other words, almost everything was hindered by the lack of independence on both sides.

Libhandy: the Predecessor

Because of the technical bottlenecks caused by the philosophical decisions, libhandy was created in 2017, with the first experimental version released in 2018. As described on the website, libhandy is a collection of “[b]uilding blocks for modern adaptive GNOME applications.” In other words, libhandy provides additional widgets that can be used by GNOME apps, especially those that use GTK 3. For example, Boxes uses libhandy, and many GNOME apps that used to use GTK 3 also used libhandy.

However, some of the problems remained: Since libhandy was relatively new at the time, most GNOME widgets were still part of GTK 3, which continued to suffer from the consequences of merging the toolkit and design language. Furthermore, GTK 4 was released at the end of December 2020 — after libhandy. Since libhandy was created before the initial release of GTK 4, it made little sense to fully address these issues in GTK 3, especially when doing so would have caused major breakages and inconveniences for GTK, libhandy, and app developers. As such, it wasn’t worth the effort.

With these issues in mind, the best course of action was to introduce all these major changes and breakages in GTK 4, use libhandy as an experiment and to gain experience, and properly address these issues in a successor.

Libadwaita: the Successor

Because of all the above problems, libadwaita was created: libhandy’s successor that will accompany GTK 4.

GTK 4 was initially released in December 2020, and libadwaita was released one year later, in December 2021. With the experience gained from libhandy, libadwaita managed to become extensible and easy to maintain.

Libadwaita is a platform library accompanying GTK 4. A platform library is a library used to complement a specific platform. In the case of libadwaita, the platform it targets is the GNOME desktop.

Porting Widgets to Libadwaita

Some GNOME widgets from GTK 3 (or earlier versions of GTK 4) were removed or deprecated in GTK 4 and were reimplemented in / transferred to libadwaita, for example:

• GtkDialog → AdwDialog¹
• GtkInfoBar → AdwBanner

These aforementioned widgets only benefited GNOME apps, as they were strictly designed to provide widgets that conformed to the GNOME HIG. Non-GNOME apps usually didn’t use these widgets, so they were practically irrelevant to everyone else.

In addition, libadwaita introduced several widgets as counterparts to GTK 4 to comply with the HIG:

• GtkHeaderBar → AdwHeaderBar
• GtkAlertDialog → AdwAlertDialog
• GtkAboutDialog → AdwAboutDialog

Similarly, these aforementioned GTK 4 (the ones starting with Gtk) widgets are not designed to comply with the GNOME HIG. Since GTK 4 widgets are supposed to be general-purpose, they should not be platform-specific; the HIG no longer has any influence on GTK, only on the development of libadwaita.

Scope of Support

The main difference between GTK 4 and libadwaita is the scope of support, specifically the priorities in terms of the GNOME desktop, and desktop environment and OS support. While most resources are dedicated to GNOME desktop integration, GTK 4 is not nearly as focused on the GNOME desktop as libadwaita. GTK 4, while opinionated, still tries to get closer to the traditional desktop metaphor by providing these general-purpose widgets, while libadwaita provides custom widgets to conform to the GNOME HIG.

Since libadwaita is only made for the GNOME desktop, and the GNOME desktop is primarily officially supported on Linux, libadwaita thus primarily supports Linux. In contrast, GTK is officially supported on all major operating systems (Windows, macOS, Linux). However, since GTK 4 is mostly developed by GNOME developers, it works best on Linux and GNOME — hence “opinionated”.

State of GTK 4 Today

Thanks to the removal of GNOME widgets from GTK 4, GTK developers can continue to work on general-purpose widgets, without being influenced or restricted in any way by the GNOME HIG. Developers of cross-platform GTK 3 apps that rely exclusively on general-purpose widgets can be more confident that GTK 4 won’t remove these widgets, and hopefully enjoy the benefits that GTK 4 offers.

At the time of writing, there are several cross-platform apps that have either successfully ported to GTK 4, or are currently in the process of doing so. To name a few: Freeciv gtk4 client, HandBrake, Inkscape, Transmission, and PulseAudio Volume Control. The LibreOffice developers are working on the GTK 4 port, with the gtk4 VCL plugin option enabled. For example, the libreoffice-fresh package from Arch Linux has it enabled.

Here are screenshots of the aforementioned apps:

A GNOME App Remains a GNOME App, Unless Otherwise Stated

This is a counter-response to Thom Holwerda’s response to this article.

An app targeting a specific platform will typically run best on that platform and will naturally struggle to integrate with other platforms. Whether the libraries change over time or stay the same forever, if the developers are invested in the platform they are targeting, the app will follow the direction of the platform and continue to struggle to integrate with other platforms. At best, it will integrate in other platforms by accident.

In this case, developers who have and will continue to target the GNOME desktop will actively adapt their apps to follow the GNOME philosophy, for better or worse. Hamburger buttons, header bars, typography, and distinct design patterns were already present a decade ago (2014).^(Source) Since other platforms were (and still are) adhering to different design languages, with or without libhandy/libadwaita, the GTK 3 apps targeting GNOME were already distinguishable a decade ago. Custom solutions such as theming were (and still are) inadequate, as there was (and still is) no 🪄 magical 🪄 solution that converts GNOME’s design patterns into their platform-agnostic counterparts.

Whether the design language is part of the toolkit or a separate library has no effect on integration, because GNOME apps already looked really different long before libhandy was created, and non-GNOME apps already looked “out of place” in GNOME as well. Apps targeting a specific platform that unintentionally integrate with other platforms will eventually stop integrating with other platforms as the target platform progresses and apps adapt. In rare cases, developers may decide to no longer adhere to the GNOME HIG.

Alternate Platforms

While libadwaita is the most popular and widely used platform library that accompanies GTK 4, there are several alternatives to libadwaita:

• Granite is developed and maintained by elementary, Inc., and focuses on elementary OS and the Pantheon desktop. Apps that use Granite can be found in the elementary AppCenter.
• Libhelium is developed and maintained by Fyra Labs, and focuses on tauOS. Apps using libhelium can be found in the “libhelium” topics on GitHub.

There are also several alternatives to libhandy:

• libxapp is developed and maintained by Linux Mint, and focuses on multiple GTK desktop environments, such as Cinnamon, MATE, and Xfce.
• libxfce4ui is developed and maintained by Xfce, and focuses on Xfce.

Just like libadwaita and libhandy, these platform libraries offer custom widgets and styling that differ from GTK and are built for their respective platforms, so it’s important to realize that GTK is meant to be built with a complementary platform library that extends its functionality when targeting a specific platform.

Similarly, Kirigami from KDE accompanies Qt to build Plasma apps. MauiKit from the Maui Project (another KDE project) also accompanies Qt, but targets Nitrux. Libcosmic by System76 accompanies iced to build COSMIC apps.

Conclusion

A cross-platform toolkit should primarily provide general-purpose widgets. Third parties should be able to extend the toolkit as they see fit through a platform library if they want to target a specific platform.

As we’ve seen throughout the philosophical and technical issues with GTK, a lot of effort has gone into moving GNOME widgets from GTK 4 to libadwaita. GTK 4 will continue to provide these general-purpose widgets for apps intended to run on any desktop or OS, while platform libraries such as libadwaita, Granite and libhelium provide styling and custom widgets that respect their respective platforms.

Libadwaita is targeted exclusively at the GNOME ecosystem, courtesy of the GNOME HIG. Apps built with libadwaita are intended to run best on GNOME, while GTK 4 apps that don’t come with a platform library are intended to run everywhere.

I am publicly announcing that I am transgender. I have experienced gender dysphoria for almost ten years, but I have found a label that I feel comfortable with now.

In this article, I’m going to go over:

• The environment I’ve lived for the last ten years
• My gender identity
• How to seek help
• Tips for those exploring themselves or seeking to understand trans individuals

Vocabularies

Before I delve into my personal experience, allow me to define several key terms:

• Sex: Biological characteristics of males and females.
• Gender: Social characteristics of men and women, such as norms, roles, and behaviors.
• Gender identity: How you personally view your own gender.
• Gender dysphoria: Sense of unease due to a mismatch between gender identity and sex assigned at birth.
• Transgender (trans): The gender identity differs from the sex assigned at birth. If someone’s gender identity is woman but their sex assigned at birth is male, then they are generally considered a trans person.
• Cisgender (cis): The opposite of transgender; when the gender identity fits with the sex assigned at birth.
• Non-binary: Anything that is not exclusively male or female. Imagine if male and female were binary numbers: male is 0 and female is 1. Anything that is not 0 or 1 is considered non-binary. If I see myself as the number 0.5 or 2, then I’m non-binary. Someone who considers themself to be between a man and woman would be between 0 and 1 (e.g. 0.5).
• Agender: Under the umbrella of non-binary; it essentially means non-gendered (lack of gender identity) or gender neutral. Whichever definition applies varies from person to person. It’s also worth noting that many agender people don’t consider themselves trans.
• Label: Portraying which group you belong to, such as “non-binary”, “transfemme” (trans (binary and non-binary) people who are feminine), etc.

Backstory

Allow me to share a little backstory. I come from a neighborhood where being anti-LGBTQ+ was considered “normal” a decade ago. This outlook was quite common in the schools I attended, but I wouldn’t be surprised if a considerably significant portion of the people around here are still anti-LGBTQ+ today. Many individuals, including former friends and teachers, have expressed their opposition to LGBTQ+ in the past, which influenced my own view against the LGBTQ+ community at the time.

Due to my previous experiences and the environment I live(d) in, I tried really hard to avoid thinking about my sexuality and gender identity for almost a decade. Every time I thought about my sexuality and gender identity, I’d do whatever I could to distract myself. I kept forcing myself to be as masculine as possible. However, since we humans have a limit, I eventually reached a limit to the amount of thoughts I could suppress.

I always struggled with communicating and almost always felt lonely whenever I was around the majority of people, so I pretended to be “normal” and hid my true feelings. About 5 years ago, I began to spend most of my time online. I met people who are just like me, many of which I’m still friends with 3-4 years later. At the time, despite my strong biases against LGBTQ+ from my surroundings, I naturally felt more comfortable within the community, far more than I did outside. I was able to express myself more freely and have people actually understand me. It was the only time I didn’t feel the need to act masculine. However, despite all this, I was still in the mindset of suppressing my feelings. Truly an egg irl moment

Eventually, I was unable hold my thoughts anymore, and everything exploded. All I could think about for a few months was my gender identity: my biases between my childhood environment often clashed with me questioning my own identity, and whether I really saw myself as a man. I just had these recurring thoughts and a lot of anxiety about where I’m getting these thoughts from, and why.

Since then, my work performance got exponentially worse by the week. I quickly lost interest in my hobbies, and began to distance myself from communities and friends. I often lashed out on people because my mental health was getting worse. My sleep quality was also getting worse, which only worsened the situation. On top of that, I still had to hide my feelings, which continued to exhaust me. All I could think about for months was my gender identity.

After I slowly became comfortable with and accepting of my gender identity, I started having suicidal thoughts on a daily basis, which I was able to endure… until I reached a breaking point once again. I was having suicidal thoughts on a bi-hourly basis. It escalated to hourly, and finally almost 24/7. I obviously couldn’t work anymore, nor could I do my hobbies. I needed to hide my pain because of my social anxiety. I also didn’t have the courage to call the suicide hotline either. What happened was that I talked to many people, some of whom have encouraged and even helped me seek professional help.

However, that was all in the past. I feel much better and more comfortable with myself and the people I opened up to, and now I’m confident enough to share it publicly 😊

Coming Out‎ ‎🏳️‍⚧️

I identify as agender. My pronouns are any/all — I’ll accept any pronouns. I don’t think I have a preference, so feel free to call me as whatever you want; whatever you think fits me best :)

I’m happy with agender because I feel disconnected from my own masculinity. I don’t think I belong at either end of the spectrum (or even in between), so I’m pretty happy that there is something that best describes me.

Why the Need to Come Out Publicly?

So… why come out publicly? Why am I making a big deal out of this?

Simply put, I am really proud and relieved for discovering myself. For so long, I tried to suppress my thoughts and force myself to be someone I was fundamentally not. While that never worked, I explored myself instead and discovered that I’m trans. However, I also wrote this article to explain how much it affected me for living in a transphobic environment, even before I discovered myself.

For me, displaying my gender identity is like displaying a username or profile picture. We choose a username and profile picture when possible to give a glimpse of who we are.

I chose “TheEvilSkeleton” as my username because I used to play Minecraft regularly when I was 10 years old. While I don’t play Minecraft anymore, it helped me discover my passion: creating and improving things and working together — that’s why I’m a programmer and contribute to software. I chose Chrome-chan as my profile picture because I think she is cute and I like cute things :3. I highly value my username and profile picture, the same way I now value my gender identity.

Am I Doing Better?

While I’m doing much better than before, I did go through a depressive episode that I’m still recovering from at the time of writing, and I’m still processing the discovery because of my childhood environment, but I certainly feel much better after discovering myself and coming out.

However, coming out won’t magically heal the trauma I’ve experienced throughout my childhood environment. It won’t make everyone around me accept who I am, or even make them feel comfortable around me. It won’t drop the amount of harassment I receive online to zero — if anything, I write this with the expectation that I will be harassed and discriminated against more than ever.

There will be new challenges that I will have to face, but I still have to deal with the trauma, and I will have to deal with possible trauma in the future. The best thing I can do is train myself to be mentally resilient. I certainly feel much better coming out, but I’m still worried about the future. I sometimes wish I wasn’t trans, because I’m genuinely terrified about the things people have gone through in the past, and are still going through right now.

I know I’m going to have to fight for my life now that I’ve come out publicly, because apparently the right to live as yourself is still controversial in 2024.

Seeking Help

Of course, I wasn’t alone in my journey. What helped me get through it was talking to my friends and seeking help in other places. I came out to several of my friends in private. They were supportive and listened to me vent; they reassured me that there’s nothing wrong with me, and congratulated me for discovering myself and coming out.

Some of my friends encouraged and helped me seek professional help at local clinics for my depression. I have gained more confidence in myself; I am now capable to call clinics by myself, even when I’m nervous. If these suicidal thoughts escalate again, I will finally have the courage to call the suicide hotline.

If you’re feeling anxious about something, don’t hesitate to talk to your friends about it. Unless you know that they’ll take it the wrong way and/or are currently dealing with personal issues, they will be more than happy to help.

I have messaged so many people in private and felt much better after talking. I’ve never felt so comforted by friends who try their best to be there for me. Some friends have listened without saying anything, while some others have shared their experiences with me. Both were extremely valuable to me, because sometimes I just want (and need) to be heard and understood.

If you’re currently trying to suppress your thoughts and really trying to force yourself into the gender you were assigned at birth, like I was, the best advice I can give you is to give yourself time to explore yourself. It’s perfectly fine to acknowledge that you’re not cisgender (that is, if you’re not). You might want to ask your trans friends to help you explore yourself. From experience, it’s not worth forcing yourself to be someone you’re not.

Closing Thoughts

I feel relieved about coming out, but to be honest, I’m still really worried about the future of my mental health. I really hope that everything will work out and that I’ll be more mentally resilient.

I’m really happy that I had the courage to take the first steps, to go to clinics, to talk to people, to open up publicly. It’s been really difficult for me to write and publish the article. I’m really grateful to have wonderful friends, and legitimately, I couldn’t ask for better friends.

We spent a whole week rewriting nouveau’s website — the drivers for NVIDIA cards. It started as a one-person effort, but it led to a few people helping me out. We addressed several issues in the nouveau website and improved it a lot. The redesign is live on nouveau.freedesktop.org.

In this article, we’ll go over the problems with the old site and the work we’ve done to fix them.

Problems With Old Website

I’m going to use this archive as a reference for the old site.

The biggest problem with the old site was that the HTML and CSS were written 15 years ago and have never been updated since. So in 2023, we were relying on outdated HTML/CSS code. Obviously, this was no fun from a reader’s perspective. With the technical debt and lack of interest, we were suffering from several problems. The only good thing about the old site was that it didn’t use JavaScript, which I wanted to keep for the rewrite.

Fun fact: the template was so old that it could be built for browsers that don’t support HTML5!

Not Responsive

“Responsive design” in web design means making the website accessible on a variety of screen sizes. In practice, a website should adapt to work on mobile devices, tablets, and laptops/computer monitors.

In the case of the nouveau website, it didn’t support mobile screen sizes properly. Buttons were hard to tap and text was small. Here are some screenshots taken in Firefox on my Razer Phone 2:

No Dark Style

Regardless of style preferences, having a dark style/theme can help people who are sensitive to light and battery life on AMOLED displays. Dark styles are useful for those who absolutely need them.

No SEO

Search Engine Optimization (SEO) is the process of making a website more discoverable on search engines like Google. We use various elements such as title, description, icon, etc. to increase the ranking in search engines.

In the case of nouveau, there were no SEO efforts. If we look at the old nouveau homepage’s <head> element, we get the following:

1
2
3
4
5
6
7
8
<head>
<meta charset="utf-8">
<title>nouveau</title>
<link rel="stylesheet" href="style.css" type="text/css">
<link rel="stylesheet" href="xorg.css" type="text/css">
<link rel="stylesheet" href="local.css" type="text/css">
<link rel="alternate" type="application/x-wiki" title="Edit this page" href="https://gitlab.freedesktop.org/nouveau/wiki/-/edit/main/sources/index.mdwn">
</head>

The only thing there was a title, which is, obviously, far from desirable. The rest were CSS stylesheets, wiki source link, and character set.

Readability Issues

One of the biggest problems with nouveau’s website (apart from the homepage) is the lack of a maximum width. Large paragraphs stretch across the screen, making it difficult to read.

Process of Rewriting

Before I started the redesign, I talked to Karol Herbst, one of the nouveau maintainers. He had been wanting to redesign the nouveau site for ages, so I asked myself, “How hard can it be?” Well… mistakes were made.

The first step was to look at the repository and learn about the tools freedesktop.org uses for their website. freedesktop.org uses ikiwiki to generate the wiki. Problem is: it’s slow and really annoying to work with. The first thing I did was create a Fedora toolbox container. I installed the ikiwiki package to generate the website locally.

The second step was to rewrite the CSS and HTML template. I took a look at page.tmpl — the boilerplate. While looking at it, I discovered another problem: the template is unreadable. So I worked on that as well.

I ported to modern HTML elements, like <nav> for the navigation bar, <main> for the main content, and <footer> for the footer.

The third step was to rewrite the CSS. In the <head> tag above, we can see that the site pulls CSS from many sources: style.css, xorg.css, and local.css. So what I did was to delete xorg.css and local.css, delete the contents of style.css, and rewrite it from scratch. I copied a few things from libadwaita, namely its buttons and colors.

And behold… merge request !29!

Despite the success of the rewrite, I ran into a few roadblocks. I couldn’t figure out how to make the freedesktop.org logo dark style. Luckily, my friend kramo helped me out by providing an SVG file of the logo that adapts to dark style, based on Wikipedia’s. They also adjusted the style of the website to make it look nicer.

I also couldn’t figure out what to do with the tables because the colors were low contrast. Also, the large table on the Feature Matrix page was limited in maximum width, which would make it uncomfortable on large monitors. Lea from Fyra Labs helped with the tables and fixed the problems. She also adjusted the style.

After that, the rewrite was mostly done. Some reviewers came along and suggested some changes. Karol wanted the rewrite so badly that he opened a poll asking if he should merge it. It was an overwhelming yes, so… it got merged!

Conclusion

As Karol, puts it:

In all seriousness, I’ve had a great time working on it. While this is the nouveau site in particular, I plan to eventually rewrite the entire freedesktop.org site. However, I started with nouveau because it was hosted on GitLab. Meanwhile, other sites/pages are hosted on freedesktop.org’s cgit instance, which were largely inaccessible for me to contribute to.

Ideally, we’d like to move from ikiwiki to something more modern, like a framework or a better generator, but we’ll have to see who’s willing to work on it and maintain it.

I find that many Linux users have a misconception about immutable distributions without knowing what it actually is. There is a lot of misinformation and generalization in the Internet about immutable distributions being “locked down”, “inflexible”, etc., when we could argue the same with many traditional distributions.

In this article, we’ll look at what makes an immutable distribution, the concept of an immutable distribution versus implementations, misconceptions about immutable distributions (both pro and con), and why they exist in the first place.

What Is an Immutable Distribution?

“Immutable” is a fancy way of saying unchangeable. So, an immutable distribution is essentially an unchangeable distribution, i.e. read-only. However, in most cases, the entirety of the distribution is not immutable. Some directories, like /tmp, are writable, as they need write capabilities to actually function. Some distributions may even have other directories, such as /etc, writable for extra functionality.

To redefine, an immutable distribution is when, at a minimum, only the core of the distribution is read-only, and the rest is read-write.

Note: The more accurate terms are “reprovisionable” and “anti-hysteresis”. However, since “immutable” is more commonly used, I’ll use it instead throughout this article. Further reading: “Immutable” → reprovisionable, anti-hysteresis by Colin Walters.

Technical Definitions

There are a few technical definitions that should be understood before reading the rest of the article:

• Rollback (rolling back): Undoing a change or update. For example, you upgrade your system to the latest version, which introduces bugs. You can then revert that update and go back to the version that worked well.
• Reproducibility: Delivering identical software regardless of the time or system used. Suppose you install a distribution on hundreds of laptops and desktops over the course of a week. The distribution you install on the first desktop (on the first day) will be exactly the same as the last laptop (on the last day). That is, all systems will be identical. You can think of it as a perfect clone.
• Atomicity (atomic updates): Ensuring that a change (update, downgrade, etc.) is either fully applied or aborted. For example, your system shuts down in the middle of an upgrade due to a power outage. Instead of having a half-updated system, the update is fully aborted, meaning that your system was unchanged, just like before you started the update.

Concept Versus Implementations

It’s really easy to confuse the concept and the implementation when discussing immutability.

As we noted above, an immutable distribution is when the core of the distribution is read-only — that’s it. You (or someone else) decide to implement that concept as you see fit. You could have a locked down and inflexible system, like GNOME OS,¹ where there isn’t even a system package manager; or you could have something that is designed to be flexible, like NixOS, where you can change the desktop environment, the kernel, the boot loader, and so on.

You can think of an immutable distribution as any traditional distribution. Some traditional distributions are locked down and inflexible, such as Fedora Workstation, where removing or even disabling SELinux can cause problems. Fedora Workstation also prevents you from accidentally removing core packages like sudo. Meanwhile, some traditional distributions are designed to be flexible, such as Gentoo Linux, where you can change almost anything in your system.

Misconceptions

There are several misconceptions both for and against immutable distributions that I would like to address.

I’m going to use pseudo quotes, which means I will be quoting and refining arguments I’ve interpreted from debates and media.

“Needing to Reboot”

Due to the read-only nature of immutable distributions, applying changes (updates, installs, etc.) absolutely requires a reboot.

The need of reboots varies per implementation. With Endless OS, you must reboot to apply updates. On Fedora Silverblue, you can run sudo rpm-ostree apply-live in the terminal to apply changes while the system is booted. On NixOS, you don’t need to reboot at all.

Even then, rebooting your system after updating it is really important to keep it running optimally. As the article Restarting and Offline Updates explains: “The Linux Kernel can change files without restarting, but the services or application using that file don’t have the same luxury. If a file being used by an application changes while the application is running then the application won’t know about the change. This can cause the application to no longer work the same way. As such, the adage that “Linux doesn’t need to restart to update” is a discredited meme. All Linux distributions should restart.”

Many immutable distributions focus on reboots when performing system-level updates, because in many cases a reboot is crucial for stability. That’s why Android, iOS, macOS, Windows, ChromeOS, etc. require a reboot.

“Difficult to Use”

Since immutable distributions are locked down, inflexible, and often need workarounds for various issues, they’re more difficult to use.

Difficulty varies per implementation and users’ priorities. For me, Fedora Silverblue is really easy to use, because it provides a great experience by default;² I want something that is reliable, gets out of my way as much as possible, and follows closest with my political views (I value free software, inclusiveness in the community, and progressing the Linux desktop), which Fedora Silverblue is one of the few that provides.³ However, NixOS isn’t for me, because I’m not a power user.

Endless OS is used by many educational institutions, because these institutions typically need a system that is simple, accessible and secure. On the contrary, NixOS is a powerful system typically used by power users and organizations that absolutely need the features it offers.

However, it’s worth noting that, no matter the distribution, immutable or not, workarounds may be needed. Nothing is perfect, but there are many cases when external developers refuse to collaborate. For example, many drivers are unavailable in the Linux kernel, so we’re sometimes forced to inconveniently install these drivers manually. While a distribution like Arch Linux has the AUR, most other traditional distributions do not have the luxury of installing obscure drivers. In short, this isn’t a fundamental problem with immutable distributions; it’s a problem that you have with every distribution.

“Inflexible by Nature”

Due to the read-only nature of immutable distributions, users cannot tinker with their system.

Again, this heavily depends on the implementation. If we look at traditional distributions, Ubuntu is not designed to be tinkered with, nor is Fedora Linux. As such, these distributions are prone to breaking after a significant amount of modification.

Meanwhile, NixOS, an immutable distribution, empowers the user and allows them to change many aspects of their system. Don’t like GRUB? Use systemd-boot, rEFInd or something else. You want to add a Mandatory Access Control? Use SELinux. Don’t like SELinux? use AppArmor or something else. Don’t like using GNOME? Use Plasma, XFCE, MATE, Cinnamon, Sway or any desktop environment/window manager. Don’t like the fact that you’re using an LTS version of NixOS? Just switch to an unstable or even a bleeding edge channel. What’s that, you want to go back to LTS? You can. Want to mix and match packages from different channels? Go for it… You could view NixOS as Arch Linux on steroids.

Really, some traditional and immutable distributions are locked down and inflexible, meanwhile some others are flexible. This heavily varies per implementation.

“Immutable Distributions Are More Secure”

Immutable distributions provide better security, because […]

I truly believe that statements like these create a false sense of security because “security” can be interpreted differently by different people. Allow me to identify the meanings of “security” and address each of them:

“Security as a Safety Net”

You can roll back or prevent damage in case an error occurs. For example, your system shuts down in the middle of an update due to a power outage. However, thanks to the system’s atomicity, nothing was changed on the system, thereby allowing you to boot back into the system without a problem.

Atomicity could be replicated on traditional distributions if someone put in the effort.

If the system updates but runs into problems, you can roll back from your bootloader.

Rollbacks can be implemented on traditional distributions. Linux Mint and openSUSE Tumbleweed/Leap are some implementors of this feature.

“Security as a Measure to Prevent Malicious Actors From Compromising Your System”

Thanks to the read-only nature of immutable distributions, they prevent malicious actors from doing more damage than traditional distributions.

While immutable distributions might prevent malicious actors from doing certain things on your system, the bigger problem is that your personal data is at risk. Whether the actor can use sudo is less of an issue than the fact that your GPG keys, personal media and documents, or other sensitive data are easily accessible once compromised.

Whether your system is immutable or not, there are still really important steps you should be taking to make your system more secure. For example, you can use LUKS2 to encrypt your drive(s) to protect your data from physical access, and you can use Flatpak (with Flatseal) to make sure that your data is better protected from malicious/compromised apps. These steps are highly beneficial and should not be taken lightly!

“Security as a Measure to Prevent Users From Breaking Their Own Systems”

Thanks to the read-only nature of immutable distributions, even the most destructive actions, like sudo rm -rf --no-preserve-root /* won’t destroy the system.

While running such commands might prevent total destruction, they can still do enough damage to make the benefit meaningless. In this example, running sudo rm -rf --no-preserve-root /* will delete your $HOME (user) directory if you wait long enough, since the user directory is mutable; depending on the implementation, it could delete your boot partition as well. These destructive commands are usually destructive in other ways on immutable distributions, as the vulnerable bit is the mutable places. Only the immutable parts of the systems are unaffected, but the rest are just as vulnerable as any vulnerable place in traditional distributions.

Immutability Is an Implementation Detail

Immutable and traditional distributions can literally share the same benefits and drawbacks, because, in reality, whether the core of the distribution is read-only or read-write is a minor detail. An immutable distribution could be as unstable as Manjaro and rely on distribution packages, meanwhile a traditional distribution could be as stable as Endless OS and fully embrace containers, such as Flatpak. A traditional distribution could be as locked down and inflexible as GNOME OS, meanwhile an immutable distribution could be as flexible as Gentoo Linux (theoretically).

Immutable distributions are different from each other, the same way traditional distributions are different from each other as well. For example, Vanilla OS utilizes ABRoot, whose concept is inspired from Android’s A/B system updates. Fedora Silverblue and Endless OS utilize OSTree, which is similar to git in paradigm. MicroOS utilizes btrfs’s features. NixOS does, uhh… yes.

While immutable and traditional distributions are presented as different in categories, they have very little difference in nature. It’s best to treat immutable distributions like traditional distributions, rather than a whole different paradigm. It’s up to the maintainers to decide what they want to do with their distribution.

Immutability Relieves Maintenance Burden

Okay, as explored above, if the “benefits” are not benefits that are exclusive to immutable distributions and can be applied to traditional distributions, then why do immutable distributions exist in the first place? Why not just implement atomicity, reproducibility, and rollback functionalities to a traditional distribution?

Simply put, immutable distributions make it much easier for maintainers to focus on their high-level goals, because immutability eases the burden of maintenance.

The benefits are indirect for users, but direct for maintainers. Maintainers have fewer things to worry about than in traditional distributions, which allows them to spend their precious time and resources on the things they actually want to worry about, such as stability, reproducibility, providing a safety net, and so on. As a result, users get a more robust system.

This is why immutable distributions are generally considered “safer” than traditional distributions, even though the concept is not. So far, maintainers have put more effort into making their immutable distribution robust, as opposed to traditional distributions, which usually have to worry about the whole mutable aspect. This benefits immutable distributions greatly, because they don’t have to worry about solving the problems that traditional distributions typically run into.

Similarly, many developers prefer to officially support Flatpak over traditional packaging formats, because they only have to worry about one format as opposed to hundreds. As a result, they have more time and energy to focus on achieving their real goals, instead of focusing on tedious repetitive tasks and supporting a wider range of combinations (packaging format, dependencies version and patches, etc.).

All of these features (reproducibility, atomicity, and rollback) can also be implemented in traditional distributions. However, these features are typically treated as first-class features in immutable distributions, even though they are not mandated, whereas they are second-class features in most traditional distributions that support them. Immutability greatly reduces the maintenance overhead and leaves more room to improve the things maintainers want to improve. Immutable distributions have recently become popular, and are already used and popular in educational and personal systems.

Conclusion

To summarize, an immutable distribution is when the core of the distribution is read-only. Anyone is free to grab that concept and implement a distribution with it. The “benefits” and “inconveniences” that we tend to see with immutable distributions could be applied on traditional distributions, but immutable distributions tend to be easier to accomplish the high-level goals, because they are easier to maintain.

In the end, immutability should be seen as an implementation detail and philosophical/political decision, rather than a purely technical one, because traditional and immutable distributions can literally share the same benefits and drawbacks.

Footnotes

Telemetry is one of the biggest controversial topics in the Linux community. Many people believe that telemetry is entirely meaningless, because developers can “just” ask their users. Some people also argue that users can opt into telemetry if they want to participate, but most of these users are in consensus that opt-out telemetry shouldn’t be there in the first place.

However, I don’t believe that asking users or explicitly opting into telemetry helps to a degree where developers and designers can form educated conclusions, as both methods share many issues regarding gathering data accurately. In this article, we’re going to explore the issues around asking users and opting into telemetry, and then I will explain why opt-out telemetry is a better approach to gather accurate data and forming educated conclusions.

Definition and Methods of Gathering User Data

Per Wikipedia, telemetry “is used to gather data on the use and performance of applications and application components, e.g. how often certain features are used, measurements of start-up time and processing time, hardware, application crashes, and general usage statistics and/or user behavior. In some cases, very detailed data are reported like individual window metrics, counts of used features, and individual function timings.”

There are three main methods to gather user data and they will be defined as such:

1. Asking users: when developers explicitly ask users for feedback through surveys or similar.
2. Opt-in telemetry: when users explicitly enable telemetry, meaning telemetry is disabled by default.
3. Opt-out telemetry: when users explicitly disable telemetry, meaning telemetry is enabled by default.

Problems With Opt-in Telemetry and Asking Users

There are several problems with opt-in telemetry and asking users: they are prone to inaccurate and misleading data, they’re undiscoverable for less technical users, and if they are discoverable, then they are usually displayed in such a way they aggressively shift users’ focus.

Prone to Inaccurate Data

The main (and harmful) problem with asking users and opt-in telemetry is inaccurate and biased data provided by enthusiasts.

I’m going to take “gnome-info-collect: What we learned” as an example. Recently, GNOME conducted a research to gather data from their users. Users were encouraged to participate, but the research was entirely opt-in. They needed to install a package named “gnome-info-collect” and run it. With all the data collected by GNOME, we got the following result for distributions used:

Distro	Number of responses	% of responses
Fedora	1376	54.69%
Arch	469	18.64%
Ubuntu	267	10.61%
Manjaro	140	5.56%
Other	78	3.10%
EndeavourOS	66	2.62%
Debian	44	1.75%
openSUSE	38	1.51%
Pop!	38	1.51%
Total	2516	100.00%

Notice that Fedora Linux users represent the highest amount of participants — literally more than half of the vote count, followed by Arch Linux and Ubuntu. However the consensus seems to be that Ubuntu is the most used Linux distribution (excluding Android). Ubuntu Desktop (the main Ubuntu in the lineup) ships with GNOME, just like Fedora Workstation, which means that the majority of GNOME users are actually Ubuntu users, not Fedora Linux users (or even Arch Linux users). In this case, Fedora Linux and Arch Linux users would be considered as vocal minorities, as there are more participants than Ubuntu’s, despite having less overall users.

Vocal minorities and enthusiasts are not representative of the entire userbase, especially in the context of software designed for less technical users. These data can be harmful, as they are often inaccurate and unrepresentative. Especially in user-interface (UI) and user-experience (UX) research, these data can skew the opinions and conclusions of developers and designers, which could exclusively benefit vocal minorities but harm their target audience(s).

This could also make it difficult to judge which statistics are accurate or even form a moderate conclusion, because we can’t tell which one is representative, unless there is a consensus on the matter.

In the above example, since there is a consensus that Ubuntu is the most used distribution, we have a reference that the data provided is not representative. However, in topics that lack consensus, our conclusions may be misguided.

Undiscoverable for Less Technical Users

Asking users and opt-in telemetry may be undiscoverable to users, as they must be made aware of said method(s) in some way.

For opt-in telemetry, they are often obscured that users will rarely discover them. Once again, this is typically enabled by vocal minorities and enthusiasts, like myself, which may result in biased results. For example, on Mozilla Thunderbird, to enable telemetry, we go through the hamburger menu → Settings → Privacy & Security, then scroll all the way down to “Thunderbird Data Collection and Use”. I only discovered it because I felt like exploring in the Settings.

As for asking users, they need a way to be reached out. In GNOME’s telemetry, I quote:

The people who provided their data with gnome-info-collect were primarily recruited via GNOME’s media channels, including Discourse and Twitter. This means that the data we collected was on a fairly particular subset of GNOME’s users: namely, people who follow our social media channels, are interested enough to respond to our call for help […]

Typically, enthusiasts will participate in surveys and/or opt into telemetry, as they’re active in chat rooms, follow the project on social media and/or blog, participate in forums, etc. However, there won’t be an easy way to reach out to less technical users without implementing annoyances. This makes it very difficult to gain accurate data of the entire userbase and making it representative.

Aggressively Shifting Focus to Ask for Feedback

A common tactic to ask users for feedback and the most “effective” one I know of is by displaying popups, banners, notifications, or other forms of behavior that will shift users’ focus.

For example, LibreOffice sometimes asks for feedback using a banner:

If you’ve ever seen this banner on LibreOffice or other apps, then you have probably clicked the close button, which is a totally normal thing to do. When you open LibreOffice, you don’t open it to participate in surveys; you typically open it to actually use LibreOffice.

When you’re in the middle of using an app and are prompted to shift your focus onto something that is completely unrelated to your intended goal, then you will likely do everything you can to get rid of it. If there is a “do not show again” button, then you will likely press that alongside, so it doesn’t annoy you again.

There are some exceptions, though. Some might want to participate if they have the time. However, this brings back to data that may be inaccurate and unrepresentative.

Time-consuming

Many users may not have the time or mood to participate in surveys for whatever reason, myself included. As pointed out previously, when you open an app, you open it to use it, not to participate in a project. I maintain and contribute to several projects, play video games with friends, spend time with family, etc. Many of us have jobs and chores to do additionally. We may not always feel like spending time filling up a survey, as we’re already exhausted and have very little time to spare. At that time, I was creating a resumé.

At the same time, personally, even if it takes 5 minutes, I prefer to participate properly, in the right mood; provide useful information and answer questions correctly, but this kind of mood rarely happens to me, so I rarely participate in surveys.

Opt-out Telemetry

Opt-out telemetry, despite its controversies, addresses those problems by including everybody by default, including less technical users, as opposed to opt-in telemetry and asking users. This means that less technical users’ data have more potential to influence the data into results that projects can use as a reference and form educated conclusions, and tailor their software around their target audience(s) and the majority of the userbase.

In addition, since opt-out telemetry is enabled by default, there is the benefit that there will be more participants as a result. Of course, users can always opt-out if they want, but at least these data get us much closer to something that is representative and accurate.

Conclusion

Opt-in telemetry and asking users for feedback may result in data that is unrepresentative and inaccurate, which may cause the collected data to be misleading and lead to misguided conclusions and incorrect decisions. Furthermore, these methods may be unreachable to less technical users, as they don’t follow the projects’ social media, forums, chat, etc. Asking users for feedback can also be obnoxious, because they are designed to shift users’ focus to something that they did not anticipate, which can be distracting. They can also be time-consuming, given the circumstances we may live in.

This is not to say that asking users and opt-in telemetry are a bad thing. I personally support asking users specifically for feature proposals — in fact, this is what issue trackers are for. However, I do not support asking users for general feedback, because general feedback struggle with representativeness.

In my opinion, inaccurate data are more harmful than no data.

A common problem I notice on the internet is the lack of awareness of many problems in the world. Of which, there are times when someone may be aware of the problem, but not to what extent. One of the common problems is a lack of effort to raise awareness and protect marginalized groups, particularly in the free and open-source software (FOSS) community.

In this article, we’re going to go over the problems associated with not raising awareness and protecting marginalized groups. I’ll also go over the “keep politics out of FOSS” demand from many free software activists who oppose raising awareness.

What Is a “Marginalized Group”?

Before I go over the importance of protecting marginalized groups, allow me to explain the meaning of a marginalized group. “Marginalized” means being excluded in bad faith¹ or being viewed as an insignificant. A marginalized group is a group of people that is excluded in bad faith and/or treated as a less important group. Some examples of marginalized groups include but are not limited to:

• sexuality and gender
• disability
• elderly or young (age)
• immigrant status
• religion
• socioeconomic status

For a list of types of discrimination, see the Discrimination sidebar on Wikipedia.

Lack of Awareness May Result in Not Providing Necessary Accommodations

There are many underrepresented groups that are unfortunately easily forgotten, not taken into consideration, never consulted, and/or not prioritized. This may lead to not providing any accommodations until developers are made aware. One group I can think of is people with disabilities, such as blind people.

We all know that people with disabilities exist, but when we have many things to worry about, it may become easy to forget about them. For example, my website’s accessibility (usability for people with disabilities) used to be far from ideal:

• Media (images/videos) lacked descriptions for screen readers or unstable internet connection.
• Many decorative images and elements weren’t ignored by screen readers. This means that the screen reader user would have their time wasted on the screen reader explaining unnecessary information.
• Some areas were low on contrast, like code blocks. This would make it difficult for vision-impaired readers to read the content.
• A “Skip to main content” button was missing. This button is useful for keyboard users that don’t want to go through the navigation bar.
• There weren’t any accommodations for people who rely on reduced motion. Buttons were animating no matter the preference.

All these accommodations happened later, because I didn’t take them into consideration when I made the website initially.

When I gained more experience with web development and chatted with people with disabilities, that’s when I was made aware of it. I researched a lot about accessibility and slowly started accommodating more people. I trained myself to write better descriptions for media and faster.

This isn’t only from a maintainer/developer perspective, but from a user perspective as well. Have you ever wondered why buttons on GNOME are large? Not only is it practical for touchscreen users, but it’s also useful for people whose hands constantly fidget, like mine. Many people struggle with clicking accurately, so having large(r) buttons helps us click the right buttons without having to put excessive effort into moving our mice. That’s also one reason why GNOME removed status icons a while back (under “4. Accessible click targets”).

Many users believe that some visual designs exist just to copy from others, look unique just for the sake of uniqueness, etc. However, many design elements are strictly focused on people who struggle with certain cues, so it’s important that users are also made aware of these accommodations, and hopefully sympathize with these decisions.

Contributors Are Driven Away by Harassment

There are many efforts put into protecting and raising awareness of marginalized groups in FOSS, but, in my opinion, it’s still not enough.

A good example of an organization that protects marginalized groups is GNOME. GNOME even goes as much as making a statement about putting marginalized people’s safety in priority on its code of conduct:

The GNOME community prioritizes marginalized people’s safety over privileged people’s comfort

[…]

Outreach and diversity efforts directed at underrepresented groups are permitted under the code of conduct. For example, a social event for women would not be classified as being outside the Code of Conduct under this provision.

…but would GNOME be a good example? Since GNOME is a huge player in the FOSS space and while it protects marginalized groups, it is also one of the largest targets for malicious actors. As such, these actors may harass marginalized people outside of GNOME spaces.

During my course of interactions, I’ve chatted with a few victims who stopped involving with GNOME because of the constant harassment (outside of GNOME). One of them shared the following to me:

Obviously, the GNOME Foundation does everything it can within its resources to protect marginalized groups, but even then, the weight of attacks may unfortunately outweigh GNOME’s efforts. It really shows that, despite putting a lot of effort to increase awareness and protect marginalized groups, it may still not be enough. It doesn’t help that the FOSS ecosystem lacks contributors (code, documentation, moderation, etc.). Pushing a person away one at a time only worsens the situation as a whole.

Emotionally Draining

With the lack of awareness among tons of people, it can be very difficult to defend or explain themselves in environments that cannot relate with or understand them.

Furthermore, some even go as much as understating. Understating means to make a problem look like it’s little of importance. For example, a disabled person might say that they can’t use Linux, as it lacks tons of accessibility accommodations. Someone else could reply with “Oh come on, just take these 15 [complicated] steps and everything should work fine. You’re just being oversensitive.” Since the non-disabled person either refuses or is unable to sympathize, they might resort to understating. Even worse, many people with disabilities/disorders may pretend to be “normal”, [1] [2] when they’re in an environment that they wouldn’t fit if they expressed themselves, or they’re in an environment that doesn’t actively showcase that they’re protected.

If you’ve done customer service or technical support, you probably have gotten really annoyed to continuously repeat yourself to each person on a day-to-day basis. You’ve also probably stumbled upon the article “Don’t ask to ask, just ask”, as the article explains a really common behavior when requesting for support. Or, if you haven’t done customer service or technical support, then there’s probably going to be a few things you continuously repeat to people, perhaps even to your parents when they don’t know how to use their phone.

I’m already exhausted with explaining over 100 times to people that Flatpak isn’t some corporate overlord that wants to take over the Linux desktop. I can’t imagine how heartbreaking it may be for a marginalized person to continuously repeat themselves about their identities, disabilities, struggles or being a target for bad actors.

“Keep Politics Out of FOSS”

The most common demand we hear from opponents of these initiatives are “keep politics out of FOSS”. By “politics”, they mean “any kind of politics that is out of scope of the free software movement”, which means that FOSS should only be about promoting open and redistributable code, not alongside other activism.

The main problem with solely focusing on the “open and redistributable code” element is that we’re making the entirety of FOSS inaccessible for everyone else, including potential developers. FOSS is not only about open and redistributable code; it’s also about software development, because without software development, there isn’t software; without software, there isn’t FOSS.

Remember: software development is much more than just about maintaining code; it’s about designing, marketing, documenting, and testing as well. Then, these processes consist of designers, marketers, documenters, and quality assurance testers, respectively.

If we keep politics out of FOSS, then we’d literally be excluding all the aforementioned groups, excluding developers and maintainers; we’d be excluding tons of potential code contributors as well.

The only reason you and I are using Linux in the first place is because there were initiatives that prioritized approachability, which are politically outside of the scope of the “open and redistributable code” philosophy. If it weren’t for these initiatives and internal activism, then we wouldn’t be using FOSS at all, and FOSS would’ve been long gone. Either that, or we wouldn’t be on Linux because it would’ve been too difficult or inconvenient.

Each project has goals they want to reach, with one or multiple target audiences. So now, not only do we have the group of people within the software development space, we have our target audience(s) to take into consideration as well; we need to make it approachable for them. For example, one of GNOME’s goals is to be as inclusive as possible for contributors, especially for marginalized people and underrepresented groups. As such, GNOME does whatever it can (within reason) to make it appealing for that target audience; as a result, it protects marginalized people.

“Keep[ing] politics out of FOSS” is something that is always bound to fail, as FOSS is by nature political beyond open and redistributable code. We need groups from different backgrounds and skills to make FOSS as appealing, useful, and work as best as it can. We need marketers to make the software deliver value to their target audience(s). We need designers to make it look well for their target audience(s). We need documenters to provide self-service and make the development experience as easy as possible. We need testers to eliminate as many bugs as possible. Without politics, there is no FOSS.

One particular person I admire is a 16-year-old trans girl who is a member of the GNOME Foundation. She has made significant contributions to GNOME and implemented a feature that I have wanted for a long time. Unfortunately, I can’t go into detail because she’s not comfortable revealing her age and name together publicly, as she doesn’t want to be discriminated against and harassed outside of GNOME spaces — rightfully so. She probably wouldn’t be here if she didn’t feel protected in her environment.

I suggest reading “Politics in your FOSS project? It’s more likely than you think!” by Samsai. Their article goes into detail on this topic.

Conclusion

Unfortunately, discrimination and harassment are still common in the FOSS community. Even when large communities make a real effort to protect them, they continue to be harassed in external spaces, such as personal websites, forums, public groups, etc. It gets even worse when marginalized people are more susceptible to harassment while also being emotionally burned out by having to constantly speak out about their situation, whether because of a disability, gender/sexuality, ethnicity, or other factors.

I would like to thank Oro (trans) and Ember (physical disability) for carefully reviewing this article. Oro has been harassed by some communities because of their gender. As a friend, I think it’s really important to raise awareness about protecting marginalized groups so that we can provide a safe space for them to express their identities.

Footnotes

Recently, the article “Developers are lazy, thus Flatpak”, by Martijn Braam, was published to criticize a few things regarding Flatpak. I want to go over the article and address some points that were raised.

While Martijn, the author, contrasted Flatpak with Alpine Linux, I’m going to be contrasting Flatpak with popular Linux distributions, as, to me, it makes sense to contrast Flatpak with some of the most used distributions.

I recommend reading his article before my response, as I won’t be replying to every point raised.

“Flatpak is a distribution”

While the developers like to pretend real hard that Flatpak is not a distribution, it’s still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it’s still a distribution you need to target. Instead of providing seperate [sic] packages with a package manager it provides a runtime that comes with a bunch of dependencies. Conveniently it also provides multiple runtimes to make sure there’s not actually a single base to work on. Because sometimes you need Gnome libraries, sometimes you need KDE libraries. Since there’s no package manager those will be in seperate [sic] runtimes.

I’m not really sure who denies that Flatpak is a distribution, but I’m certainly not one of them. If anything, this seems to be a really good thing to me, because we’re bundling a distribution and deploying it to users’ systems, meaning that they’re getting the exact same builds that we, the developers, tested against. It makes it even easier for us to troubleshoot, because the environment is near-identical.

To quote from Flatpak’s documentation: “Flatpak is a framework for distributing desktop applications across various Linux distributions.” Even Flatpak agrees that it’s a distribution.

“No built in package manager”

If you need a dependency that’s not in the runtime there’s no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you’re also the maintainer of all the dependencies in this semi-distribution you’re shipping under the disguise of an application.

Separating every dependency would be really inconvenient, just like managing graphical apps in a Linux distribution. If, for example, a flatpak named XYZ needs 10 dependencies, whereby one of the dependencies changes the version that the developers of the XYZ flatpak have not tested, then it could lead to bugs or even breakages that would make it really difficult for developers to trace back, as they would need to frequently contact each packager and figure out together. So, as mentioned by the author, the solution is to let the developers bundle everything, as they test their apps against an environment that is easier to understand.

Separating all dependencies is easier for smaller programs and dependencies, as they have a small volume of dependencies, and thus are not as difficult for troubleshooting. However, Flatpak targets graphical apps, which are typically large and sophisticated and need a model that can scale well. In this case, letting developers manage the dependencies is a better approach, as it’s easier to maintain and troubleshoot.¹

And one thing is for sure, I don’t trust application developers to maintain dependencies.

That’s completely fair, as you’re entitled to your own opinion. Likewise, I don’t trust the worryingly large amount of non-programmers/developers that package dependencies in larger distributions, especially when they have no real world experience in developing apps. Furthermore, I trust even less the package managers that allow dependencies to self-destruct in case something goes wrong.

This gets really nuts by looking at some software that deals with multimedia. Lets [sic] look at the Audacity flatpak. It builds as dependency:

• wxwidgets
• ffmpeg
• sqlite
• chrpath
• portaudio
• portmidi

So lets [sic] look at how well dependencies are managed here. Since we’re now almost exactly half a year into 2023 I’ll look at the updates for the last 6 months and compare it to the same dependencies in Alpine Linux.

• audacity has been updated 4 times in the flatpak. It has been updated 5 times on Alpine.
• ffmpeg has been updated to 6.0 in both the flatpak and Alpine, but the ffmpeg package has had 9 updates because if [sic] codecs that have been updated.
• sqlite hasn’t been updated in the flatpak and has been updated 4 times in Alpine
• wxwidgets hasn’t been updated in the flatpak and has been updated 2 times in Alpine
• chrpath hasn’t had updates
• portaudio hasn’t had updates in flatpak and Alpine.
• portmidi hasn’t had updates

This is just a random package I picked and it already had a lot more maintainance of the dependencies than the flatpak has. It most likely doesn’t scale to have all developers keep track of all the dependencies of all their software.

The main issue here is that Audacity has many technical limitations. To name one, in Audacity’s source code, it’s documented that “Audacity on Linux uses vanilla version of wxWidgets, we require that version 3.1.3 is used. This version is not available in most of the distributions.”

This is why wxWidgets in the Audacity flatpak wasn’t updated. If they updated to major versions, then they might have ran into issues. Alpine Linux, on the other hand, packages wxWidgets version 3.2.2.1, which, as seen above, is outside of the “required” version.

Even then, in this case, the amount of updates doesn’t signify which is better maintained, as context absolutely matters. It is best to consult the maintainer of the flatpak about their decision, rather than cherry picking and misinforming yourself without doing thorough investigations.

“The idea of isolation”

This whole section is criticizing GNOME Software, not Flatpak itself. GNOME Software is a frontend that decides how they should display flatpaks to users. If the GNOME Software developers wanted, they could display a dialog that warns the user when they try to install the app. In this case, they went against it and put it under a separate button. In my opinion, it is really unfair to blame a backend utility when the frontend does it “wrong”.²

“So what about traditional distributions”

I’ve heard many argument for Flatpaks by users and developers but in the end I can’t really say the pros outweigh the cons.

I think it’s very important that developers do not have the permissions to push whatever code they want to everyone under the disguise of a secure system. And that’s my opinion as a software developer.

Software packaged by distributions has at least some degree of scrutiny and it often results in at least making sure build flags are set to disable user tracking and such features.

As user u/natermer explains really well on Reddit: “the reviewing and security benefits of distribution packaging is [sic] heavily overstated by many people defending it. Only a small number of high profile packages ever receive serious security scrutiny. For the most part the packaging authors put in just enough to [sic] work to get the software to build correctly and the dependencies to install without breaking anything and then it is up to the end users to report on any problems that crop up. Which means that the guarantees are not really much better then [sic] with stuff like “pip”.”

In the Audacity example discussed above, I mentioned that Alpine Linux packages wxWidgets version 3.2.2.1 and Audacity, which Audacity has explicitly stated to use 3.1.3. This is a good example of the packaging authors putting in just enough work to get the software to build. The app launching isn’t enough to conclude that it works well. While the author’s point was regarding security, I think that scrutiny beyond security is equally as important and should be mentioned.

Furthermore, this isn’t only about scrutiny, but also maintenance, or the lack thereof. Let’s look at the amount of packages that some popular distributions contain in their repositories. As of writing this article:

• Debian has over 1,200 orphaned packages (no maintainer), many of which are over 1,000 days!
• Fedora Linux has over 800 orphaned packages (no maintainer).
• Arch Linux has over 400 packages flagged as outdated.

So, while the author is concerned that developers will “mishandle” dependencies with Flatpak, we observe that the more worrying bit is the amount of unmaintained packages on the distributions you run on your system; packages that are installed on your host. So you either choose a mishandled package on your host, or a mishandled dependency inside a container. I will happily take the latter.

I also believe software in general is better if it’s made with the expectation that it will run outside of Flatpak. It’s not that hard to make sure you don’t depend on bleeding edge versions of libraries while that’s not needed. It’s not that hard to have optional dependencies in software. It’s not that hard to actually follow XDG specifications instead of hardcoding paths.

I’ve written “Traditional Packaging is not Suitable for Modern Applications” which goes in depth with the problems of the lack of robust dependency management. To summarize, with traditional packaging systems, developers cannot cherry pick dependencies, and distributions cannot provide consistent experiences and environments if they’re not making use of the same containers or similar.

Audacity, as an example, on a traditional packaging system, if the distribution chooses to use the latest version of wxWidgets, 3.2.2.1, and the distribution ships that version, then the packagers cannot cherry pick 3.1.3 or any other version, otherwise that version will conflict with the existing version.

This isn’t only regarding versioning, but it goes as far as applying custom patches. For example, as taken from my article I linked, OBS Studio requires a few patches for ffmpeg to neatly integrate with OBS Studio. This, again, cannot be done if the distribution ships an unpatched ffmpeg or one that doesn’t have the patches OBS Studio requires to work properly, otherwise they have to find all sorts of workarounds (refer to my article).

Another problem that traditional packaging systems cannot solve is providing a consistent and predictable environment. For example, Bottles is a “fragile” piece of software, because it needs an environment for Wine and other utilities to run in secure, contained and predictable environments. I’ve written a long comment that explains why supporting traditional packaging systems is a burden for us, while being infeasible at best.

Steam, another example, uses steam-runtime-tools, which uses bubblewrap, a utility that originated from Flatpak, to contain and isolate games. Even, though, Steam is available and “supported” on many distributions, they all originate from the same archive, which means that they’re all the same binaries and thus are somewhat consistent, just like Flatpak.

As Linus Torvalds said, “[…] I guarantee you Valve will not make 15 different binaries […]” — In reality, developers who have other things to worry about cannot spend their time to build their software 5 times for 5 different Linux distributions and continuously support them. To be fair, “5” is an understatement. Instead, they want one binary, and continuously and thoroughly test that binary and ship it to users.

“But packaging for distributions is hard”

That’s the best thing! Developers are not supposed to be the ones packaging software so it’s not hard at all. It’s not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in. I have software that’s packaged in Alpine Linux, ALT Linux, Archlinux AUR, Debian, Devuan, Fedora, Gentoo, Kali, LiGurOS, Nix, OpenMandriva, postmarketOS, Raspbian, Rosa, Trisquel, Ubuntu and Void. I did not have to package most of this.

The most I notice from other distributions packaging my software is patches from maintainers that improve the software, usually in dealing with some edge case I forgot with a hardcoded path somewhere.

The most time I’ve ever spent on distribution packaging is actually the few pieces of software I’ve managed to push to Flathub. Dealing with differences between distributions is easy, dealing with differences between runing [sic] inside and outside Flatpak is hard.

Masochism aside, as the author wrote in the beginning of the article, “[s]adly there’s reality”. That reality is that developers do not and literally cannot deal with all the burden that distributions cause. They want something that is easy for them to maintain, while having the control to bundle everything they want, and however they see fit, because developers know how their programs work the best. They can test their apps in environments and ship the same environments to users.

If the distribution does not put an effort to make it easy for developers to package, test and ship their apps to users, then the distribution has failed to appeal the majority of developers. The decreased difficulty that Flatpak and Flathub offer is precisely why many distributions are starting to include and use Flathub by default, like Steam OS; it’s why GNOME and KDE have been focusing on Flatpak as the primary distribution method; and it’s also why Flatpak and Flathub have grown in popularity really quickly.

“But Flatpaks are easier for end users”

A second issue I’ve had on my Pinebook Pro is that it has a 64GB rootfs. Using too many flatpaks is just very wasteful of space. In theory you have a runtime that has your major dependencies and then a few Megabytes of stuff in your application flatpak. In practice I nearly have an [sic] unique platform per flatpak installed because the flatpaks depend on different versions of that platform or just on different platforms.

While I have a 256 GB SSD, I probably have more graphical apps than the average user, because I test and contribute to several apps. I would go as much as saying that my Flatpak setup is cursed, but I digress.

Many of the apps use different runtimes and different versions of runtimes. I believe that I fall into the “I nearly have a unique platform per flatpak installed” category, although I believe his statement was hyperbolic.

First, we’ll check the amount of storage all flatpaks take. I’ll be using flatpak-dedup-checker to measure the storage usage:

1
2
3
4
5
$ ./flatpak-dedup-checker --user
Directories:                /var/home/TheEvilSkeleton/.local/share/flatpak/{runtime,app}
Size without deduplication: 89.31 GB
Size with deduplication:    37.73 GB (42% of 89.31 GB)
Size with compression:      27.66 GB (30% of 89.31 GB. 73% of 37.73 GB)

We notice that all flatpaks, without compression, take 37.73 GB in total. Let’s look at how many apps I have installed:

1
2
$ flatpak list --app --user | wc -l
173

173 graphical apps — including major browsers, such as Firefox, LibreWolf, Tor Browser, Chromium, ungoogled-chromium, Google Chrome, Brave, Microsoft Edge, and Epiphany. If you’re curious, feel free to look at all my installed apps:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
$ flatpak list --app --user
Name                                         Application ID                                                Version                                Branch                    Origin
Dialect                                      app.drey.Dialect                                              2.1.1                                  stable                    flathub
Elastic                                      app.drey.Elastic                                              0.1.3                                  stable                    flathub
Cambalache                                   ar.xjuan.Cambalache                                           0.10.3                                 stable                    flathub
Valent                                       ca.andyholmes.Valent                                                                                 master                    valent-origin
Dconf Editor                                 ca.desrt.dconf-editor                                         43.0                                   stable                    flathub
Decoder                                      com.belmoussaoui.Decoder                                      0.3.3                                  stable                    flathub
ASHPD Demo                                   com.belmoussaoui.ashpd.demo                                   0.3.0                                  stable                    flathub
Bitwarden                                    com.bitwarden.desktop                                         2023.5.0                               stable                    flathub
Boxy SVG                                     com.boxy_svg.BoxySVG                                          3.96.0                                 stable                    flathub
Brave Browser                                com.brave.Browser                                             1.52.117                               stable                    flathub
Tally for Plausible                          com.cassidyjames.plausible                                    3.0.1                                  stable                    flathub
Discord Canary                               com.discordapp.DiscordCanary                                  0.0.156                                beta                      flathub-beta
Mindustry                                    com.github.Anuken.Mindustry                                   144.3                                  stable                    flathub
ungoogled-chromium                           com.github.Eloston.UngoogledChromium                          113.0.5672.126                         stable                    flathub
Gradience                                    com.github.GradienceTeam.Gradience                            0.4.1                                  stable                    flathub
Desktop Files Creator                        com.github.alexkdeveloper.desktop-files-creator               1.2.2                                  stable                    flathub
Eyedropper                                   com.github.finefindus.eyedropper                              0.6.0                                  stable                    flathub
Rnote                                        com.github.flxzt.rnote                                        0.6.0                                  stable                    flathub
Wike                                         com.github.hugolabe.Wike                                      2.0.1                                  stable                    flathub
Text Pieces                                  com.github.liferooter.textpieces                              3.4.1                                  stable                    flathub
Tor Browser Launcher                         com.github.micahflee.torbrowser-launcher                      0.3.6                                  stable                    flathub
G4Music                                      com.github.neithern.g4music                                   1.13                                   stable                    flathub
Czkawka                                      com.github.qarmin.czkawka                                     5.1.0                                  stable                    flathub
Clapper                                      com.github.rafostar.Clapper                                   0.5.2                                  stable                    flathub
Logisim-evolution                            com.github.reds.LogisimEvolution                              3.8.0                                  stable                    flathub
Avvie                                        com.github.taiko2k.avvie                                      2.3                                    stable                    flathub
Flatseal                                     com.github.tchx84.Flatseal                                    2.0.1                                  stable                    flathub
Frog                                         com.github.tenderowl.frog                                     1.3.0                                  stable                    flathub
Video Downloader                             com.github.unrud.VideoDownloader                              0.12.4                                 stable                    flathub
Easy Effects                                 com.github.wwmm.easyeffects                                   7.0.4                                  stable                    flathub
NewsFlash                                    com.gitlab.newsflash                                          2.3.0                                  stable                    flathub
Google Chrome                                com.google.Chrome                                             113.0.5672.126-1                       stable                    flathub
Inochi Creator                               com.inochi2d.inochi-creator                                   0.8.0                                  stable                    flathub
qView                                        com.interversehq.qView                                        5.0                                    stable                    flathub
GtkStressTesting                             com.leinardi.gst                                              0.7.5                                  stable                    flathub
Forge Sparks                                 com.mardojai.ForgeSparks                                      0.1.1                                  stable                    flathub
Extension Manager                            com.mattjakeman.ExtensionManager                              0.4.0                                  stable                    flathub
Microsoft Edge                               com.microsoft.Edge                                            114.0.1823.37-1                        stable                    flathub
OBS Studio                                   com.obsproject.Studio                                         29.1.2                                 stable                    flathub
Share Preview                                com.rafaelmardojai.SharePreview                               0.3.0                                  stable                    flathub
Black Box                                    com.raggesilver.BlackBox                                      0.13.2                                 stable                    flathub
Geopard                                      com.ranfdev.Geopard                                           1.4.0                                  stable                    flathub
Transmission                                 com.transmissionbt.Transmission                               4.0.3                                  stable                    flathub
Bottles                                      com.usebottles.bottles                                        51.6                                   master                    bottles-origin
Bottles                                      com.usebottles.bottles                                        51.6                                   stable                    flathub
Steam                                        com.valvesoftware.Steam                                       1.0.0.75                               stable                    flathub
Visual Studio Code                           com.visualstudio.code                                         1.78.2-1683731010                      stable                    flathub
Fragments                                    de.haeckerfelix.Fragments                                     2.1.1                                  stable                    flathub
Tubefeeder                                   de.schmidhuberj.tubefeeder                                    v1.9.4                                 master                    tubefeeder-origin
Tubefeeder                                   de.schmidhuberj.tubefeeder                                    v1.9.6                                 stable                    flathub
Tuba                                         dev.geopjr.Tuba                                               0.3.2                                  stable                    flathub
Forecast                                     dev.salaniLeo.forecast                                        0.1.0                                  stable                    flathub
HandBrake                                    fr.handbrake.ghb                                              1.6.1                                  stable                    flathub
Metadata Cleaner                             fr.romainvigier.MetadataCleaner                               2.5.2                                  stable                    flathub
Cartridges                                   hu.kramo.Cartridges                                           1.5.4                                  stable                    flathub
Element                                      im.riot.Riot                                                  1.11.31                                stable                    flathub
Cinny                                        in.cinny.Cinny                                                2.2.6                                  stable                    flathub
Komikku                                      info.febvre.Komikku                                           1.21.1                                 stable                    flathub
Amberol                                      io.bassi.Amberol                                              0.10.3                                 stable                    flathub
Bavarder                                     io.github.Bavarder.Bavarder                                   0.2.3                                  stable                    flathub
AdwSteamGtk                                  io.github.Foldex.AdwSteamGtk                                  0.6.0                                  stable                    flathub
Youtube Downloader Plus                      io.github.aandrew_me.ytdn                                     3.14.0                                 stable                    flathub
Epic Asset Manager                           io.github.achetagames.epic_asset_manager                      3.8.4                                  stable                    flathub
GPU-Viewer                                   io.github.arunsivaramanneo.GPUViewer                          2.26                                   stable                    flathub
Celluloid                                    io.github.celluloid_player.Celluloid                          0.25                                   stable                    flathub
Escambo                                      io.github.cleomenezesjr.Escambo                               0.1.1                                  stable                    flathub
PinApp                                       io.github.fabrialberio.pinapp                                 1.1.7                                  stable                    flathub
Monitorets                                   io.github.jorchube.monitorets                                 0.10.0                                 stable                    flathub
AppImage Pool                                io.github.prateekmedia.appimagepool                           5.1.0                                  stable                    flathub
Kooha                                        io.github.seadve.Kooha                                        2.2.3                                  stable                    flathub
Mousai                                       io.github.seadve.Mousai                                       0.7.5                                  stable                    flathub
WebCord                                      io.github.spacingbat3.webcord                                 4.2.0                                  stable                    flathub
Converter                                    io.gitlab.adhami3310.Converter                                1.6.1                                  stable                    flathub
Sudoku Solver                                io.gitlab.cyberphantom52.sudoku_solver                        1.0.1                                  stable                    flathub
Letterpress                                  io.gitlab.gregorni.ASCIIImages                                1.3.0                                  stable                    flathub
Calligraphy                                  io.gitlab.gregorni.Calligraphy                                1.0.0                                  stable                    flathub
LibreWolf                                    io.gitlab.librewolf-community                                 113.0.2-1                              stable                    flathub
Upscaler                                     io.gitlab.theevilskeleton.Upscaler                                                                   master                    upscaler3-origin
Upscaler                                     io.gitlab.theevilskeleton.Upscaler                            1.1.2                                  stable                    flathub
Upscaler                                     io.gitlab.theevilskeleton.Upscaler                            1.1.2                                  test                      upscaler1-origin
Devel                                        io.gitlab.theevilskeleton.Upscaler.Devel                                                             master                    devel-origin
Dev Toolbox                                  me.iepure.devtoolbox                                          1.0.2                                  stable                    flathub
Passes                                       me.sanchezrodriguez.passes                                    0.7                                    stable                    flathub
Lutris                                       net.lutris.Lutris                                             0.5.13                                 stable                    flathub
Mullvad Browser                              net.mullvad.MullvadBrowser                                    102.9.0esr-12.0-2-build1               stable                    flathub
Poedit                                       net.poedit.Poedit                                             3.3.1                                  stable                    flathub
RPCS3                                        net.rpcs3.RPCS3                                               0.0.28-1-33558d14                      stable                    flathub
Live Captions                                net.sapples.LiveCaptions                                      0.4.0                                  stable                    flathub
Color Picker                                 nl.hjdskes.gcolor3                                            2.4.0                                  stable                    flathub
Audacity                                     org.audacityteam.Audacity                                     3.3.2                                  stable                    flathub
Chromium Web Browser                         org.chromium.Chromium                                         114.0.5735.90                          stable                    flathub
Chromium application base                    org.chromium.Chromium.BaseApp                                                                        21.08                     flathub
Electron2 application base                   org.electronjs.Electron2.BaseApp                                                                     21.08                     flathub
Electron2 application base                   org.electronjs.Electron2.BaseApp                                                                     22.08                     flathub
Flatpak External Data Checker                org.flathub.flatpak-external-data-checker                                                            stable                    flathub
Builder                                      org.flatpak.Builder                                                                                  stable                    flathub
Piper                                        org.freedesktop.Piper                                         0.7                                    stable                    flathub
VulkanInfo                                   org.freedesktop.Platform.VulkanInfo                                                                  22.08                     flathub
appstream-glib                               org.freedesktop.appstream-glib                                0.8.1                                  stable                    flathub
Feeds                                        org.gabmus.gfeeds                                             2.2.0                                  stable                    flathub
Giara                                        org.gabmus.giara                                              1.1.0                                  stable                    flathub
Zola                                         org.getzola.zola                                              0.17.2                                 stable                    flathub
GNU Image Manipulation Program               org.gimp.GIMP                                                 2.99.14                                beta                      flathub-beta
GNU Image Manipulation Program               org.gimp.GIMP                                                 2.10.34                                master                    gnome-nightly
GNU Image Manipulation Program               org.gimp.GIMP                                                 2.10.34                                stable                    flathub
Adwaita Demo                                 org.gnome.Adwaita1.Demo                                       1.4.alpha                              master                    gnome-nightly
Boxes                                        org.gnome.Boxes                                               44.2                                   stable                    flathub
Builder                                      org.gnome.Builder                                             44.2                                   stable                    flathub
Calculator                                   org.gnome.Calculator                                          44.0                                   stable                    flathub
Calendar                                     org.gnome.Calendar                                            44.0                                   stable                    flathub
Contacts                                     org.gnome.Contacts                                            44.0                                   stable                    flathub
Devhelp                                      org.gnome.Devhelp                                             43.0                                   stable                    flathub
Web                                          org.gnome.Epiphany                                            44.3                                   stable                    flathub
File Roller                                  org.gnome.FileRoller                                          43.0                                   stable                    flathub
Firmware                                     org.gnome.Firmware                                            43.2                                   stable                    flathub
Fractal                                      org.gnome.Fractal.Devel                                       5~beta1-c3d77b7                        master                    gnome-nightly
Geary                                        org.gnome.Geary                                               43.0                                   stable                    flathub
Glade                                        org.gnome.Glade                                               3.40.0                                 stable                    flathub
Lollypop                                     org.gnome.Lollypop                                            1.4.37                                 stable                    flathub
Loupe                                        org.gnome.Loupe                                               44.3                                   stable                    flathub
Maps                                         org.gnome.Maps                                                44.2                                   stable                    flathub
Files                                        org.gnome.NautilusDevel                                       44.1                                   master                    gnome-nightly
Notes                                        org.gnome.Notes                                               40.1                                   stable                    flathub
Document Scanner                             org.gnome.SimpleScan                                          44.0                                   stable                    flathub
Text Editor                                  org.gnome.TextEditor                                          44.0                                   stable                    flathub
Endeavour                                    org.gnome.Todo                                                43.0                                   stable                    flathub
Videos                                       org.gnome.Totem                                               43.0                                   stable                    flathub
Weather                                      org.gnome.Weather                                             44.0                                   stable                    flathub
Pika Backup                                  org.gnome.World.PikaBackup                                    0.6.1                                  stable                    flathub
Secrets                                      org.gnome.World.Secrets                                       7.3                                    stable                    flathub
Clocks                                       org.gnome.clocks                                              44.0                                   stable                    flathub
App Icon Preview                             org.gnome.design.AppIconPreview                               3.3.0                                  stable                    flathub
Contrast                                     org.gnome.design.Contrast                                     0.0.8                                  stable                    flathub
Emblem                                       org.gnome.design.Emblem                                       1.2.0                                  stable                    flathub
Icon Library                                 org.gnome.design.IconLibrary                                  0.0.16                                 stable                    flathub
Lorem                                        org.gnome.design.Lorem                                        1.2                                    stable                    flathub
Color Palette                                org.gnome.design.Palette                                      2.0.2                                  stable                    flathub
Symbolic Preview                             org.gnome.design.SymbolicPreview                              0.0.8                                  stable                    flathub
Typography                                   org.gnome.design.Typography                                   0.2.0                                  stable                    flathub
Fonts                                        org.gnome.font-viewer                                         44.0                                   stable                    flathub
Identity                                     org.gnome.gitlab.YaLTeR.Identity                              0.5.0                                  stable                    flathub
Iotas                                        org.gnome.gitlab.cheywood.Iotas                               0.1.16                                 stable                    flathub
Apostrophe                                   org.gnome.gitlab.somas.Apostrophe                             2.6.3                                  stable                    flathub
GTK Demo                                     org.gtk.Demo4                                                                                        master                    gnome-nightly
Inkscape                                     org.inkscape.Inkscape                                         1.2.2                                  stable                    flathub
JDownloader                                  org.jdownloader.JDownloader                                   2.0                                    stable                    flathub
Dolphin                                      org.kde.dolphin                                               23.04.1                                stable                    flathub
Kdenlive                                     org.kde.kdenlive                                              23.04.1                                stable                    flathub
Krita                                        org.kde.krita                                                 5.1.5                                  stable                    flathub
NeoChat                                      org.kde.neochat                                               23.04.1                                stable                    flathub
Xwayland Video Bridge                        org.kde.xwaylandvideobridge                                                                          master                    xwaylandvideobridge-origin
KeePassXC                                    org.keepassxc.KeePassXC                                       2.7.5                                  stable                    flathub
LibreOffice                                  org.libreoffice.LibreOffice                                   7.5.3.2                                stable                    flathub
Thunderbird                                  org.mozilla.Thunderbird                                       102.11.2                               stable                    flathub
Firefox                                      org.mozilla.firefox                                           113.0.2                                stable                    flathub
Tagger                                       org.nickvision.tagger                                         2022.11.2                              stable                    flathub
Nicotine+                                    org.nicotine_plus.Nicotine                                    3.2.9                                  stable                    flathub
ONLYOFFICE Desktop Editors                   org.onlyoffice.desktopeditors                                 7.3.3                                  stable                    flathub
Helvum                                       org.pipewire.Helvum                                           0.4.0                                  stable                    flathub
qBittorrent                                  org.qbittorrent.qBittorrent                                   4.5.3                                  stable                    flathub
Tenacity                                     org.tenacityaudio.Tenacity                                    1.3-beta3                              test                      tenacity-origin
Wine                                         org.winehq.Wine                                               7.0                                    stable-21.08              flathub
Wine                                         org.winehq.Wine                                               8.0                                    stable-22.08              flathub
Zrythm                                       org.zrythm.Zrythm                                             1.0.0-beta.4.9.1                       stable                    flathub
Imaginer                                     page.codeberg.Imaginer.Imaginer                               0.2.2                                  stable                    flathub
Atoms                                        pm.mirko.Atoms                                                1.1.1                                  stable                    flathub
Commit                                       re.sonny.Commit                                               4.0                                    stable                    flathub
Oh My SVG                                    re.sonny.OhMySVG                                              1.2                                    stable                    flathub
Playhouse                                    re.sonny.Playhouse                                            1.1                                    stable                    flathub
Workbench                                    re.sonny.Workbench                                            44.1                                   stable                    flathub
Graphs                                       se.sjoerd.Graphs                                              1.5.2                                  stable                    flathub
Cawbird                                      uk.co.ibboard.cawbird                                         1.5                                    stable                    flathub
ArmCord                                      xyz.armcord.ArmCord                                           3.2.0                                  stable                    flathub

Alright, let’s look at the amount of runtimes installed:

1
2
$ flatpak list --runtime --user | wc -l
97

And the runtimes themselves:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
$ flatpak list --runtime --user
Name                                                     Application ID                                                 Version                                      Branch                 Origin
Codecs                                                   com.github.Eloston.UngoogledChromium.Codecs                                                                 stable                 flathub
Proton (community build)                                 com.valvesoftware.Steam.CompatibilityTool.Proton               7.0-6                                        beta                   flathub-beta
Proton (community build)                                 com.valvesoftware.Steam.CompatibilityTool.Proton               7.0-5                                        stable                 flathub
Proton experimental (community build)                    com.valvesoftware.Steam.CompatibilityTool.Proton-Exp           7.0-20230208                                 stable                 flathub
Proton-GE (community build)                              com.valvesoftware.Steam.CompatibilityTool.Proton-GE            8.3-1                                        beta                   flathub-beta
Proton-GE (community build)                              com.valvesoftware.Steam.CompatibilityTool.Proton-GE            8.3-1                                        stable                 flathub
gamescope                                                com.valvesoftware.Steam.Utility.gamescope                      3.11.51                                      stable                 flathub
Codecs                                                   org.audacityteam.Audacity.Codecs                                                                            stable                 flathub
Codecs                                                   org.chromium.Chromium.Codecs                                                                                stable                 flathub
Calf                                                     org.freedesktop.LinuxAudio.Plugins.Calf                        0.90.3                                       22.08                  flathub
LSP                                                      org.freedesktop.LinuxAudio.Plugins.LSP                         1.2.6                                        22.08                  flathub
MDA                                                      org.freedesktop.LinuxAudio.Plugins.MDA                         1.2.10                                       22.08                  flathub
TAP-plugins                                              org.freedesktop.LinuxAudio.Plugins.TAP                         1.0.1                                        22.08                  flathub
ZamPlugins                                               org.freedesktop.LinuxAudio.Plugins.ZamPlugins                  4.1                                          22.08                  flathub
SWH                                                      org.freedesktop.LinuxAudio.Plugins.swh                         0.4.17                                       22.08                  flathub
Freedesktop Platform                                     org.freedesktop.Platform                                       21.08.18                                     21.08                  flathub
Freedesktop Platform                                     org.freedesktop.Platform                                       22.08.12.1                                   22.08                  flathub
i386                                                     org.freedesktop.Platform.Compat.i386                                                                        21.08                  flathub
i386                                                     org.freedesktop.Platform.Compat.i386                                                                        22.08                  flathub
Mesa                                                     org.freedesktop.Platform.GL.default                            21.3.9                                       21.08                  flathub
Mesa                                                     org.freedesktop.Platform.GL.default                            23.1.1                                       22.08                  flathub
Mesa (Extra)                                             org.freedesktop.Platform.GL.default                            23.1.1                                       22.08-extra            flathub
Mesa git snapshot                                        org.freedesktop.Platform.GL.mesa-git                           23.0-branchpoint-4408-g4ac56e3e5a4           23.08beta              flathub-beta
default                                                  org.freedesktop.Platform.GL32.default                                                                       21.08                  flathub
Mesa                                                     org.freedesktop.Platform.GL32.default                          23.1.1                                       22.08                  flathub
Mesa (Extra)                                             org.freedesktop.Platform.GL32.default                          23.1.1                                       22.08-extra            flathub
Mesa git snapshot                                        org.freedesktop.Platform.GL32.mesa-git                         23.0-branchpoint-4408-g4ac56e3e5a4           23.08beta              flathub-beta
MangoHud                                                 org.freedesktop.Platform.VulkanLayer.MangoHud                  0.6.9-1                                      22.08                  flathub
vkBasalt                                                 org.freedesktop.Platform.VulkanLayer.vkBasalt                  0.3.2.9                                      22.08                  flathub
ffmpeg-full                                              org.freedesktop.Platform.ffmpeg-full                                                                        21.08                  flathub
ffmpeg-full                                              org.freedesktop.Platform.ffmpeg-full                                                                        22.08                  flathub
i386                                                     org.freedesktop.Platform.ffmpeg_full.i386                                                                   21.08                  flathub
i386                                                     org.freedesktop.Platform.ffmpeg_full.i386                                                                   22.08                  flathub
openh264                                                 org.freedesktop.Platform.openh264                              2.1.0                                        2.0                    flathub
openh264                                                 org.freedesktop.Platform.openh264                              2.1.0                                        2.0beta                flathub-beta
openh264                                                 org.freedesktop.Platform.openh264                              2.1.0                                        2.2.0                  flathub
openh264                                                 org.freedesktop.Platform.openh264                              2.1.0                                        2.2.0beta              gnome-nightly
Freedesktop SDK                                          org.freedesktop.Sdk                                            21.08.18                                     21.08                  flathub
Freedesktop SDK                                          org.freedesktop.Sdk                                            22.08.12.1                                   22.08                  flathub
i386                                                     org.freedesktop.Sdk.Compat.i386                                                                             21.08                  flathub
i386                                                     org.freedesktop.Sdk.Compat.i386                                                                             22.08                  flathub
.NET Core SDK extension                                  org.freedesktop.Sdk.Extension.dotnet6                          6.0.408                                      21.08                  flathub
Free Pascal Compiler and Lazarus                         org.freedesktop.Sdk.Extension.freepascal                       3.2.2                                        21.08                  flathub
Go programming language Sdk extension                    org.freedesktop.Sdk.Extension.golang                           1.20.2                                       21.08                  flathub
OpenJDK 11 SDK Extension                                 org.freedesktop.Sdk.Extension.openjdk11                                                                     21.08                  flathub
OpenJDK 17 SDK Extension                                 org.freedesktop.Sdk.Extension.openjdk17                                                                     22.08                  flathub
Rust stable                                              org.freedesktop.Sdk.Extension.rust-stable                      1.67.0                                       21.08                  flathub
Rust stable                                              org.freedesktop.Sdk.Extension.rust-stable                      1.70.0                                       22.08                  flathub
toolchain-i386                                           org.freedesktop.Sdk.Extension.toolchain-i386                                                                21.08                  flathub
toolchain-i386                                           org.freedesktop.Sdk.Extension.toolchain-i386                                                                22.08                  flathub
toolchain-i386                                           org.freedesktop.Sdk.Extension.toolchain-i386                                                                22.08beta              flathub-beta
GNOME Boxes Osinfo DB                                    org.gnome.Boxes.Extension.OsinfoDb                             20230518                                     stable                 flathub
HEIC                                                     org.gnome.Loupe.HEIC                                                                                        stable                 flathub
GNOME Application Platform version 41                    org.gnome.Platform                                                                                          41                     flathub
GNOME Application Platform version 42                    org.gnome.Platform                                                                                          42                     flathub
GNOME Application Platform version 43                    org.gnome.Platform                                                                                          43                     flathub
GNOME Application Platform version 44                    org.gnome.Platform                                                                                          44                     flathub
GNOME Application Platform version Nightly               org.gnome.Platform                                                                                          master                 gnome-nightly
i386                                                     org.gnome.Platform.Compat.i386                                                                              41                     flathub
i386                                                     org.gnome.Platform.Compat.i386                                                                              43                     flathub
i386                                                     org.gnome.Platform.Compat.i386                                                                              44                     flathub
GNOME Software Development Kit version 41                org.gnome.Sdk                                                                                               41                     flathub
GNOME Software Development Kit version 42                org.gnome.Sdk                                                                                               42                     flathub
GNOME Software Development Kit version 43                org.gnome.Sdk                                                                                               43                     flathub
GNOME Software Development Kit version 44                org.gnome.Sdk                                                                                               44                     flathub
GNOME Software Development Kit version Nightly           org.gnome.Sdk                                                                                               master                 gnome-nightly
i386                                                     org.gnome.Sdk.Compat.i386                                                                                   41                     flathub
i386                                                     org.gnome.Sdk.Compat.i386                                                                                   42                     flathub
i386                                                     org.gnome.Sdk.Compat.i386                                                                                   43                     flathub
i386                                                     org.gnome.Sdk.Compat.i386                                                                                   44                     flathub
i386                                                     org.gnome.Sdk.Compat.i386                                                                                   master                 gnome-nightly
Codecs                                                   org.gnome.Totem.Codecs                                                                                      stable                 flathub
yt-dl totem-pl-parser plugin                             org.gnome.Totem.Videosite.YouTubeDl                                                                         stable                 flathub
Adwaita dark GTK theme                                   org.gtk.Gtk3theme.Adwaita-dark                                                                              3.22                   flathub
adw-gtk3 Gtk Theme                                       org.gtk.Gtk3theme.adw-gtk3                                                                                  3.22                   flathub
adw-gtk3-dark Gtk Theme                                  org.gtk.Gtk3theme.adw-gtk3-dark                                                                             3.22                   flathub
Adwaita theme                                            org.kde.KStyle.Adwaita                                                                                      6.4                    flathub
Kvantum theme engine                                     org.kde.KStyle.Kvantum                                         1.0.6                                        5.15-21.08             flathub
KDE Application Platform                                 org.kde.Platform                                                                                            5.15-21.08             flathub
KDE Application Platform                                 org.kde.Platform                                                                                            5.15-22.08             flathub
KDE Application Platform                                 org.kde.Platform                                                                                            6.4                    flathub
QGnomePlatform                                           org.kde.PlatformTheme.QGnomePlatform                                                                        5.15-21.08             flathub
QGnomePlatform                                           org.kde.PlatformTheme.QGnomePlatform                                                                        5.15-22.08             flathub
QGnomePlatform                                           org.kde.PlatformTheme.QGnomePlatform                                                                        6.4                    flathub
QtSNI                                                    org.kde.PlatformTheme.QtSNI                                                                                 5.15-21.08             flathub
KDE Software Development Kit                             org.kde.Sdk                                                                                                 5.15-21.08             flathub
KDE Software Development Kit                             org.kde.Sdk                                                                                                 6.4                    flathub
QGnomePlatform-decoration                                org.kde.WaylandDecoration.QGnomePlatform-decoration                                                         5.15-21.08             flathub
QGnomePlatform-decoration                                org.kde.WaylandDecoration.QGnomePlatform-decoration                                                         5.15-22.08             flathub
QGnomePlatform-decoration                                org.kde.WaylandDecoration.QGnomePlatform-decoration                                                         6.4                    flathub
Codecs                                                   org.kde.krita.Codecs                                                                                        stable                 flathub
DXVK                                                     org.winehq.Wine.DLLs.dxvk                                      1.10.3                                       stable-21.08           flathub
DXVK                                                     org.winehq.Wine.DLLs.dxvk                                      1.10.3                                       stable-22.08           flathub
Gecko                                                    org.winehq.Wine.gecko                                                                                       stable-21.08           flathub
Gecko                                                    org.winehq.Wine.gecko                                                                                       stable-22.08           flathub
Mono                                                     org.winehq.Wine.mono                                                                                        stable-21.08           flathub
Mono                                                     org.winehq.Wine.mono                                                                                        stable-22.08           flathub

In that output, here are some of the interesting bits:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Name                                                     Application ID                                                 Version                                      Branch                 Origin

[…]

GNOME Application Platform version 41                    org.gnome.Platform                                                                                          41                     flathub
GNOME Application Platform version 42                    org.gnome.Platform                                                                                          42                     flathub
GNOME Application Platform version 43                    org.gnome.Platform                                                                                          43                     flathub
GNOME Application Platform version 44                    org.gnome.Platform                                                                                          44                     flathub
GNOME Application Platform version Nightly               org.gnome.Platform                                                                                          master                 gnome-nightly

[…]

KDE Application Platform                                 org.kde.Platform                                                                                            5.15-21.08             flathub
KDE Application Platform                                 org.kde.Platform                                                                                            5.15-22.08             flathub
KDE Application Platform                                 org.kde.Platform                                                                                            6.4                    flathub

[…]

DXVK                                                     org.winehq.Wine.DLLs.dxvk                                      1.10.3                                       stable-21.08           flathub
DXVK                                                     org.winehq.Wine.DLLs.dxvk                                      1.10.3                                       stable-22.08           flathub
Gecko                                                    org.winehq.Wine.gecko                                                                                       stable-21.08           flathub
Gecko                                                    org.winehq.Wine.gecko                                                                                       stable-22.08           flathub
Mono                                                     org.winehq.Wine.mono                                                                                        stable-21.08           flathub
Mono                                                     org.winehq.Wine.mono                                                                                        stable-22.08           flathub

We can observe that, just like the author, I have many different versions of runtimes. Even with an unusual amount of runtimes and apps, Flatpak somehow manages to use 37.73 GB, even with most browsers installed as a flatpak.

I imagine that most users have a small selection of apps installed, which only come with a few runtimes and a version apart, which also means that my setup is possibly one of the worst case scenarios. Even with that amount of torture, Flatpak still manages to handle storage fairly well.

“Flatpak does have it’s [sic] uses”

I wouldn’t say Flatpak is completely useless. For certain usecases [sic] it is great to have available. It [sic] think Flatpak makes most sense for when closed source software would need to be distributed.

This is something that is really important to address: Flatpak (Flathub) makes even more sense for free and open-source (FOSS) apps than closed source, because they make apps easily discoverable. For example, Upscaler, an app I developed as a final assignment in CS50x and published it on Flathub on November 16 2022, was featured on OMG! Ubuntu! on that same day (hover over the date for the published date). Another example, gregorni, a friend of mine, published Calligraphy on June 1 2023, which was featured on OMG! Linux! on that same day.

While it makes a lot of sense for closed source apps to publish their apps on Flathub, in my opinion, FOSS apps get even more benefits than closed source apps, because news outlets, especially the FOSS targeted ones, will quickly discover your apps, and might even write an article about them. This also means that more users will discover your apps, which helps it grow in popularity. This also means that you’re not forced to rely on GitHub to make your app discoverable. You could actually use Codeberg and have your apps easily discoverable if they are published on stores that are designed to be discovered.

Imaginer and Bavarder are some GTK4+libadwaita apps that are primarily available on Codeberg, yet both gain more than 100 downloads a day on average, which is a pretty big achievement in my opinion.

Conclusion

In the end, I respect the opinion of disliking Flatpak, as we all have different opinions and disagree on many things. However, there is a difference between having an opinion, and being misinformed and displaying them to viewers or readers, especially when it can potentially hurt the community who are working really hard on addressing genuine issues on the Linux desktop.

As an app developer, I cannot predict users’ setups; I prefer not to waste my time to research what dependencies and their versions Fedora Linux, Debian, Ubuntu, Arch Linux, etc. package. I prefer not to waste my time to refer users to Bugzilla, mailing lists, IRC or other inconvenient platforms that no one wants to use, and later figure out that they’ve been packaging a 6 month old version of the app. Instead, I prefer to devote my time on fixing actual bugs, adding new features, tweak some designs, work on other projects, write articles, or, you know, touch grass for once.

Footnotes