Title: GNOME Gets a Taste of Its Own Medicine
Created: 2021-11-10
Author: zlg

Recently, there was some drama surrounding Pop!_OS due to two things: the
publishing of a Linus Tech Tips video [1] that highlighted an oversight
involving Pop!_OS and installing Steam, and the ongoing advancement that
GNOME is engaging in with libadwaita, GNOME 42+, and GTK4 contrasting with
Pop!_OS, elementary, PureOS, and other forks of GNOME 3.x. GNOME chose to
call out System76 as their target, and spent an entire blog post on spreading
misinformation regarding how open they *actually* are to collaboration. It
seems they wrote the blogpost because they perceive System76 to be spreading
misinformation, but from my perspective, I see multiple organizations frustrated
at an upstream whose ego is catching up to them. So with the preface out of the
way, let's talk about the video.

- - -

Linus attempted to install Steam via `apt` on Pop!_OS, and due to the way apt
processed dependencies, it chose to remove the desktop interface Linus had
installed in order to meet Steam's dependencies. This was caused by certain
32-bit dependencies for Steam not existing, so apt did what it could and
fell back to Ubuntu versions of said dependencies. This caused pop-desktop
and friends to be removed, hosing Linus's GUI. This caused him to express
disappointment in Pop!_OS and move onto another distro.

After this video hit Youtube, Linus's fans took to Twitter to more or less talk
shit about Pop!_OS, even though they personally hadn't encountered the problem
and Linus even included at the end of the video that *he didn't carefully read
the output of a `sudo apt` command*. System76's own page for installing Steam
mentions that you should do this. I'm not sure what, if any guide that Linus
followed, but System76 explicitly mentions this in their docs. That said, the
problem was with packaging, and it was quickly fixed by System76, but Linus's
fans weren't stopping.

This upset the developers at System76, and so one prominent developer protected
his tweets in order to bring some order to his feed, since the problem was
already fixed. This was seen by some as 'unprofessional' and a bad move, but I'd
like to know what exactly entitles random passerbys to talk shit about a project
-- which they are in fact *WRONG* about, now at least -- and expect someone to
take it without any fight. Using professionalism as a veil for justifying the
mistreatment of someone is some of the most disingenuous rhetoric I've seen
and I'm ashamed to be associated with the Linux community, who rallies behind
professionalism as if it's the only acceptable way to conduct yourself in the
Bazaar that is libre software. No; in the face of someone attacking you, you owe
them no respect, even as a professional. It's hypocritical to act however way
you please and then expect someone else to behave to a higher standard than you,
yourself are capable of.

- - -

In the other arena, GNOME is making it so that GNOME core applications rely on
libadwaita, which is what they're calling a 'platform library' providing the
entire API for the platform, including theming. This means that if you package
gedit, gnome-terminal, nautilus, et al, they are stuck with the Adwaita theme.
This is an attempt to push out forks by forcing them to either accept Adwaita as
literally the only theme (why do you think it's named "the only one"?) possible
with their applications via libadwaita, or reimplement all of the library just
to theme.

GNOME forks have reached out to GNOME on multiple occasions, asking for certain
theming and UI capabilities be made available in GNOME (things from better
theming APIs to more customizable hot areas, docks, appindicator support,
etc.), to more or less no results. Some things, like appindicator support, are 
things they only needed to leave in. Canonical appears to be one of the only
organizations that's on GNOME's nice list, and it's another corporation like
their top funder, Red Hat... Where exactly are you a team player, GNOME? At 
GUADEC, Linux Foundation conventions? Certainly not the greater community. :)

So it's really weird that they respond to System76 specifically, with a blog 
titled "A Case Study on How Not To Collaborate With Upstream". [2] Already, the 
title is condescending and patronizing. Throughout the blogpost, they outline 
situations where they discuss with System76 at first, or Sys76 comes to them 
first, they reject their idea, System76 makes their own solution, and then 
doesn't upstream the work.

