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/