Hey GNOME guys, what entitles you to their commits being ready for merge into 
your project? Part of the beauty in libre software IS being able to fuck off and 
have your own repository, with blackjack and hookers. Also, why do System76 have 
to apologize or retract any statements ex post facto fixing or merging 
something? That's an unreasonable demand and it's manipulative. If you're 
reluctant at first and the contributor screws off on their own, and you later 
merge something of theirs without telling them, well... they probably just 
forgot about collaborating with you altogether. The relationship has been 
damaged by your failure to adopt or help massage the changes to be palatable for 
your project.

GNOME devs are quick to point out that the GTK_THEME environment variable will
work to specify your own stylesheet, even in GTK4. However, there's this problem
between upstreams and devs regarding trust: will GNOME support GTK_THEME going
forward? Libadwaita itself only mentions GTK_THEME in a single location [3]. How
long will that last? There is no indication of such a feature continuing to work
on GNOME. There's *strong* indication that they don't suggest doing it, which
is a hint that they will not support it going forward. Why can't they offer a
straight answer?

This is where the peanut gallery makes accusations of FUD (fear, uncertainty,
doubt). It's a dogwhistle term meant to dismiss people without having to form
an argument against what they are communicating, as if uncertainty and doubt
are simply not allowed. There's no fear to mention here, but there's plenty
of uncertainty as to which features will survive in GNOME going forward, and
there's plenty of doubt among GNOME downstreams that they will be able to rely
on GNOME going forward. The social problems they are having with others in the
development community add credence to this. So, the FUD argument is moot.

More claims are made, separating GTK4 and libadwaita, but who develops those
two? That's right, GNOME does. Again, given GNOME's history with removing
anything that doesn't gel with their vision and later making up reasons why
their approach is superior, what reason do developers or users have to believe
that this functionality will remain in the future? This comes across as very
weasel-wordy, and avoiding a conclusive answer, so they can lead devs along as
long as possible before ripping the API out from under them. This gives them
maximum leverage over the ecosystem until they have their next thing ready to
push and market. They're biding time for GTK4 to be ready. Once it is, it will
be trivial to remove GTK_THEME support and demand people follow cadence or be
left behind. Lots of this practice among commercially funded projects like
GNOME.

GNOME developers, as a social unit, seem to expect to be treated like royalty
among libre software projects simply because popular distros rely on them.
This is the same sort of hubris demonstrated by Lennart Poettering and Drew
DeVault. There's a common saying in the Western world, that first impressions
matter. If a developer's first impression of GNOME, or systemd, or Wayland is
a negative one, what moral standing do they have to ask for more of a chance
or to collaborate? In the real world, you only get one shot at making a good
impression, and now GNOME's mad that their failure to collaborate constructively
is finally catching up to them and making them look bad.

Let's make a few things clear:

Downstream devs owe nothing to upstream regarding patches. Zilch. If you care
about your forks, you should clone and pull periodically. This way, you can
`cherry-pick` what you want and avoid what you don't want. (Hint: this is
what picky downstreams do to upstream codebases, too!) Sure, it's nice when
upstreaming happens, but let's be real: most contributions to libre software
projects, not just GNOME, are rejected. Thus, putting effort into upstreaming
patches is a good way to lose man-hours in your own project. Then, assuming your
patches make it into upstream, you have to keep up an appearance and defend the
feature being in the codebase. I don't know about you, but I'm interested in
libre software for the software, code, and freedom. Not to endlessly argue about
whether or not my patches belong or playing politics to keep my contributions in
a project. That's not collaboration, it's exploitation of free labor.

The lesson large projects should be learning from these events is one of social 
friction. Not just in terms of the interpersonal disagreements, but of the 
structure they build for this mythical collaboration they tout. The more hoops a 
contributor has to jump through to get their code into your project, the less 
likely they will be to contribute. Maybe that's what you want. In that case, 
cool, whatever. But then don't bitch about not having enough collaborators, or 
collaborators who are prepared to switch stacks if the going gets shitty enough.

Code review is important. Quality is important. I get it. But you have to
respect the work that goes into contributions sent your way, and reject
gracefully if you must, or the project's reputation will suffer. None of this
is unfair in my book. If I started a project and advertised I was accepting
patches, but bug reports and patches were full of arguments and bickering over
small details in code and grandiose design ideas that are a decade away, then my
project would rightfully earn a poor reputation for contributors, regardless of 
how much my users enjoyed the software.

For the record, I am one such person who has contributed to projects in the
past and stopped doing so because I got tired of wasting my time on code that
was never going to be accepted in the first place, or people becoming expectant
that I would continue to churn out code for them when mistreated. If you want
contributors, make a clear coding style that isn't 20 pages long and provide a
list of features that you, for sure, will never implement. Help contributors
massage their contributions into being workable for your codebase, or reject and
encourage something more constructive for their efforts.

GNOME and other butthurt upstreams are quick to point out the human side of
libre software for their own defense, but pay no respect or consideration to the
humans outside of their group whose efforts have been wasted by their API churn
and dismissive attitude on the bug tracker and in popular media.

It turns out that even big projects need to respect the contributors they rely 
on, or they'll start losing mindshare.

The community's getting tired of your two-faced communication and eagerness to
play victim when you've turned away countless contributions in the feverish
chase for a universal GUI and unique brand. Frankly, I feel System76 has
done nothing morally wrong, even though they too are a corporation. The bug
concerning apt was fixed rapidly after Linus' video was published, [4] [5] and
from what I can tell they are continuing to try to make the GNOME 3.x-based
stack work, along with Purism and others on GTK4. You HAVE collaborators, GNOME;
you've just treated them like shit, and you're mad that people are calling you
out in a loud enough voice to have an impact.

GNOME developers, this is your wake-up call.

-z

P.S. Don't pay attention to discussions on popular fora concerning this topic: 
some communities are heavily moderating discussion to manipulate the narrative.

Looking on the /r/linux subreddit resulted in locked threads and numerous
deleted messages by the resident tyrant and moderator of /r/linux,
/u/CAP_NAME_NOW_UPVOTE. They, along with /u/blackcain (a GNOME developer) have
a stranglehold on the topics that make it to /r/linux, with an obvious bent in
favor of GNOME's agenda. So, popular fora that GNOME influences are silencing
discussion on this topic *and* the System76 <-> GNOME drama. That's not the
behavior of a transparent or neutral community. To add to this, moderator
usernames (and affiliations) are hidden on the sidebar unless you have an
account, are logged in, and are not banned. Quite interesting that Reddit
assists moderators in avoiding accountability for their censorship.

One such accusation the mods there used is "some users think this is the most
important thing in the Linux world right now" (who?) "and we disagree." [6] That
begs the question then, /u/CAP_NAME_NOW_UPVOTE: What *is* the most important
thing in Linux right now? That's right, you won't answer that, will you? :) It's
because it's about silencing and control of the narrative for you, and not about
allowing discussion or sharing perspectives. You are not fit to lead or manage a
community. View the threads with removeddit for the full picture. [7] [8]

If you're capable of defending your viewpoint in a neutral medium on equal
ground, hit me up. You personally have a history of deleting threads and
comments when you're challenged. Truly, the cowardly way out of a discussion.
Time will tell if you step up or not.

I can be reached on Libera as 'zlg' and my e-mail is zlg@zlg.space.

[1]: https://youtu.be/0506yDSgU7M
[2]: https://blogs.gnome.org/christopherdavis/2021/11/10/system76-how-not-to-collaborate/
[3]: https://gitlab.gnome.org/GNOME/libadwaita/-/blob/2bad3db9082c0b8aadbbeb9abdc20b25694d65e3/src/adw-style-manager.c#L257-271

[4]: https://twitter.com/jeremy_soller/status/1453008808314351628
[5]: https://github.com/pop-os/apt/pull/1
[6]: https://old.reddit.com/r/linux/comments/qq9dsb/linux_hates_me_daily_driver_challenge_pt1/hk118b7/
[7]: https://www.reveddit.com/v/linux/comments/qqit79/system76_a_case_study_on_how_not_to_collaborate/
[8]: https://www.reveddit.com/v/linux/comments/qq9dsb/linux_hates_me_daily_driver_challenge_pt1/