Is GNOME Actually Evil?

tty0 login: novatorine
login date: 2024-05-02


GNOME is the de facto or de jure default desktop environment on many of the biggest Linux distributions, and it has a substantial marketshare among Linux users. Yet, GNOME seems to be positively reviled by a vocal minority of the Linux community.

Why the hell is that?

Is it just because GNOME is the most widely used DE, an example of Bjarne Stoustrup's rule of programming languages applied to other software? Or is all this hate earned, somehow? Or is it, perhaps, the result of a bandwagoning hate mob, a sort of cultural vicious cycle a portion of the Linux community is stuck in?

When I first started hearing about the hate people had for GNOME for reasons beyond just not liking its interface, I was completely neutral. Oh, I used it and liked it, but I was willing to admit that sometimes bad people could create good products, and maybe the GNOME developers were toxic. What did I know, right?

Strangely, though, the more I fell down the rabbit hole, listening both to the first hand grievances of GNOME haters and (this is the crucial part most people don't seem to do) actually listening to GNOME project members, with an ear toward actually hearing what they as people were saying, instead of just an ear toward mining out of context quotes to make them look bad, the less and less the GNOME haters seemed to be behaving reasonably. A lot of the hate for GNOME seemed like people refusing to see their dissatisfaction with it as "the free stuff I'm getting isn't exactly what I want", and instead choosing to see it instead as "the evil GNOME developers want to take things away from me to be mean to me specifically and control the Linux desktop to take away my freedom." But fundamentally, that reaction never seems like a proportionate response to what GNOME did as far as I saw.

As a result, I've been meaning to write an essay about the GNOME haters for some time now. However, I wasn't sure what to use to represent them: simply trawling the Hacker News or Reddit comments sections wouldn't really be productive or helpful, since who knows how representative that was, but I wasn't sure where else to look, so I shelved the project. Just recently, however, I got into a bit of a spat about GNOME on Hacker News with someone who not only handily demonstrated the facile logic, emotional manipulativeness, and entitlement of GNOME haters, but also happened to collect a number news articles, form threads, and blog posts from major anti-GNOME figures in the community like the people behind Budgie — i.e., just the sort of first hand evidence and statements from major figures I'd need to make this article worthwhile! At long last, I could finally write the article I'd been meaning to write about GNOME.

So what did I learn from reading those sources?

What I Learned

In the intervening years since ESR wrote The Cathedral and the Bazaar and the fledgling open source world was high on the hardest drug of all — hope — the meaning of open source software has changed. Something has been forgotten in the rush, a conflation has occurred between the core values of free software and... something else.

The Cathedral & The Bazaar

The free software movement used to refer to an ecosystem of individual programmers creating software that scratched their own itch, and then sharing it freely with the rest of the world in case it scratched anyone else's itch. It was understood that it was okay for software to reflect the vision of its creator(s) and any like-minded affinity group that sprouted up to aid in that software's development. Software wasn't expected to change for any random group that showed up out of the woodwork and demanded changes if they had no stake in the project and fundamentally disagreed with its reason for being, and patches didn't have to be accepted if they didn't fit the project. If there were fundamental philosophical disagreements, well, that was what forking was for. But most crucially of all, no one was thought to be obligated to anyone else. The community understood that since they provided nothing in return for the software that was freely given to them, nothing could justly be expected or demanded of the people making it. It wasn't a trade, it was a (surprising, exciting, benevolent) gift, not a contract, not a product. The GPL still understands this idea, at least in print:

...the program 'as is' without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair or correction.

Software was provided this way because what open source contributors did was a benevolent act, a gift, and gifts do not incur obligations on the part of the giver. So software was provided without the promise that it would be what you wanted, or that features or bugfixes would be added at your request.

But that has changed. No longer is open source a gift economy, a gratis exchange of ideas and programs with no strings attached and no obligations incurred in recognition of that fact. Nor, for most people, has it become a paying job, either, though — instead, it's become almost the worst of both worlds:

All the obligation, none of the renumeration.

For decades a pervasive mentality has been growing that if someone uses a project — whether as an end user, or a downstream — then they are owed by the project maintainers and contributors. Despite the fact that it is their labor, and the product of their own labor, and that they are doing all of this completely gratis, with no expectation of any sort of return on investment, and users are piggy-backing off of their work, the assumption is that project contributors owe their downstream users. Whatever features, bugfixes, and design changes users want must be supplied by the projects they use, or it's abuse, it's neglect, it's anti-user rights.

And you know, within reason, it is absolutely a good thing for a project to serve its users needs — to fix bugs, add features. But to take that and convert it from a supererogatory positive thing projects can do, when it is within their time and budget constraints and aligns with their goals and their roadmap, into something that is required, is, in my opinion, an abandonment of a core pillar of the open source ecosystem that makes it function properly.

We talk about user's rights, but somehow we've forgotten that RMS's four freedoms...

Was about giving users rights over the software they already had. It was about user autonomy and self-determination, not user convenience through giving users true ownership of the software they actually have installed on their computers (a sort of "right to repair" for software), instead of giving users more freedom by giving them control over future versions of the software, because the former gives users rights over the things they're actually using and relying on, and in return only exercises control over labor that's already done, already alienated, whereas the latter gives users rights to dictate the direction of the ongoing and future labor of others — which takes it from being about self-sufficient possession, to a form of soft exploitation through entitlement. It's like the difference between being able to own a house — and so modify, repair, and share it however you want — and the individual self-sufficiency and autonomy that implies, and being able to demand a plumber come and fix your house, or a construction worker come improve your house, without paying.

In essence, we forgot that open source is largely the volunteer labor of people working on their own projects, and decided to treat it like a business, while demanding it not be a business. To act like paying customers, who are entitled to the product they want, while refusing to pay anything, and lambasting anyone who talks in a remotely corporate way, or perhaps puts their download button behind a donation screen like ElementaryOS does.

ElementaryOS Donation Screen

We want to have our cake and eat it too, because we've forgotten that open source is not about you, and it's burning maintainers out, and the best solution for many of them seems to be just being a lot less generous with their time, because people will continue to take and take and take and take as if it was their birthright to do so.

This is the context into which GNOME emerges.

NOTE: I'm not going to directly quote anything from the sources here, because a lot of the quotes from the GNOME team are complete Rorschach tests absent added context and analysis, so directly quoting things is likely to only further confirm whatever the reader already believes, no matter what side they're on. Instead, whenever I make a generalization about them, I'll link to my detailed source-by-source breakdown so you can see why I think that.

The sources that my interlocutor quoted to me were supposed to establish a "pattern of behavior" on the part of the GNOME project, but in every case where there was a way to directly see what the GNOME project or its developers actually did or said, it seemed completely harmless and within their prerogative and at worst some mild justifiably provoked sarcasm, just interpreted with the least good faith possible. The only things that could have been damning were second-hand claims from specific individuals claiming GNOME was "abusive" to them, but providing no direct evidence for me to look at, which means I'd have to trust their word, but given the lack of abusive behavior I saw whenever GNOME's behavior was directly visible, my own experiences with reporting bugs to them, and the tendency to hyperbole and drawing wild conclusions I tend to see from GNOME-haters, I have no reason to do that. I don't even have any evidence that by abuse they mean anything reprehensible at all, given that "abuse" as a word can be stretched quite far by emotionally motivated parties.

In the end, this whole thing really just taught me more about the haters of GNOME, not GNOME itself. In a nutshell, the main complaint on the part of the major community figures seems to be that GNOME is too opinionated in pursuing its own design goals, and this makes it a bad platform to develop their entirely different desktop experiences on top of using theming and extensions. More specifically, the complaint seems to be that the GNOME project isn't willing to bend over backwards and to do even more work to make theming and extensions stable (and got mad when GNOME caved and did it in a way they didn't like) in order to make it easier for downstream developers to exploit the work the GNOME developers already did. It's just: "I'm taking advantage of your hard work because it means I have to do a lot less, but you're not making it sufficiently easy for me, how dare you!" They want to act like they are paying customers of GNOME, when they are absolutely nothing of the sort, and GNOME owes them no labor at all.

Old man yells at cloud

There are also complaints that the GNOME developers don't get to bugs fast enough, or that they don't implement enough features for some people, or they pare down features too ruthlessly, or sound too corporate, or that they're occasionally ignorant about things outside their area of expertise, but to be quite honest, I think the correct response to these, at least the complaints regarding features and bugs, is the same as the response I'm going to give to distribution maintainers, so I won't be addressing those complaint separately. Instead, whenever I say something distribution maintainer-specific, simply remove or replace that with something to do with features users want, mutatis mutandis. I don't think projects should only have a right to determine what features they want to implement and how they want to design things free of obligation to downstream (as long as the project isn't breaking any explicit promises or veering away from its core intent without warning), either — I also think projects generally have the right to follow their design vision, even if a vocal minority of users are unhappy with it. So I think my arguments below generalize across that whole spectrum from individual user to downstream project — ultimately, it is the GNOME team doing the work, so they should be able to follow their own design vision, as long as no promises have been made. In the end, forks exist for fundamental philosophical disagreements, and users are also fully free to use something else in a healthy free software ecosystem. Indeed, they have already begun to: GNOME is no longer the dominant DE on Linux, that's now KDE.

And you know what, this might have even been a valid point even if they weren't paying customers, had GNOME ever promised to be a modular, customizable, extensible toolkit for building unique desktop environment experiences for downstream distros, because then it would be a betrayal. But that's not GNOME, that's KDE (or COSMIC). GNOME's vision has always clearly been, since the GNOME 3 release, that they want to provide a quality-assured, clean, coherent finished product for end users to use directly. They aren't in the business of creating something that's meant for other people to build off of it into their own completely different thing in the first place. That was never part of the goal. The only reason people think it is, is because that was GNOME 2's goal, and so treating GNOME this way is "what we've always done." But that simply isn't going to be productive — you can't bludgeon someone into changing their goals through sheer willful blindness in ignoring their current, actual goals, and, for instance, theming is not compatible with a properly quality-assured experience. So in reality what's happening is that everyone has decided that instead of taking KDE, which is actually made for this kind of modular customization and theming, and turning it into what they want, they're going to use GNOME instead, and then they're going to berate and vilify the GNOME team for not doing extra work to make something that's completely contrary to their goals and outside their mandate possible. GNOME simply isn't meant to be a desktop environment building kit, and yet for some reason people are hopping mad it isn't good at that anyway.

Moreover, people fundamentally just seem angry that GNOME is opinionated — that it has its own vision, its own ideas it wants to pursue, and is bravely and consistently pursuing that vision, those ideas, over the course of decades, pursuing what makes its developers and the users that buy into its vision happy to use it. For the people angry at GNOME, it seems, there is no room for an open source project with its own vision that it wants to pursue anymore; every project should instead bow down to the democratic demands of the masses of users that have decided to use it, whether or not those demands actually align with anything the people actually doing the work of keeping the project going want to do, or even don't contradict the entire premise and raison d'etre of the project to begin with. And the irony of this is that everyone wants to base their work off of GNOME instead of KDE precisely because they're more focused and opinionated and minimal and their design is better. These GNOME-haters simply can't seem to quit using GNOME like a chain smoker can't stop going through packs a day because it's just so good compared to the alternatives for the same reason they hate it. But you can't have it both ways like that.

Ironically, one of the final sources cited to me by my Hacker News interlocutor, a YouTube video from an Inkscape developer, actually sums up what GNOME is doing pretty well, in my opinion. The two components we have going on are, first, that people seem to have expectations for what GNOME should be that are completely divorced from what they have been clear it is:

A lot of the, should we say, grumbling about the GNOME project actually comes from the fact that GNOME's old promises and what people think GNOME should be promising is definitely not what the GNOME project is promising today. Um, it used to be the case that the GNOME project's problem that they were trying to solve, their goals, were to basically be a free software desktop platform, and being able to enable lots of different applications to be developed is, you know, definitely a part of that mission. But as time's gone on, this idea about being both a free software community and being a platform has faded away, and instead, what's happened is the GNOME idea has turned into being a product and turned into being a desktop. There's nothing wrong with that, but it means that the promises about what users should expect from it have changed, and I suspect that that's a lot to do with the kinds of blog posts that we're seeing, the communications that we're seeing out of contributors for GNOME, and it's probably what makes it very tiresome for GNOME contributors to have to constantly repeat about why people are mismatching what they think the GNOME community should be.

And second, that GNOME isn't run in the way people have begun to expect from free software — the core maintainers and contributors don't just do whatever the broader "community" that just happens to use their software wants; instead, there's a clear vision and set of goals and something specific they're pursuing, and if you want to have real weight to steer those goals, then you should actually be a consistent contributor to the project, not just a voice from the peanut gallery or a drive-by pull-requester, because the people who do the work get to decide what work they do and how to guide the product of their work:

I don't think the GNOME Foundation is looking after a community. Uh, this is a hot take, fair warning. I think they're looking after a worker-owned cooperative, right? If you don't know what a worker-owned cooperative is, it's basically the idea that the people who work for a business, they buy in through their labor into the ownership of the company, and through that ownership, they're then able to do things like vote, right? So, you get a decision on how the company moves, and a community is different from that, right? What happens in a worker-owned cooperative is very differently structured; you have people who are inside, people who are outside, you have a pathway that you have to attain in order to become a part of the inside group, and once you're in on the inside group, then you are given more capacity to make decisions, more trust to make things like vote, and, uh, you know, you get those privileges. Um, you could only do that if you had sustained and continual contributions to a bunch of projects, and that's definitely a buy-in, right? That's not a community operation. It's not really a community operation; community should be open to everybody. Community is not something that you should have to gatekeep, right? But if you're operating a resource-poor, resource-restricted, and let's, let's, should we say, hyper-focused project, where you've got all of these restrictions, where you just cannot spend time on people's mistakes, people's fantasies, people's learning opportunities, all of these chaotic things that happen in their community, you have to figure out ways of restricting things, and, um, I think the GNOME project has chosen a pathway that they want to go down.

The thing is, this seems perfectly acceptable to me. I'm a big fan of worker cooperatives, after all: workers should own the product of their labor, and be able to direct their forces how they like! The people that actually do the work to make something possible, in my view, absolutely should be the ones determining where and how they work, and what they work on, and the direction the thing they're building takes. Anything less, any attempt to make some kind of claim on what workers should and should not do or exert a form of control or ownership over the product of their labor, unless they've explicitly made contracts or promises or been paid or something, is a form of exploitation. And lest you think this is hyperbolic, recall all the links about open source maintainer burnout above: this mentality that the downstream users of open source projects are entitled to the labor of open source maintainers (and entitled to have maintainers merge their PRs), instead of that work being a benevolent free gift, given gratis and without warranty, is actively burning out and exhausting open source maintainers and leading to major security breaches like the xz event, and this is happening precisely because this is a form of soft exploitation.

Me, explaining to you why open source work can become exploitative

The Inkscape developer obviously goes on to say that he doesn't like GNOME's perspective, else why would my interlocutor bring it up, talking about how GNOME didn't accept his input and contributions even though he was a "long-standing free and open source contributor," which honestly smacks of a bit of ego to me — how dare they treat me like anyone else because my credentials don't have anything to do with their project, don't they know who I am? — and how your average "casual user" who doesn't know how to program may be disempowered by GNOME's philosophy, because they won't have any way to have an inroad to get their ideas more than just heard out, but actually implemented, by the GNOME team, but again, that's sort of the beauty of open source, isn't it? You can switch projects to find a project with a feature-set and community philosophy that more suits your own, like KDE, which will happily add any feature anyone asks for. I do agree with him though that it would be nice if GNOME went the Codeberg route and introduced some kind of monthly donation that people could sign up for in order to be considered "active contributors" which in return gave them voting rights, but I don't think it's mandatory, or the fact that they don't do that is anti-user. It's just, simply, a different way of running an open source project. That's all.

And the thing is... many open source projects, like Codeberg, are basically run this way — with a single strict vision it adheres to and/or giving vastly heightened weight to the input of active contributors. It isn't very common right now, due to the pervasive culture in open source I've talked about, but it is something some projects do — perhaps more than you'd think.


Likewise, there are some projects that are driven by a coherent vision and guiding philosophy, and refuse on principled grounds to implement features outside of that mandate.

And none of these projects get the kind of widespread hate and harassment, nor claims of "abuse", that GNOME does; the validity of this method of running your project is recognized for every project other than GNOME. If someone did what I suggested above and went to any other open source project and started making entitled demands that features completely outside of the mandate that project has committed to, incompatible with its vision and goals, nobody would bat an eye if they were ignored or even got some sarcasm in return.

If I began belligerently demanding that Alpine switch to systemd by default, because I had based a distro on it and found switching my distro to systemd after the fact difficult and annoying, and claimed that they were "sabatoging my work to make their work look better" simply because they said they thought not using systemd was part of making their effort the best it could be, and as a result that happened to break my distro, if I went around whining about how I offered them a "solution" (a merge request to add systemd) but they didn't accept it and that makes them intransigent and abusive, about how they "didn't respect the effort I put into replacing their init system with systemd," no one would take me remotely seriously.

If I started complaining about how the suckless people were evil and abusive because they refused to add Lua scripting or theming or an expose view to dwm, because it didn't fit with the vision of their project, I'd be laughed out of town. Yet when it comes to GNOME, similar claims are made about their decisions all the time and everyone takes them seriously.

Granted, there aren't many examples of such deeply opinionated projects in open source, but it is absurd to say that means running a project with a clearly defined vision and design philosophy is wrong, that everything must be done according to the dominant historical paradigm of open source developemnt, simply because opinionated projects with a clearly defined scope, design, and vision are rare in the free and open source world — that most are content to bloat and expand, throwing more and more features onto the pile until the entire thing sags under its own weight, in order to avoid the inevitable ire of users if anything is removed. Indeed, I think this culture of trying to please everyone, instead of focusing on your own vision, is not only one of the things driving open source maintainer burnout, as this mentality of entitlement, where open source maintainers aren't freely giving a gift that scratches their own itch to others, in case it scratches anyone else's, but are actually obligated to others, metastisizes beyond control. I also think this mentality is one of the core problems with open source software design in the first place: nothing has a coherent vision, or an organizing principle, or no such coherent vision or principle survives contact with the users.

There's another double standard at work here, too. There seems to be this expectation that "upstreams" must cooperate with everything "downstreams" want, even when that upstream didn't ask to become an upstream and wasn't intended to be one, like it's some kind of moral law... but downstreams cooperating with upstreams? That's supererogatory. Downstreams should be completely free to follow their vision and do whatever they want. So for instance when System76 didn't cooperate with upstream GNOME by refusing to adopt a commonly accepted standard for firmware updating, that was perfectly fine to the GNOME-haters — no one wanted to chastise that sort of behavior, because everyone recognized it was their prerogative to act that way if they wanted to. Why this difference, though? If upstreams are obligated to downstreams, to provide them with the tools and features they demand, why shouldn't downstreams be obligated to cooperate with the features upstream wants to introduce and send patches upstream in return? If the relationship isn't mutual, it very much seems like an exploitative one to me.

In the end, then, this seems like a clash of ideals and expectations. Many people in the FOSS community seem to view themselves as entitled to be able to sway the direction of any project they use, entitled to the labor of the people that maintain and contribute to those projects, and view the only "correct" way to run an open source project as running it like a democracy.

I disagree, though.

I think the entire point of open source is not to gather together in great democratic mobs to spear these noble behemoths and drag them down to our level, crushing their visions along with their souls so we can feast on their entrails as the project dissolves inevitably into homogenous mush. It isn't to make KDE clean and simple and GNOME modular and highly customizable and Alpine use systemd and Void Linux use the apt package manger.

The point isn't to evolve everything into a shambling cancerous mass by popular demand.

what happens when you add too many features if you didn't intend to be extensible from the start

The point of open source in my view is, instead, the opposite: for each project to pursue its own unique interesting vision, and let like-minded people flock to the projects that intrigue and excite them, and leave the projects they don't like using or working with in the dust without a care. The point is free choice, and ever-growing diversity, not homogeneity. It is to let anyone, with as little friction as possible, take the code of anything they want and do their own thing with it, pursue their own vision, so that hopefully, no matter what your vision is, you'll be able to find a project that aligns with what you want, and use it, and improve on it if you want to. I don't want everything to become KDE or XFCE. I want GNOME, KDE, XFCE, to all exist alongside each other, alongside COSMIC and Cinnamon and Budgie and Sway and i3 and Qtile and Xmonad and dwm and everything else — all with their own unique appeals.

Into The Future

What about all the distribution maintainers basing their work on GNOME, or the users that want a say in GNOME's development, but don't have the time or skills to contribute code? If we let GNOME do their thing, that doesn't really solve their problems, right?

Well, the needs expressed by the distro maintainers and users are real, otherwise there wouldn't be so much energy and emotion and vitriol invested into them, and I am sympathetic to the issues they have. I don't think distro maintainers are just making things up to stir drama. The problem is just, as cliche as it sounds, that there's been a misunderstanding over what the GNOME project is supposed to be and do, and as a result the hopes and demands of distribution maintainers are just simply being directed at the wrong people. Thus, the solution, to my mind, is to stop blindly trying to force GNOME to be right for a use case it isn't trying to be right for, and instead find something else for distro maintainers to use that will be better and easier for them.

In this vein, I think System76 might actually be offering us a light at the end of the tunnel with the COSMIC DE: COSMIC is a clean and cutting edge desktop environment explicitly designed from the ground up to be even more modular and composable and customizable, at least in theory, than KDE, and in a much more reliable way — specifically with the aim of providing a construction kit for making your own desktop environment. This seems to be exactly what many distros have been dying for since the GNOME 2.0 days, so this seems like the ideal solution. In my ideal world, I imagine Mint, Solus, Budgie, Ubuntu, System76 and others getting together to create some sort of open source foundation or consortium to govern the direction of the DE toolkit they all use and help them share resources and improvements. I mean, what other desktop environment could compare with the combined might and investment of so many distribution maintainers, right? I think they'd do pretty well, especially if things like openSUSE joined in.

Pop COSMIC DE's Iced toolkit tester

The other option I see, in case the amount of effort required to build a new DE from scratch is simply impractical, and things need to be built using GTK, is forking GNOME and putting the fork under the governance of an open source foundation or consortium like I suggested above, thereby being able to take advantage of the full history of work on GNOME — and maybe even their ongoing work, if the fork decides to periodically rebase or adapt patches from upstream! — and giving distribution maintainers more control over the direction of the project, while being more fair to the actual GNOME project.

Or, alternatively, if everyone is dead-set against having to maintain their own desktop environment in any way, why not just use KDE? KDE seems tailor-made for the needs expressed by the people angry at GNOME — so much so that some of them (not IgnorantGuru, to be fair) very often compare KDE favorably to GNOME, pointing to how well KDE complies with their needs and input compared to GNOME — at which point, especially now that KDE has its own activities overview, why not just use KDE? It even has the concept of "global themes" that are supposed to not just theme the DE but completely rearrange its looks and behavior, officially supported by upstream. Wouldn't that be perfect for distributions? And in fact, here and there, we do see the inklings of this move: Steam Deck, for instance, chose to use KDE instead of GNOME, probably for some of these reasons.

KDE Plasma 6

As for users, I think the best thing would be to take the Inkscape developer's advice and give non-programmers a path into the "worker cooperative" that is GNOME through monthly subscriptions/dues. In fact, I think that's something that a lot of open source projects could honestly stand to do: prioritize the needs and desires of people who are actually contributing something in return for their demands, but then make sure to add an easily discoverable way for those who don't have the time to contribute through labor to contribute monetarily instead, so they can have a voice without either making demands or having to become an expert in compositor programming. This seems like a very fair and evenhanded way to set clear boundaries to avoid burnout, to make it clear that while information wants to be free, and so software should remain libre, labor doesn't want to be, and cannot be, free, so if you're going to demand the labor of others, you should probably remunerate them in some fashion, to make it a fair mutual exchange, instead of a demand.

In the end, then, although I think this whole endless cycle of vitriol and hate is fundamentally built on rotten foundations, and find it saddening, I really do see hope for the future, for all of this to end. GNOME's userbase will shrink, probably, but that's okay, and in the long run I think there's a chance for everyone to be happier and a lot less stressed out.

NOTE: I'm going to continue to discuss my opinions of how my actual interaction with that Hacker News denizen went, as it's cathartic to voice my thoughts about an abusive interaction like that, and because it holds important lessons for us to learn about this whole discussion, but feel free to stop here.

Appendix A: The Brain Rot From Outer Space

This healing won't be easy, though. In all the time spent reading the sources provided to me as evidence against GNOME. There's so much entitlement, so much petty grievance, so much grandiose moralizing, and so little willingness to actually revise stances or change expectations without needless acrimony (some of the sources are about distro maintainers realizing that GNOME isn't built for making DEs, and realizing they should probably move off it, but directing ire at GNOME for "making them do that" when it was never supposed to be for that purpose in the first place) that lurks just behind every word written by these people, a sort of sense of one's own moral superiority and others' obligations to you, a willingness to grandstand about abstract principles and values like "empathy" and "respect for hard work" and "introspection" and "willingness to admit you might be wrong" while not displaying any of them yourself toward the other side, that might make sitting down and having a reasonable conversation, so all parties can part amicably, very difficult. The resentment that festers in many of these people because GNOME has "disappointed them time and time again" because they had expectations for GNOME that were fundamentally unfair and unaligned with reality and refused to revise them until the acrimony was up to everyone's eyeballs, isn't just going to evaporate into thin air. The toxicity will take time, and most importantly effort at adult communication — instead of airing your grievances on Twitter without communicating directly, and posting ragebait out of other people's quotes — because otherwise, every conversation will look like the one I had with this Hacker News guy.

To see what I mean, what the possible pitfalls and dangers are here, let's actually look at my discussion with him.

When things started, they were insisting that GNOME wasn't just "technically questionable" — something one might productively discuss, with multiple valid viewpoints on the question — but also that the project itself was "shady" because, they claimed, it actively looked for opportunities to "try to make their 'product' look better by actively breaking other people's work." (Yeah, seriously.) They seemed to sincerely believe that the most parsimonious explanation of the facts wasn't just that the GNOME team was just genuinely trying to make their product the best it could be for their goals, but it simply wasn't intended to be used as a basis for other people to build products out of, and that wasn't a use case they had ever said they'd support, so their work often happened to break things for others downstream. No, it had to be active malice — their desire to make something great for users was transformed in this user's mind into a desire to make their product better at the cost of other projects, and the inherent unreliability of using someone else's explicitly internal, unsupported API similarly became sabotage.

They then linked to five "sources," purporting that these evidenced their claims. When I replied pointing out that the things they'd linked didn't support such hyperbolic claims at all — that pursuing a consistent vision for a project and so not wanting to support minor features like official theming, or extensions stable enough for a distro (instead of just an individual user) to rely on between versions, or app indicators, which doesn't seem to justify the dire claims being made, and isn't really that usual of a behavior for a FOSS project, and certainly isn't the same as Microsoft-like lock-in or sabatoging other people's projects — instead of actually responding to my point, by explaining how it was actually lock in, or how it was unusual, or how those features weren't minor, or how downstreams had a right to demand them, this person instead responded with a Gish Gallop. They gave me another ten "sources" no different from the first five, sprinkled here and there with choice sensationalized quotes, clearly expecting that, when confronted with such a daunting litany of the same exact drivel, except now at far greater length, I would just throw up my hands and say, "well you've got so many links, you surely must be right!" It's the classic "stack of paper" argumentation tactic: whoever's got the bigger "stack of paper" (sources) they can point to as supporting their position, whether the sources actually do or not, is presumed the winner.

They clearly thought they would get the last word here, too, because they spent an entire paragraph simply directing absurd insults toward me and anyone else who doesn't hate GNOME (presumably in contrast to their superior intellect and moral fiber for hating GNOME so much!):

Yep. There we go. Saying anything about GNOME that isn't adoring praise immediately draws out the victim-playing accusations of bad faith, and refusal to engage with the actual problems. How dare anybody scrutinize the way GNOME developers treat and conduct themselves around other people [they still aren't really clear on what this conduct is, exactly, beyond claims that refusal to implement desired features is "abuse" and conspiracy theories about GNOME being basically Microsoft; I've never once, even in their sources, something that indicates that GNOME developers actually "treat other people" badly]. Nobody can ask GNOME to listen to them, but everybody else must listen to GNOME. There's genuinely something strange going on with the mindset around the whole project; it's like they've actively weeded out anybody with any functioning empathy, self-awareness, or non-zero neuroplasticity…

They then finished up their tirade with one of the baseless, sensationalized, whiny claims from one of the videos (from the Subsurface developer), who claimed that GTK developers not immediately agreeing to implement any feature they might want to add, or not being ready to constantly be an IT help desk for figuring out how to do things, constituted "abuse," and a little bit of their own added poisoning-of-the-well:

There is no way to get an answer. The only thing you can get is abuse.

It's literally endless.

To reiterate, in reading their own sources, I have never, ever seen anything that constitutes abuse fromt the GNOME developers. At absolute worst, you get a little provoked sarcasm here and there, real milquetoast stuff. So what could my interlocutor mean by abuse here, except simply — like the GNOME team he is claiming is abusive — not agreeing with him. Honestly, it's a perfect strategy, right? Redefine "abuse" to mean basically giving any possible response other than rolling over and agreeing with whatever the other person wants then talk about how the "abuse" is "literally endless" and is the only answer recieved from "the other side." Now anything the other person says can be used as evidence against them of them being abusive, because it just falls into the "responses are endless abuse" trap.

In any case, despite the insults, I really did want to try to have some kind of productive conclusion to this discussion, and I really did see that long list of sources and think "you know what, this could be the point at which my opinion flips again and I decide GNOME are actually bad actors — let me give reading their sources a try." So I spent a long time reading the first half of their sources, in a good faith attempt to meet them where they were at. I was sorely disappointed. There was no actual abuse, no instance of GNOME being needlessly intransigent, and all the arguments were over minor unimportant features, mostly about theming, just like before. The best the sources got was two quotes from two famous people (Linus Torvalds and Drew Devault) saying they don't like GNOME, which doesn't count as evidence GNOME is actually evil in my book. Admittedly exasperated, I wrote a long reply, explaining why I didn't find what they were saying convincing. This time I even wrote my problems in more detail than before, so they'd have more to break down and argue with, instead of my bare assertions, in case they could show me where my reasoning was wrong. After all, presumably, they responded to me in order to convince me, right? Otherwise, why reply at all?

Sadly, they responded in exactly the way I expected they would, given their initial block of nearly identical insults: with more narcissistic projection via repetitive insults. Refusing to exercise a even a neuron of neuroplactiticy to actually engage with my points, consider for even a second that they might be wrong, or even to just argue for their point more clearly, and demonstrating absolutely zero empathy for either my perspective or the perspective of the GNOME team, and with absolutely zero introspection into their own character traits, and without a word of introspection about whether they're really right, or a moment reflecting on the impact of their abuse towards me, they instead expanded on their insults and grandstanded about vague ideals like how "words mean things" and "other people exist" and "empathy":

Tell me more how GNOME are the real victims, and calling out the way y'all treat people is "Gish Galloping" "needless insults and generalizations" and "meaningless petty grievances". Words mean things, you know, and other people exist. ... You hit 4 kilobytes in this defensive rant. And not a single word of empathy for anything you apparently don't personally identify with, not a single thought reflecting on the impact your conduct has on other people. Not a single spot of introspection wondering "Are we really right"?

It's so funny that they complain that I didn't give a "word of empathy" to anyone I didn't "personally identify with," and yet that is explicitly what they're doing with the GNOME team. They literally open the conversation by saying GNOME isn't worthy of sympathy — GNOME shouldn't be able to pursue their own vision for their own project, they should just bow down and devote their freely-given time and effort to whatever the people he personally identifies with (distro maintainers) want, while distro maintainers should have to do nothing themselves in return — and maybe they're right about that, but if not holding sympathy for someone because you think they're utterly in the wrong and bad actors is a valid point of view, then why can't I hold it? It's also extremely funny how he lambastes me for not giving a "single thought" to how my conduct effects other people, as if he cares at all about how he's treating me, or how the entitlement and harassment and hate that the people he supports direct at the GNOME developers effects them (pretty severely!).

Also, all of this completely missing the fact that my very response itself, my reading of his sources and engagement with them, itself indicated I was open to being wrong — but it seems good faith, open-minded discussion with a fellow human being isn't what he wanted. He wanted a public performance of indecision and self-doubt on my part for his benefit, along with a chance to grandstand about how morally superior he is for hating GNOME, and what a moral cretin I am for disagreeing.

And of course his reply concluded with the expected linking of my response to the alleged "abuse" the GNOME developers point at people:

....It really is endless, isn't it....?

At this point, it was blindingly obvious that this person wasn't interested in a real discussion of any sort at all, but was just there to "play to the crowd," whether that crowd was their withered self-esteem and superego needing reassurance, or the crowd on Hacker News, about their virtues. In essence, virtue signaling. So, in response to this, tired of being subject to fallacy after fallacy and insult after insult, and reading through the FOSS equivalents of tabloids airing petty grievances between entitled assholes and GNOME, I finally responded by shutting down the conversation:

[me:] I think I'm done being a footstool for you to grandstand about what a great person you are from. You can find a different dance partner to virtue signal with.

To this, this narcissist replied with more narcissistic projection, of course:

I suppose I should be unsurprised that you would pretend that's what it's about. Assume everybody's as selfish and disingenuous as you, yeah.

Believing projects should be free to pursue their own goals, and not subject to constant harassment and entitled demands for doing so, and that people who want an all-purpose toolkit to build their own desktop environment with should probably go somewhere other than GNOME — perhaps a fork of it maintained and modified by a consortium of previous users of GNOME like Mint, Budgie, System76, Ubuntu, etc, or even a totally new DE, like what System76 is doing, which I think might actually be the right long term move! — is apparently "selfish," and having the emotional intelligence to spot when someone is arguing in bad faith means I'm disingenous. Obviously, idiot.

The lesson to be learned here is that it isn't just GNOME's side that lacks empathy or introspection or neuroplactiticy, it's also the people who have decided to become dyed in the wool haters of GNOME as well. For instance, the people who created that misleading, spurious, and ill-considered proposal to switch Fedora to KDE as the default, despite Fedora being The GNOME Distro, on the basis of misleading and/or irrelevant claims. Giving in to petty instincts like this will get us nowhere. In order to achieve the bright future I see possible before us via KDE and COSMIC, and finally bring some peace to the lands of the Linux desktop, we have to be willing to put aside petty and manipulative grievances and try to set reasonable expectations, respect each other — and not the subordinate sort of "respect" the GNOME-haters demand from GNOME, where GNOME acquiesces to their every demand for convenience, but real mutual respect, like actual human beings — and try to find a proper solution.

Things can get better. There is hope. There is always hope in the Linux world, because on the internet, nothing ever truly dies.

Appendix B: The Sources

Click to see an in-depth analysis and breakdown of key points from the sources provided to me, to support the generalizations made above

Don't use a notification area in GNOME 3

The earliest of the sources sent to me by my 'friend' is a ticket on the Transmission application from 2010. In it, a GNOME developer offers the author of Transmission a heads up that GNOME 3 isn't planning to support notification area icons, and says that since the option to do that will therefore no longer be cross platform, it should probably be removed. This is probably a bad idea, to be fair, but I don't think leading with that suggestion is really all that heinous, since the idea of a cross-platform app is to support the common denominator features between the platforms, at least if you don't want to add flags to adapt. After pointing out this is probably a bad idea, the author of Transmission says:

In order for this ticket to move forward, I'd like you to tell me what change should be made to Transmission that will make it work properly, out of the box, on GNOME Shell, Unity, and XFCE.

Obviously, at the time he wrote that, that just isn't possible. The entire point is that they've all got different features, so unless you want to have three separate versions, or remove the feature, you'd have to only support one way of doing it and not have the feature on the others. Seeing this, the GNOME developer points that out:

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

It is my hope that you are a GNOME app. Yes this kind of fragmentation is unfortunate. I'm not happy about it either. Anyway, I just wanted to give you a heads up. Wish you the best.

I think this is a totally fine and fair thing to say. It's true that they can't/wont' support all three, and so the GNOME developer points that out, admits it is unfortunate and that they aren't happy about it either and that it isn't ideal, and humbly says they like the app and hope it'll be on GNOME. They also confirm what was clear from above, that this wasn't a demand or even a request, nor a really thought through premeditated thing — the GNOME developer was just trying to be helpful, letting the Transmission developer know what the problem was, and trying to offer a simple solution along with the heads up, as is good etiquette for issues. The fact that they didn't offer a more involved solution isn't really on them, or a sign of malice, in my opinion.

Does Charles react normally to this? No. He reacts by melodramatically performing his shock, his shock, that the GNOME developer had the gall to say he'd have to choose, as if they had any control over that. The GNOME developer offers his sympathies again, but points that out. A month passes, and then the same GNOME developer and another one show up to offer a more fully realized solution this time, seeing how at a loss Charles was.


The solution for GNOME 3 and the GNOME 2 fallback is the same: use a notification when the notification daemon supports persistence. Both the GNOME 3 and 2 fallback notification servers support persistence. So, the guidance from GNOME is consistent here and you shouldn't need to support two separate code paths. As for Ubuntu, I can't say. If you don't want to maintain an Ubuntu specific implementation they would probably maintain the patch in their packages for you.


Jordan asked me to make a comment here.

2 things need doing:

  • Add a tiny bit of code to gtk/notify.c to check whether the notification server has the "persistence" cap (just like is done for the "actions" cap in can_support_actions()), and export it in notify.h

  • If gtr_notify_has_persistence() returns TRUE, hide the preference for showing status icons, and just never show a status icon.

This should be enough to make transmission behave well with gnome-shell, and the GNOME 3 fallback. notify-osd doesn't support persistence. The only problematic one would be Mint if they had a newer notification-daemon, which they shouldn't if they're sticking with GNOME 2.

In response to the very idea of being required to support a GNOME-only feature, someone on the forums accuses GNOME of being "diseased":

Rant: I don't know the exact kind of disease someone's spreading in GNOME project since GNOME2 concept days but the feature of dropping every feature someone else might find useful is what should bury that clone project in the long term, and the less people are involved the better.

And morally grandstands about how great they are in comparison, because their products don't have a vision to them, they just do whatever users ask:

PS: my free software is about actually helping myself and others, not about forcing my stupid "brilliant" views onto each other's head and down their throats. It's also about educating people, not about helping those trying to dumb us down and look smart. It's about UNIX simplicity and elegance, not about mind-boggling chunks of ​MSDN camp type code.

So far, this seems frustrating, but isn't diversity of desktop environments, each having differing philosophies and ways of handling things, something the GNOME haters want? If so, this is the sort of world they'll inevitably have to deal with. I don't think calling DE developers evil every time their DE isn't perfectly feature-compatible with another is productive, and I don't think the GNOME team acted in a particularly negative way here. Yes, I can imagine it's deeply unfortunate and frustrating for Charles, who has all these added things to worry about, and I can see why he'd be frustrated with GNOME, but fundamentally I don't think that should mean application developers get to dictate to DEs what features they have.

Rotting in Threes

The second source linked is a post called "GNOME (et al): Rotting in Threes," from the blog of someone going by the tag "IgnorantGuru" (username checks out).

Some of the things you’re about to read should make your hair curl and your blood boil.

Off to a good start: telling the reader how to feel, instead of how you feel.

Theme development is a tedious and difficult task, and for the GTK devs to be so careless in breaking their API at every turn disrespects the many hours people put into making themes for it. Yet as I read some of the GNOME developer comments below, I was given to believe that this breakage stems from a Microsoft-like climate of preventing users from customizing their systems...

Wanting to create an open source project that focuses on delivering a consistent vision and user experience, and so doesn't have enough "customizability" for some people, is "Microsoft like" now? I wonder what this person thinks of the suckless people. Surely he'd condemn them too, right? Or is this only a standard foisted upon the GNOME project?

Additionally, yes, developing something that is explicitly not supported, using an explicitly internal API, is going to be tedious and difficult, but that doesn't mean that every single open source project should be forced to slavishly ensure the backwards compatibility of every internal API someone (or even many someones) happen to want to use. That's absurd. If you have any API at all, someone will try to use it, but the amount of work they put into that doesn't give them a claim on the work of anyone else, or on upstream projects, and it's just so absurd for them to complain melodramatically about how hard it is to use internal APIs to do unsupported things with software because they break so often. You should have been aware of that going into it!

...and deliberately breaking the work of others so that your ‘brand’ is the best.

Ah, so that's where the person on Hacker News got this claim. I wonder whether they are this IgnorantGuru person, or if they've just been duped by him? In any case, just because other people built something on top of your project, which explicitly was not designed for other people to build that kind of thing on top of, that doesn't mean that when you working on your own project happens to break the things other people built on top of it, because you want your project to be the best it can be, that you're deliberately sabatoging other people's work. That's absolutely ludicrous.

Can anyone now run up and start building things on top of your open source project, without you asking them to, and directly flying in the face of the stated purposes and goals of your project, and then point the finger at you and scream like a banshee in protest about how they've been sabotaged, sabotaged I tell you! because the thing they should've expected to happen, gone in knowing would happen from the very start, that the person who makes a project continued developing their project according to their own freedom, had happened? Does just randomly showing up out of the blue and piggybacking on someone else's work now give you the right to demand more work from them? Does it give you the right to set the goals for the projects other people give their labor freely to, to direct others' free labor?

That seems to be the logic here.

Anytime I hear the word ‘brand’ being used in Linux, I know something valuable is being poisoned.

This is just bad faith poisoning the well in my opinion — latching onto a corporate-sounding word as evidence of the person using it being the root of all evil, when in reality, if you're trying to make something for people who aren't necessarily enthusiasts who will research everything to death, marketing and brands are an inevitable part of that: you need to find some way to communicate who you are and what you're about to people if they're going to find out about you, after all. This isn't even mutually exclusive with believing in your project and wanting the best for users, it doesn't have to be driven by any sort of profit motive, nor does it have to be at the cost of anyone else.

Yet what I’m hearing is that with GNOME v3 the goal is to promote their “brand” and make it dominant, in part by greatly limiting what users can change on their own systems, and partly by breaking or simply removing whatever support they’re no longer promoting as ‘The Way’. The reach of this selfish and narrow-sighted development goes beyond GNOME and affects GTK apps in general.

As I said before, wanting more people to use your open source project is fine, as is having a "brand." This is just bad faith. Likewise, as I've also said before, having a precise, specific, directed vision for your project, and culling anything that is out of scope or conflicts with that vision, even if that vision is minimalism, isn't something evil. It's not "selfish" or "narrow-minded," because they're not forcing anyone to use their project.

I genuinely understand that might be really inconvenient and frustrating for many users, and that's genuinely unfortunate, and I don't agree with many of the specific decisions GNOME made, especially prior to the 40 series, but the amount of hyperbolic crying about this is absolutely insane. There was a fork of GNOME 2, why not have everyone who doesn't like nuGNOME switch to that en masse, both as users and contributors, and really show GNOME what for? GNOME really doesn't have that many more people or resources than any other DE, it's not like no one can hope to match them or anything.

Stop trying to enforce your vision on a project when that simply isn't what the project is, and go use something else.

That's the entire point of open source: letting everyone scratch their own itch, trying to build the best version of the thing they want that they can, and if you disagree, you have the ability to take someone else's project and make it your own — the ability to walk out, and take everything you need to get started with an alternative with you (the full source code and documentation).

Would it really be fair of a vocal contingent of people to, for instance, show up at the door of Void Linux, or Alpine, or the suckless people, demanding that they add incompatible features or fundamentally change how they do things, just to suit them? I think if that happened — if, for instance, GNOME users flocked to KDE and started demanding that they remove features — you would be able to clearly identify the problem, but yet, somehow, when it comes to GNOME, the same logic doesn't apply?

Windows devs seem to be arriving as well, bringing their diseases with them – corporate ‘kill off the competition’ mentalities that don’t serve Linux, merely exploit it.

Calling GNOME devs "diseased" "Windows" developers — really great of you. I wonder if IgnorantGuru is the same person as the one that accused GNOME devs of being from Microsoft and being diseased in the previous article. Almost certainly not, to be fair, but it is interesting how often these thought-patterns repeat. You'll see more of them, too!

The rest of this continues in a similar fashion: quote after quote this blog author is completely outraged and shocked that the GNOME team has a consistent vision for their project, instead of wanting to acquiesce to the demands of the mob, and cares about a consistent experience for users and "branding" and "marketing." See for yourself:

GTK3 isn’t a reliable API. Maybe it should be called libgnome instead. GTK3.4 came with Gnome3.4, and wasn’t compatible with previous GTK3 themes. This means all GTK3 applications looked really ugly not only with all the GTK2 themes which don’t support GTK3 (almost all of them), but also the few which did.

Not being a reliable API, and not being a reliable API for theming, an explicitly unsupported functionality achieved using internal APIs are entirely different things, but here whoever wrote this quote is equivocating between them to make GTK 3 seem much worse than it is. This is a pattern we will see often.

I’m no longer interested in zenity because with Gnome 3 updates, it lost some features, and I had scripts not working as they should. I didn’t understand why. Even the zenity docs were not updated about removed features. I had to search in bug reports to find that developers removed some features that were no longer considered useful with the new Gnome Shell paradigms. Wow. So devs think that zenity is Gnome Shell only? It can’t be used in other environments? I was very frustrated. ... there’s clearly an adoption of a very closed-source way of functioning, more and more disconnected from users and obsessed with brand control.

Zenity is explicitly a GNOME-only project. Not only is it hosted on GNOME's version control system, something I doubt was different in 2012, wherever they hosted their stuff back then, because project self hosting of source was even more common back then, they even say: "This is Zenity: the GNOME port of the venerable 'dialog' program, which allows you to display dialog boxes from the command-line and shell scripts." It is the GNOME port of an existing tool. So yes, of course it is GNOME only. Of course they don't feel the need to notify users about a change ot an internal tool.

it’s such a pain to develop a GTK 3 theme. It’s always broken. I have a version of my theme for GTK 3.2, one for GTK 3.4, one for GTK 3.6. I’m so tired of that. For GTK 3.4, it was so broken that I had to code it again from the beginning. Days and days of wasted time and frustration.

I get that sucks, I've tried to make DE themes before and it is a shitton of work, and I really respect the dedication involved in trying to make a theme for others as a result, but this really isn't something you can blame GNOME for. They tell people up front constantly that this isn't a stable API or intended functionality, so complaining when the API isn't stable and the functionality isn't intended and so it causes you to have to do a lot of work feels like shooting yourself in the foot with buckshot and then complaining there are holes in your foot.

I’m sorry to say this but I am abandoning any GTK3 theme making from now on. Upstream is impossible to work with and GNOME 3 has become a complete mess in regard to third party theme making. ... Honestly, Windows and OS X actually look more attractive to me right now.

This seems like an incredibly hyperbolic statement probably made by someone who's burned out after pushing themselves too hard. I have a lot of sympathy, but this doesn't really constitute good evidence either.

The problem therein is why should we as supporters of Gnome who gave our time for free get slapped in the face with new theme requirements and our work broken and failing to do more work at out own time to support something where the requirements could change again in another 6 months or less and again break our new work? It’s a real pickle no doubts there!

GNOME never asked someone to theme their stuff, nor does it help them, in fact it only leads to more spurious bug reports and complaints for them, and is something they have asked people to stop doing and don't think is a good idea, so theming work isn't "supporting GNOME." This attempt to make it seem like you're giving to GNOME out of the goodness of your hearts and are getting slapped in return is misguided. You're giving out of the goodness of your heart to your theme users at best, and you should've known up front what using an internal unstable API involves.

How can anyone remain interested in a system developed by devs who don’t care about their users? Do you know what GNOME devs think about themes and extensions?

Does GNOME not care about their users, or just "not care" about the users that want something fundamentally different from their DE than what they're even trying to provide?

Below are some tasty answers from Gnome Shell devs, considering users only as walking billboards

Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design. We’ve fought long and hard to give GNOME 3 a consistent visual appearance, to make it synonymous with a single user experience and to ensure that that experience is of a consistently high quality. A general purpose extensions and themes distribution system seems to threaten much of that.

How dare a project try to have a consistent stable visual appearance and user experience so people can orient themselves and so they can provide quality assurance and proper UI/UX design, and ensure users don't get deluged in distro crap like Android users are deluged by OEM crap?

One particular issue is the ability for users to modify the top bar via extensions. This part of the UI is vital for giving GNOME 3 a distinctive visual appearance. If we do have extensions, I would very much like to see the top bar made out of bounds for extension writers, therefore. We have to have at least something that remains consistent.

This sounds like a marketing thing, but I think there's a real point to be made here about orientation too — if nothing can remain consistent, users are likely to get lost far more easily.

Firefox has indeed profited from extensions and there are lessons that we can learn from that. GNOME Shell isn’t a browser, though. We need to be mindful not to adopt the Firefox model without considering the ways in which our needs might differ. ... The point is that it decreases our brand presence. That particular user might understand what it is that they are running, but the person who sees them using their machine or even sees their screenshots on the web will not. The question we have to ask ourselves is: how do we make sure that people recognise a GNOME install when they see one?

I'll admit I don't really care about "brand presence," but I don't think it is unfair or evil for an open source project to care about their brand. That doesn't make them a for-profit company. This is only evil if you assume GNOME doesn't have the right to want to make an end-user product, and determine what use-cases they do and do not want to support, but must instead act as a meek toolkit for downstream developers to use to construct whatever desktop experience they want. But that simply isn't what GNOME is.

We’ve always argued that if it is anything, GNOME is a UX. There might be a case for letting people tweak things here and there, but I really think that every GNOME install should have the same core look and feel. Otherwise, what is it that we are doing in the first place?

And I think the fact that their core concern is with being able to do quality control — to ensure a good clean user experience for their users, shines through here, despite the marketing-speak above. And again, while the lack of configurability in macOS or Windows is really awful, because users are locked into their platforms, GNOME is an open source desktop environment, one of many users can easily choose and switch between all without even reinstalling their operating system, so GNOME rigidly pursuing its vision simply doesn't have the same implications as macOS or Windows doing it.

For example, Gnome Shell doesn’t support status icons, so GNOME dev ‘mccann’ filed a bug report to a Transmission (BitTorrent client) dev to say that this option should be removed. Why should it be removed? Because Gnome Shell doesn’t support it anymore! Apparently in GNOMEland there are no other desktop environments (remind anyone of Microsoft?) From Don’t use a notification area icon in GNOME 3...

We already covered this one.

More quotes of the quotes the author of this blog thinks are evil:

I think one of the most important cases against applets (as they are currently defined in GNOME) is that they are extremely detrimental to the Identity of the product or platform. Today, our entire desktop identity is defined by a configurable number of horizontal or vertical bars filled with any number (even duplicates) of random Things that may launch stuff, open menus, open dialogs, operate on windows, switch workspaces, and more! Boxes-o-crap as I lovingly (in the eulogistic sense) refer to them. Each time I see “Remove from panel” when I right click on the notification area or the menu system I weep and my mascara runs and god is it awful.

I think this illustrates really well the core UX insight at the core of GNOME: visual information overload sucks for a lot of people. Some people like it, but others would prefer an experience that isn't like that out of the box and isn't designed to end up that way.

Let’s say that we are trying to define either a product or a product platform. I don’t think it is possible to do this without some “brand” coherence. And it is arguably impossible to do this effectively with such an ad-hoc/individually-customized design identity...

So, one of the many very exciting things about GNOME Shell is that for the first time we may have ability to really shape the user experience and form an identity for the GNOME platform.

Can't have someone wanting to actually be able to directly shape the user experience of the desktop environment they're spending all this time and energy designing and doing UX testing for, right? That's obviously evil. And god forbid someone wants to have some visual and UX consistency between instances of your platform, and a visual identity so people can identify you and know what you're getting, an integral part of actually making all the different projects in the world legible to the average user so they can choose between them.

What follows is an endless litany of outrage over the various features GNOME removed in the process of paring back and fundamentally redesigning their desktop environment — almost all of which, I might add, have been added back, either putting the lie to the claim that GNOME doesn't listen to users, or putting lie to the claim that they didn't mean to eventually bring back those features in a new way. See, they were fundamentally redesigning their UI and UX from the ground up, so of course they would have to remove. You can criticize the project on the grounds that these are bad decisions, but not say they're evil for making them.

The author also quotes some things from GNOME developers saying they view the GNOME "Fallback" mode as a distraction that makes the user experience of their desktop environment worse, because it means you'll end up with a whole island of users camped out on something that was only supposed to be a temporary band-aid for people who couldn't function without a familiar interface, an fallback mode that inherently has no future because that's not the direction GNOME is going in, meaning GNOME would either have to maintain both, or just deal with the consequences of that, and IgnorantGuru interprets this as the GNOME developers seeing fallback mode as "competition" in a business sense that they must extinguish like Microsoft does or something, and files it away as further evidence of their evil:

“the presence of fallback mode is having a negative impact on the quality of the primary GNOME 3 user experience”

See also this report: (fallback) [meta] Remove fallback support code

At some point, the author loses track of the focus, and starts ranting about actually bad behavior on the part of Canonical/Ubuntu: not just not implementing features people want (the horror!) but actually closed sourcing things, collaborating with Amazon, giving away user data, etc. This is all actually bad behavior, but it being here, alongside GNOME's comparatively innocent and completely tame behavior, treated with equal scrutiny and ire — and covered in far less space! — really demonstrates this author's total lack of a sense of proportion. So let's move on.

Torvalds pours scorn on De Icaza's desktop claims

This one is pretty easy. It's a tabloid-tier article from "IT Wire" about nothing more nor less than Linus Torvalds clapping back against a meagre, milquetoast comment a GNOME developer made on Google+ that he didn't like. It doesn't even really have anything to do with the other complains about GNOME. Lets first read the statement that Torvalds doesn't like:

In my opinion, the problem with Linux on the Desktop is rooted in the developer culture that was created around it.

Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers. The kernel people might have some valid reasons for it, and might have forced the industry to play by their rules, but the Desktop people did not have the power that the kernel people did. But we did keep the attitude.

The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees.

And we did.

We deprecated APIs, because there was a better way. We removed functionality because "that approach is broken", for degrees of broken from "it is a security hole" all the way to "it does not conform to the new style we are using".

A completely milquetoast take, one that honestly I could go either way on — agreeing or disagreeing. I think there's something to be said for a culture of engineering excellence, so we don't end up bloated crapware like macOS and Windows, or saddled with bloated crapware of our own like Xorg, but there's also something to be said for the sheer consistency and commitment to backwards compatibility of Windows (although not macOS).

What sin does this commit? Let's hear what Linus has to say:

The gnome people have their problems. They do seem to like to blame pretty much anything but themselves. ... The gnome people claiming that I set the 'attitude' that causes them problems is laughable.

Two insults, okay, that's par for the course for Linux, to be fair.

"One of the core kernel rules has always been that we never ever break any external interfaces. That rule has been there since day one, although it's gotten much more explicit only in the last few years. The fact that we break internal interfaces that are not visible to userland is totally irrelevant, and a total red herring.

Funny that he brings up the red herring fallacy, because that's exactly what he's doing here — the GNOME developer's whole point is that there wasn't any stable interface for drivers to interoperate with the kernel, presumably causing worse driver compatibility — just look at how often NVIDIA's proprietary drivers, which have to try to link up to the kernel's internal binary ABI, break.

Now yes, Linus is right that he also has had an impressive long-term commitment to maintaining external interfaces — the classic "never break userspace" — and so he probably isn't at fault for this tendency in the Linux world to break interfaces, or at the very least that his legacy is more complex and multifaceted than simply him being at fault for that tendency, so I would agree that, overall, this GNOME developer seems a bit ignorant of kernel development, and a bit ungrateful to our lord and savior Linus Torvalds.

In general, the statements from the GNOME developer do seem a bit hypocritical considering how GNOME would later operate, and in general it's just a lukewarm and mildly ignorant take, but one a great many other Linux users have made over the years — but what, exactly, is this evidence of? That people have bad takes, or can be hypocritical sometimes? I mean, yeah, absolutely. But I imagine Miguel's own views have changed to align with his actions post-GNOME 2, and honestly this doesn't prove to me the whole project is bad or that he's a bad apple or anything.

Linus continues with some unoriginal digs at the GNOME project in return (perhaps fair game given the way Miguel talked about him):

"I wish the gnome people had understood the real rules inside the kernel. Like "you never break external interfaces" - and 'we need to do that to improve things'" is not an excuse.

"Or 'different users have different needs'. The kernel was - and is - happy to support both the SGI style thousand-CPU machines and the embedded vendors with cellphones and routers. The fact that they have different needs is very obvious.

"I personally think that one reason that the Linux kernel has been so successful was the fact that I didn't have a huge vision of where I wanted to force people to go. Sure, I wanted 'unix', and there are some very high-level concepts that go with that (fork,exec,files etc), but I didn't want to enforce any particular world-view outside of that very generic pattern.


"That's exactly the reverse of the gnome 'we know better' mentality, and "We will force Corba/.NET down your throat whether you like it or not, and if you complain, you're against progress, and cannot handle the change'..."

"Some gnome people seem to be in total denial about what their problem really is. They'll wildly blame everybody except themselves. This article seems to be a perfect example of that."

I'm not sure what that line is really worth, it's just playing the same annoying blame-game the GNOME developers played — and I think it is equally untrue in both cases — but the rest is just the usual complaints about GNOME focusing too strictly on pursuing the refinement of the one workflow it's after, and claiming that implementing a feature in their own project that people can easily switch away from if they don't like because unlike Windows or macOS you can easily switch DEs or even entire Linux distributions, there isn't vendor lock-in, is somehow "shoving" things "down user's throats."

Honestly, again, this is just more evidence that people don't like GNOME, but not really evidence there's a solid reason for it, that there's a real problem or actual abuse coming from them. People are occasionally hypocritical and occasionally have slightly bad takes once or twice in a decade. That's fine. It isn't a heinous crime.

Work with theme authors

This next one is a real doozy. It's IgnorantGuru again, this time opening a general philosophical discussion thread with a clear ax to grind, one likely to lead to flame wars, in GNOME's bug tracker, inviting his friends to join the party, and then acting surprised and upset when a GNOME developer tells him that this isn't the place for his shenanigans.

It begins with this post:

IgnorantGuru: As a general but substantial and well-evidenced issue, I believe your dev team should examine why you are repeatedly and carelessly breaking themes with every minor gtk3 release version

"Examine why?" They know why. You just want them to change their minds about their own goals for their own project, but don't hide it behind obfuscation like this.

This makes it very hard to develop a stable app in gtk3 despite the core api seeming to perform well,

If the core APIs are stable, then it should be very easy to develop a stable application, it's just the themes that are unstable — breaking your app, and other apps, because they haven't caught up with the internal API they're hijacking... also, why the hell is that an application developer's concern anyway? people choose to theme their desktops, yes, but you're not responsible for every single theme someone decides to slap on your application, downstream of you, that isn't part of your application, nor is it part of your mandate. This is just a transparent attempt to conflate applications with the themes that may sometimes be applied to them, so that if a theme breaks it becomes tantamount to the application itself not working (despite it working just fine under the covers, and the theme being the broken thing added on) in order to make this annoying discussion about themes seem more important.

and also wastes the time of theme developers - you can see the frustration they're expressing, and their comments that "upstream is impossible to work with"... Many are simply giving up on gtk3 as a result.

Right, because GNOME has made it clear theming isn't officially supported. So what? Like, yes, it sucks that it's so much work to keep up, but again I don't see how this is anyone's fault but their own, or why that gives them a right to demand the GNOME people act a certain way.

As an app developer, with a new port to gtk3 in testing, I'm already seeing many bug reports caused but this issue alone - theme breakage due to poor maintenance and lack of consistency on your part. What good is an api which breaks so frequently that everything is almost always in a broken state?

Poor maintenance on GNOME's part, and not the themes'? What DARVO shit is this...

Giving you the benefit of the doubt that this isn't being done or ignored deliberately in some effort to support gtk3's use within gnome exclusively (as some are saying), it seems strange that you would put the effort you have into making gtk3 very stable and usable, really excellent work in many regards, and then destroy the usability of that work with careless theme api breakage. The theme is ultimately what the user experiences.

After accusing the GNOME team of wanting to break other people's things in a very Trumpian way (as some are saying, while linking to their own block that says exactly that), they of course finish with a patronizing and moralistic remark:

Remember to step back and examine systemic problems in your dev team, rather than just repeating the same mistakes and looking myopically at issues in isolation.

Of course, rightly, the GNOME developers point out that this isn't actually a bug that's been put on the bug tracker that's for bugs, not discussions:

Emmanuele Bassi: is there an actual bug, in that wall of text, or are you just venting for theme changes?

... bugzilla is not a place for introspection. you are also operating under the impression that there are "lead developers".

if you have specific bugs and regressions, you're strongly encouraged to file them - along with test cases, if possible, so that they can be caught by the test suite.

if you're just venting because the themeing classes, which are not currently under any stability promise, change while we fix bugs then the gtk-devel-list mailing list is a better option for you to be heard by anyone beyond your echo chamber.

To which IgnorantGuru replies, Orwellianly:

This is a very specific bug, it's just broad. You don't seem to be addressing it at all.

I still think an effort to analyze this severe problem is in order, not just wasting time in a long discussion and denials of the problem on the mailing list - I don't have time to correct your development problems, sorry. I'm just reporting the issue to you in the hopes that you would want to address it.

I'm not sure what exactly IgnorantGuru thought would happen differently on a bug tracker than a mailing list, especially since features that aren't intended to ever be implemented aren't bugs, and the GNOME people seem a bit confused too:

we have two wildly differing definitions of "specific", I am afraid. again: if you have specific instances of things that broke between 3.4 and 3.6 (old stable and current stable) we'd like to get bugs detailing them. ... if you don't have time to deal with bug reports then I don't feel very much compelled to answer broad questions that are more suited to the development mailing list than to bugzilla.

To which IgnorantGuru grandstands about how mean GNOME is, but does offer the possibility of getting some specific bug reports:

Very well, I have changed this to UN-RESOLVED so you can get some further info from theme developers. I asked some theme developers I know to add some details, but they said they have wasted too much time trying to get you to fix anything, and simply refuse to be "fooled into participating" anymore. That's quite a relationship you have with gtk3 theme devs, many of which I know to be very conscientious and helpful contributors. You must have done some number on them to alienate them all the way you have - nice support work. I guess the fact that people are saying that gtk3 "upstream is impossible to work with" means nothing to you, and doesn't indicate any problems in your dev team.

A bit later, Benjamin Otte helpfully shows up to explain himself candidly about the themes, as IgnorantGuru asked:

Hi, I'm the guy that has spent the last two years breaking themes with every release. This is 100% deliberate and I intend to continue this process for the forseeable future. I've been very open about this and told this to all the people that have asked me about it (read: not you) and done so repeatedly. So it's not a new thing.

But because you asked, again, here are the reasons for why this choice was made:

(1) Moving the theming code from its antiquated underpowered gtkrc format to a web-inspired CSS format respecting the CSS box model that can be animated is not a simple task that can be done quickly. And if done slowly, it likely can't be done without breakage.

(2) GTK doesn't swim in extra developers that are happy to spend their time ensuring compatibility with rarely used themes. I decided the time was better spent implementing new features than caring about other themes.

(3) All the theme authors participating in GTK development (read: not you) agreed that it's better to keep their themes up to date if in exchange they get new features than keeping with the status quo.

(4) After those decisions were made, no time was spent on even thinking about compatibility, because there were no people even bringing up the topic, let alone willing to work on it.

And this is why lonely blog posters on blogspot or the mint dev blog (read: you) get all sad and ranty when they don't participate upstream and then decide to only use GTK2 apps.

I'll let you decide who's in the right here: the person grandiosely moralizing, pretentiously and patronizingly telling other people to "examine their systemic problems" for not doing everything they want, hyperbolicly inflating the importance of themes, and claiming "no one said" theming was unstable, or everyone else in this thread.

The discussion branches off from here, debating the specific merits of stability in a theming API in the context of 2012's alpha version of GTK+ 3, and it doesn't seem really that interesting or relevant to the broader discussion here, except to say that it's yet another case of GNOME wanting to do something with their project, and people who built something on top of it (themes) that were explicitly told what they're doing is unsupported because it would simply take far more time investment than it would be worth, and that it was using an unstable internal API, are annoyed GNOME is doing their thing. I think this quote just sums IgnorantGuru's whole deal up, really (from IgnorantGuru himself, in the comments):

Despite your wall of bullshit, the uncensored, unprepared quotes in the article make you quite transparent.

As I just covered above, these quotes don't really show what Guru seems to think they do. He's reading way too far into every little thing to try to justify the worst possible interpretation, but none of the quotes seem to justify his believe that GNOME is trying to act like Microsoft and "embrace, extend, extinguish" the Linux desktop or anything like that. At worst, they show a group of people with a slightly more design and marketing focused mentality than your average Linux developer, which is perfectly fine — there is space for that in the open source community.

You come from that crowd of elitist corporate developers who would control users, not empower them.

Disempowering users would be taking away their choice of distro or desktop environment in the first place. Offering users a well-designed, curated, focused DE alongside all the other options is not a desire to control people, because people can just pick up and leave. Moreover, the simplified user experience of the GNOME desktop environment could only betray an elitist attitude if they were designing it for others to use, but viewed themselves as too good for it, but that's not the case. If anything, GNOME is designed just as much for the developers that create it as via user experience research, interviews, and surveys.

As an analogy, if you were a doctor, you would be prescribing toxic drugs and using your professional associations to undermine alternative healthcare. If you were a food designer, you would be making processed foods loaded with toxic chemicals and GMOs, and putting your corporate insiders in charge of regulatory agencies. In your elitist ‘high priest developer’ crowd, the user is just a resource to be exploited at all costs, talked down to, and controlled.

And here we see the general mentality this person has. The logic they are applying here, by their own admission, also leads them to this logic. So now I ask you — is it good logic, if by his own admission these beliefs are also analogous?

You may notice, if you read the bug tracker thread, that it seems that the GNOME people know who IgnorantGuru is, and are actively ignoring him. Why are they doing this? Well, besides the fact that he's very obviously doing some semi-polite form of trolling, trying to start moralizing philosophical arguments about vague general issues and talking down to the GNOME developers in a bug tracker instead of the mailing list that's actually for discussions of that nature, it's because he has a long history of becoming obsessively angry at various projects (just scroll through a few years of his blog) and showing up on forums and bug trackers making wild abusive conspiratorial accusations and distorting the facts and then whining about "censorship". In fact, he was still doing this years later, too. Let's actually take a look at that blog post:

I submit the following for your review because it’s an interesting case study in how Red Hat developers are running the GTK+ bugtracker, censoring non-flattering input, and misusing their code of conduct. Since they deleted several of my comments, and threatened another participant merely for using the word “overengineered” (lol – if the shoe fits…), I thought it might be valuable to bring what they deleted to larger attention.

Well, okay then — claims of "censorship" and "misuse of their code of conduct" seem really bad; if true, these would be serious marks against them. But if we've learned anything about they internet by now, we know that people complaining in a side channel about how they got "censored" on another internet platform for innocent behavior are often not innocent, and often not summarizing what they did correctly. Guru is claiming this partially on behalf of another person, but I think the principle still applies, so to find out what really happened, we'll have to read the bug tracker transcript itself, and come to our own conclusions. But first, let's look at how he summarizes the initial interaction:

The case in study is a bug report regarding the way the GTK+ file chooser (file browser) only shows FUSE mounts made by gvfs, and is blind to those made by almost all other file managers. This is a simple bug. All that needs to be done to fix it is add the traditional location used for fuse mounts to the heuristics – a 5 minute job. Yet instead of simply fixing it, first a Red Hat employee immediately closes it as “RESOLVED WONTFIX” with a “No.”

What actually happened, though?

Description Psy[H[] 2015-05-31 19:30:12 UTC $HOME/.cache is a logical place for applications to place user-level mountpoints such as FUSE filesystems. Those should be visible in GtkFIleChooser. Right now it seems to exclude all hidden dirs in $HOME from mountpoint search. $HOME/.cache should be whitelisted.

Comment 1 Matthias Clasen 2015-06-01 16:06:23 UTC

No. XDG_CACHE_DIR has defined semantics that don’t match mounting things.


Alright, so already it's clear he's lying. This is no simple bug, but a difference in design philosophy, and the "bug" is closed as a direct result of that, because the GTK developers want to adhere to the defined FreeDesktop semantics of things, and this person wants an exception added for convenience. Let's see how things continue:

Comment 2 IgnorantGuru 2015-06-02 15:18:22 UTC

I realize that GTK development is effectively dead for non-Gnome projects, but you may wish to consider that several widely used XFCE and LXDE file managers which use GTK, such as Thunar and PCManFM, as well as other programs, do mount fuse and network filesystems in XDG_CACHE_DIR, and have done so for years. This is common usage, and not every GTK project follows Freedesktop specs to the letter ... Otherwise it is blind to them and fairly useless outside of Gnome. ... Just quoting the specs and ignoring common usage to avoid updating it just makes the file chooser irrelevant for real uses. Is GTK now documented as a Freedesktop/Gnome-only project? You have several non-Gnome file managers using GTK, so perhaps supporting their uses as well as Gnome would be appropriate.

Here we find IgnorantGuru showing up out of the blue on a bug tracker for a project he hates, to sling insults and conspiracy theories (adhering to a well-documented cross platform specification for how things work is not being "GNOME-specific", and adding exceptions just to accommodate common usage could actually cause more bugs and issues in the long run) peppered throughout his requests for change. Maybe his requests would have been considered, had he made them in a reasonable manner, even if they'd be a bad technical decision contrary to how GTK wants to work, but obviously he's never going to get anywhere acting like this. A few key points are raised in response to him, though:

Comment 3 Matthias Clasen 2015-06-02 15:41:20 UTC

Right now it seems to exclude all hidden dirs in $HOME from mountpoint search. $HOME/.cache should be whitelisted.

The file chooser does not do any mountpoint search at all. We rely on gvfs to provide this information.

GTK development is effectively dead for non-Gnome projects

GTK development for non-gnome projects depends on developers from those projects participating and making their needs heard.

The file chooser as it stands apparently ignores all hidden directories, which > doesn’t leave good options.

That is not true.

They aren't even asking for functionality in the right place! Let's read further. Psy and Guru both insist that GtkFileChooser is able to find mountpoints on their system without GVFS, to which Emmanuele explains:

If no GVFS is present, the fallback code will list the Unix mounts coming from /proc/mounts or /etc/mtab; each mount point will be checked via g_unix_mount_guess_should_display(), which will return TRUE for user-accessible mount points under /media, /run/media/$USER, or directly under $HOME.

If you want your mount points to be visible in the GTK file chooser and you don’t have GVFS running, you should mount them under “/run/media/$USER”.

So there is a fallback for when GVFS is absent, but it expects them to be listed in a different way. Emmanuele does admit there's a bit of a bug there, however, although it would have to be fixed somewhere else, not on this tracker, so this thread should already be closed in my opinion:

The bug in GIO is that the code doing the check hardcodes /run instead of using XDG_RUNTIME_DIR. If XDG_RUNTIME_DIR is unset, it should fallback to XDG_CACHE_DIR (which is what g_get_user_runtime_dir() does), but that would mean that the FUSE mount points would go under XDG_CACHE_DIR/media/$USER, which is a bit ridiculous.

They go back and forth about what the XDG standards actually say and whether to make GTK conform to them, or to comman usage, a discussion of technical details with IgnorantGuru showing no signs of being censored and the discussion showing no signs of being stopped, only an ongoing philosophical disagreement about how things should work. There is a fundamental problem this entire thread is built on top of, though: this problem only occured because gvfs (and udisk) weren't installed — if they were, everything would be standards-compliant and work just fine:

Comment 19 Emmanuele Bassi (:ebassi) 2015-06-02 21:45:36 UTC ... To be absolutely blunt, not installing components and then complaining that things are broken is not really cool. It’s not like we want to duplicate the logic everywhere: we put it inside some component for a reason. GIO depends on GVFS on Linux, and GVFS depends on udisks. If you’re using some other OS, the chain of dependencies is different, but we kind of treat the stack as a stack, not as a pick and mix bowl of “may be nice to have”. The reason the dependency is “soft” (i.e. we don’t make GIO depend some libraries) is mostly a case of 1. historical accidents; 2. a convenience for integrators to avoid dependency cycles; and 3. because on Windows, *BSD, or MacOS, the dependencies are fairly different.

Because that is what they're asking for — they're asking the GTK developers to duplicate virtual filesystem handling logic from the software they wrote to handle userspace virtual filesystems into their general library (GIO) just so that people don't have to install things that are listed as dependencies (just not hard dependencies because things do still generally work without them). And the objection might be that gvfs is GNOME-specific, so it shouldn't have to be installed... but so is GIO, and they have that installed. And GTK does work without it, if they adhere to the open specifications for free software desktops!

And here is where we get to the meat of things — the comments that got deleted.

The meat of the first comment that got deleted is, as far as I can tell as someone who isn't extremely deeply into GTK development, just a word-salad of nonsensical moon logic:

Actually, you’re being absolutely inaccurate. gio does not depend on gvfs – it is part of glib and runs fine without gvfs. Perhaps you should review what a dependency is. From your own docs: “One of the big advantages of putting the VFS in the GLib layer is that GTK+ can DIRECTLY use it, e.g. in the filechooser.”

Iow, GTK+ does NOT depend on gvfs for a reason. The point of putting it in the glib layer was to avoid GTK+ dependencies on DE-specific filesystem abstraction layers like gvfs.

So, to be clear here: the quote from the documentation says that GVFS is part of glib, and the whole point of that was so that GTK+ could directly talk to it — but he's claiming that GTK+ does not depend on GVFS at all.

This is but a premonition of things to come however, because he finishes out this comment with this needlessly antagonistic and conspiratorial — GTK and GNOME aren't exclusively run or controlled by Red Hat! — statement:

I really [sic – realize] Red Hat has done everything in their power to break that separation and create a monolithic stack, but for now glib is not gvfs dependent.

Then he immediately jumps in to grandstanding in a way that is far too broad and off topic for the subject matter at hand:

For people who don’t know the history on this, modern GTK devs (iow Red Hat – some of the same names we see here) tried desperately to make GTK dependent on gvfs. However, it broke everyone’s work and gvfs didn’t work everywhere, so they were forced to backtrack. To no one’s surprise but theirs, GTK still runs just fine without gvfs (except where they deliberately break it, like this gvfs hack interfering with other software), but I’m sure it’s still their agenda to make it a dependency just because they want it to be, and the inaccurate information being given here is right in line with that history.

So he's claiming there's some big conspiracy by Red Hat to make everything dependent on everything else for some reason, and that they're lying about what is dependent on what in this very thread to further that agenda — although they were clear where and how the fallback works, and when you need GVFS, and gave non-GVFS suggestions on how to get it to work. That parenthetical, though, is perhaps the height of Guru's absurdity: a library "running fine" except in the cases where it breaks because it lacks a dependency isn't a conspiracy, my friend, that's precisely what a soft dependency is. That's how they work. Hell, that's how dependencies work in general — something missing its dependencies will continue along just fine until it hits a point where it's missing something it needs and then it will fail. But Guru's conspiratorial mindset is locked in. He continues with the acrimonious verbal abuse, too:

So basically gio is only now supported for gvfs use at most – they won’t even think of making or accepting any changes which help other general users of GTK. And I’ve heard this “please submit patches, test cases, more info”, etc. before from these same people. That is their way of just ignoring you – they’d rather waste your time than tell you flat out that they refuse to support gio (or really GTK), and won’t accept any changes that do so. At least that has been the pattern of behavior.

This may not be harassment or verbal abuse on the level of what a Kiwi Farmer might direct towards a trans person, but this is pretty clearly unproductive, rude, and dismissive conduct that is unfitting of a bug tracker where people are just trying to get things done. Even Psy, the person Guru is trying to "help" here, isn't really engaging with him that much, probably because he's being too insane even for them. So this is when Emmanuele finally steps in:

Comment 23 Emmanuele Bassi (:ebassi) 2015-06-03 08:54:58 UTC

This will be the only time I reply to one of your comments, and it’s also your final warning. Bugzilla is under the code of conduct of GNOME, and you have been consistently rude, dismissive, and flat out insulting in every single interaction with the developers.

Either you stop, or you get your account revoked.

Also, I've been assuming for the sake of argument this whole time that Guru's comments really were deleted by the GTK team — but they weren't. I'm going to post Emmanuel's response to someone else's attempts to summarize and defend Guru's points in full here, because I think it does just as good of a job at deflating them as I could have:

Comment 28 Emmanuele Bassi (:ebassi) 2015-06-03 20:03:07 UTC (In reply to OmegaPhil from comment #27)

censorship is unacceptable (for the record I have no interest in a ‘code of conduct’,

It does not matter if you have no interest: the code of conduct for GNOME services exists, and it’s enforced on Bugzilla.

if you see shit you call it out,

No, it does not work that way.

You behave like a decent human being, and you afford some level of courtesy to the people that work on the stack that you use. You assume people mean well, and you treat them like intelligent people that are trying to solve problems and work on an open, volunteer-driven project.

o GTK is not supposed to be dependent at all on GVFS.

While GTK does not depend on GVFS, GTK depends on a set of functionality that is implemented by GVFS. If nothing implements it, then GTK simply will fall back to a subset of that functionality.

o In recent times, Red Hat developers have attempted to make it dependent (e.g. the ‘soft dependency’ mentioned previously).

Red Hat does not enter in the picture; I’m not a Red Hat employee. You can leave you conspiracy theories at the door.

o This broke a lot of things, thus a more serious dependency had to be backtracked.

This has broken nothing. Not showing FUSE mount points from random, unspecified locations that just so happen to be used by some project is not a break in functionality.

o With the current situation and this bug, it looks like the maintainers don’t care to be compatible/accessible with client software that already has well-established behaviour, and is not involved with the GNOME software stack.

I’ve said multiple times that I’ll gladly review a patch; I also said that, while I routinely work on the G* core platform, I’m also not a GIO maintainer, thus I cannot guarantee that the patch I review will be integrated. You can try and convince a GIO maintainer — join IRC and state your case.

What I’m not going to do is write the patch for you, since I don’t have any issue with the current stack, and I also have other projects — as well as work — that I maintain and have to care about.

Since the people in this bug use applications that do not conform to the basedir specification it’s entirely up to them to pursue a fix in GIO.

Basically hes very concerned that with this and other issues, important core software is being stolen away from normal non-GNOME usage.

Honestly, if 1% of the energy spent finger-pointing, complaining, and resorting to rude and unfounded accusations were instead spent writing the patch in question, we could have closed this bug already.

This doesn't seem like unjustified censorship from the GTK/GNOME team, nor does it correspond as abuse or harmful behavior. This seems like a reasonable reaction to a petty, rude troll trying to muscle in on every discussion.

Gtk to Qt - a strange journey

This next one is a talk by Konstantin Blasi at, and is perhaps the most convincing one yet — but that's not saying much. Here's a transcript of the relevant portion, edited for clarity:

"We had the ability to do Windows binaries, Mac binaries, and of course, the Linux distribution from source. There are some issues with the Windows support and Mac support in GTK. The core developer community quite clearly does not consider this relevant, important, or supported. So, there are sub-communities that try to make this work with various degrees of success. The look and feel is absolutely not native—I mean, not even close to native—and you run into a lot of bugs and a lot of unexplained behavior. We were at the point where people were saying, 'Oh, this would be a great feature if somebody else would do the UI component,' because no one on the team was willing to deal with changes to the UI anymore. The complexity of doing this, the fragility, the fact that the model system was utterly broken in the way it's designed was very, very, very frustrating. There were lots of things we wanted to do differently, lots of just user interaction changes that we wanted, and we could not find anybody who would help us implement it, and we couldn't figure it out. And the documentation is—what's the polite word for terrible? I think terrible, yeah. But the biggest challenge for me—and I say this, I've said this to these people in person, and I'll say it here again—the biggest challenge for me with GTK is the attitude of the core community. The community will tell you if you have a problem, they will tell you... eh, now that I can't repeat, there was just reminded of the politeness rules for this conference. The second thing they tell you is you're doing it wrong. The third thing they're telling you, 'Oh, you don't get our vision,' and then they stop talking to you because obviously that's all the help you need. The is utterly impossible to go with a concrete question, saying your documentation states this is what it should do. If I write exactly this code, it doesn't work. This is what it does. How do I get to working code? There is no way to get an answer to this; the only thing you can get is abuse. You can get long flamewars. So if you want lots of comments on your Google+ posts, that works. ... Our issue with GTK was we tried for more than a year. We had engaged with a lot of GNOME and GTK developers, and we had come to the conclusion a year ago: this isn't worth it."

This seems pretty bad right? This poor guy is being abused by the GTK team! If they did actually say unprintable things to him, for basically any reason, and he isn't just using that as hyperbole to say they rebuffed him — which, to be honest, seems to be to be what he's actually saying, not that they actually told him to go rotate on a fist or something — then I genuinely would and do condemn that as toxic behavior.

The problem is, I just don't know how much I believe what this person is saying. Even IgnorantGuru never recieved any abuse himself in response to his trolling in their bug tracker, just a bit of light sarcasm but otherwise good-faith discussion, which honestly I think is a testament to the GNOME developers' good will. There were technical disagreements, and the GNOME or GTK people didn't immediately give up and do whatever was asked of them because of those disagreements, but that hardly constitutes actual abuse, and throughout all the rest of these sources, whenever there's been a way to directly check what they've said, I've seen no evidence of the GNOME or GTK people every actually abusing someone at all. The only time any "evidence" of abuse shows up is in vague claims like the one above, backed up with no evidence to support them. Even most of the sources from GNOME haters don't claim abuse. So I've got a choice between believing the word of someone without any evidence so I can see for myself what they're referring to, to make sure it really happened and that my definition of "abuse" lines up with theirs, or believing all of the direct evidence of GNOME's behavior I've seen on their bug tracker and conversations in these sources. I'm going to go with what my own two eyes tell me, especially since I think there are existing ulterior motives for all the acrimony against the GNOME and GTK developers that have nothing really to do with their actual behavior. These are not unbiased witnesses.

Additionally, there's the fact that it seems like he's intertwining somethings here — the original clip of this video provided to me by the Hacker News person elegantly clipped out the context of the person saying he "received abuse" and "got into flame wars" and "the GNOME developers told him he didn't understand their vision", so that it only included him mentioning bugs and then going to discuss all that, making it sound like all of that happened just in response to him reporting bugs. But it seems like, in actuality, if you listen to the full context given above, there are at least five separate issues that the speaker, and my interlocutor, were both conflating: the issue of cross-platform compatibility, the issue of GTK's "bad design," him wanting to change the behavior of things in GTK, him wanting help implementing things, and the issue of bugs, which the speaker mentions in that order before getting to the GTK team's response to him, thus allowing my interlocutor to conveniently cut out all but the last. The speaker never really makes it clear which responses from the GTK team were to which issues, but if we look at the range of GTK responses — from saying "you're not supposed to do that/that's not supported/important", to silence, to saying "that's not compatible with our vision" (and associated flamewars) — it seems pretty clear which is most probably to correspond to which: responding "you're not supposed to do that" to cross-platform compatibility and him wanting to change the behavior of GTK in some way, responding with "that's not compatible with our vision" to him trying to tell them how they should design their own API (and flamewars ensuing over that bikeshedding, as they always do), and silence when he asks for help implementing his own app.

Could these responses not actually match up, and instead be as disproportionate as he sort of intimates through conflation and obfuscation? Perhaps, but I don't really know how much I can conclude from this. I could probably make a strong conclusion against GTK if any of the other evidence I'd seen so far shows any actual abuse or real hostility on their part, instead of just GNOME developers not being sufficiently "nice" to a troll and not supporting features they don't want to support, but as it stands, I don't know.

Would it be better if GTK was more open and helpful? Absolutely. But this, if we leave aside the conjecture and conflation of issues, just isn't that strong of a piece of evidence. So let's move on.

GNOME can eat shit

This is a short one, a rather famous quote from Drew Devault on Reddit:

As a Wayland developer who has had to deal with fighting GNOME tooth and nail over every standard, GNOME can eat shit. What else are we supposed to do but stop supporting them when they refuse to play ball with standards? They're bullies, plain and simple, and take a Microsoft-esque approach to Linux politics - except they just skip "embrace" and "extend" and just go straight to "extinguish". We've spent literal years fighting with GNOME over every standard. They don't just decline to implement standards, they actively work against the establishment of standards at all. Get fucked, GNOME.

By the way, you're welcome that mpv has Wayland support at all. No less than 3 times have I had to confront wm4 about removing Wayland support in general on the basis that GNOME sucks.

Again without clear sources for this where I can go read the logs, and in the presence of all the general GNOME hate that's going around, it's hard to feel like this is actually evidence for anything other than another single person's opinion, this time Devault instead of Blasi. We don't get to see what GNOME's reasoning was on any of the standards — why they resisted, what their motivations were, etc, so it's just kind of impossible to say. And honestly, it doesn't seem to me like GNOME refusing to sign off on standards if they don't want to implement them really constitutes "bullying" or Microsoft-esque "extinguishing," so much as them just being stubborn and perhaps overly committed to their vision, precisely because Drew can do exactly what he just said in this comment, and just walk away from the bargaining table, and implement a protocol every other desktop environment and window manager will use, leaving GNOME out in the cold if he wants to, and probably eventually forcing GNOME to acquiesce, since people are free to switch away from it if it doesn't support things well.

GTK3 was a brutal upstream

Next we have something also mercifully short: a blog comment with more complaining from the Mint people about theming.

Please provide a link towards PopOS’s reactions. I’m interested in this.

Joseph is working on adding GTK4 support in Mint-Y.

Personally I won’t let any app in our default selection break our theme in Mint 21. I would replace it, or patch it, or fork it, or patch libadwaita, or even patch GTK if it came to that. I don’t think it will come to that but that’s what I mean by being strict and knowing what we want.

The migration to GTK3 was brutal upstream. With the exception of Mint 12 I think we managed to patch regressions, delay changes and adopt design changes which were good but which broke with the past at a nice pace. We were able to embrace flat themes, symbolic icons, CSD, dark mode, touch UI widgets (toggle buttons for instance) and many improvements after people got used to them and they no longer frustrated most people. We also rejected many upstream changes and stayed true to our own vision of the desktop. Cinnamon is testament to that, we didn’t want to lose our panel, our applets, our tray, our window-centric switcher or our desktop paradigm. Looking ahead at GTK4, we’ll have the same approach, we’ll keep a close eye on the changes, consider what they bring and what they take away, if they’re of interest or not, and whether people are ready to move on or not. Developers who jump into GTK4 without thinking or caring what it means for their non-GNOME users, or developers in general who only care about their app integrating properly in a desktop we don’t ship, aren’t likely to produce apps we’ll continue to use, or at least that we’ll continue to use without modifications.

I heard people talk about changing toolkits, I agree with their concerns but I think it’s too early for that. If you’re developing an app with GTK right now and you want it to continue to work well for all users of Linux the solution is simple, stick with what works, what integrates well, what’s stable and what is supported everywhere. Yesterday that was GTK+, today that’s GTK3.

Again, meh? GNOME is not a DE construction set, it's a DE itself, so of course it's going to be hard to have to continually adapt it to be something completely different, and of course it would lead to downstream consumers of it having to patch it or fork it or move to a different toolkit. There's nothing new here, so let's keep it moving.

System76 drama

Another tabloid article, this time from The Register! In this one, it's talking about what catalyzed System76's decision to write their own Wayland-first desktop environment in Rust (with blackjack and hookers!). It's a long series of "he said she said" back and forth grievances between the GNOME team and System76, first a point-by-point recounting of a GNOME blog post talking about the issues they had in collaborating with System76 in the past, and then System76's response. This article was linked to me as an example of GNOME "vilifying" System76, so let's look at what they said:

Murphy spoke of frustration about the fact that the GNOME extensions System76 develops "break every GNOME Shell release" and that there are "things we'd like to do that we can't simply achieve through extensions in GNOME."

On Tuesday, Christopher Davis, a core member of the GNOME team, accused System76 of "poor behavior" in a post, though added: "I do not speak for GNOME as a whole, only for myself."

He referenced several incidents. Back in May 2018, there was a row over LVFS (Linux Vendor Firmware Service). System76 refused to use it following a discussion with its maintainer, Richard Hughes, and criticized the service's data collection among other issues. In August 2019, System76 described its new firmware manager, which connects to LVFS as well as the company's own firmware service. Davis said: "System76 began using the LVFS and fwupd without any fanfare or retraction of their prior statements."

Davis continued, saying System76 has fixed bugs in its own distro before fixing them upstream in Ubuntu, which Pop!_OS is based on, leading to a complaint from Sebastien Bacher, another member of the GNOME team. We note that, from looking at the comments on that post, including those from Murphy and Soller, the issue is not clear-cut. "Pop!_OS provided patches for both those GNOME examples," said Soller.

Another issue was development work by System76 on an i3-style tiling manager in GNOME, which Davis said System76 has refused to collaborate with GNOME on, and that System76 made proposals too late for GNOME 40 and "shared misinformation" when these ideas were not included. There was also a reference to a disagreement over libadwaita, a library to make it easier to follow GNOME human interface guidelines. "I do not feel like it is worth my time to engage with System76," said Davis.

Hours after Davis tweeted a link to his blog post, saying "it’s finally time to lift the curtain," Soller revealed he was stepping back from System76's Linux distro work.


Murphy added that the statements made by Davis were "mostly untrue. He doesn't really understand our situation. Makes too many assumptions about us." He also referred The Reg to a separate GNOME campaign, signed by Davis, requesting that apps are not themed because "all our efforts designing, developing, and testing our apps are made futile by theming in many cases." Murphy believes this was targeting System76.

Reaction to all of this from the community is mixed but by no means supportive of the post from Davis. "I read this expecting to pooh-pooh on System76, but left thinking maybe they have a good case," read a comment on Hacker News.

I recommend you read the full GNOME blog post to get the full content of their issues with System76. It genuinely seems to me, at least from Davis's account, that System76 really did them a disservice, repeatedly spreading misinformation and grievences online via Twitter instead of communicating directly and trying to resolve things. Worse, System76's best reply seems to be a weak, nonspecific "you just don't get it, it totally wasn't like that," and if you actually look at some of S76's interactions with GNOME developers, you can clearly see which side is the petty, short-temptered, childish one that doesn't want to communicate like adults, and which isn't (click on image to go to the thread):

Tobias Bernard on Twitter: "Proper tiling is something we've wanted u…
archived 19 Sep 2021 04:59:26 UTC

The pettiness of Jeremy Soller's response — essentially delivering an ultimatum to this indie open source app developer that he won't consider upstreaming his work until he changes his stance on app theming — and again, what an utterly minor thing to be so petty over! — is just sad. It's totally within Jeremy Soller's rights, of course, but this isn't even refusing to do something for like, an actual technical reason, or because it conflicts with your vision, or anything like that, and if anything upstreaming System76 tiling would make things much, much easier in the long run for them, so this is entirely just cutting off their own nose to spite someone else's face. I encourage you to read the "stop theming my app" page, by the way, it makes a lot of good points, even though Soller treats it like a personal attack — as we saw above, where he makes the absolutely paranoid, egomaniacal claim that GNOME is out to get System76, specifically with the "stop theming" campaign, despite there being a million other, bigger distros that also do it.

Building an Alternative Ecosystem

Once again, we have another theming post, from the Budgie team, complaining about the fact that GNOME isn't a tookit for building DEs, but a completed DE in and of itself, and that it doesn't have a stable public API for theming, and talking about moving to a different toolkit and DE — which, agian, is the right move, in my opinion! Here's their discussion of theming:

Linux users have long enjoyed the degree to which they are able to personalize their desktop apps and environments through theming, a tradition dating back to long before I even started using Linux. Reasonable expectations like these are being completely turned on their head by GNOME.

So everything is supposed to have certain features just because they're "traditional" or "expected"? I'm not finding myself very convinced. Plus, if you actually read the "Stop Theming My Apps" manifesto, they never wanted to stop individual users from theming their apps, or their entire desktop! It was a plea to distro maintainers to stop doing that for branding purposes, because if a user purpusefully chooses to theme things themselves, they know something's been changed, that it's nonstandard and not technically supported by upstream app developers, and so are prepared for and expecting minor bugs, and won't blame them on the DE or app developer, thus creating more work for them. If the distro does it, however, it will be assumed to be supported and intentional, and cause problems for upstream developers, as people report problems to them that are really problems with the theme the distro uses. So this is just hyperbolic misinformation. In fact, and lest you bring up the instability of the CSS API, GNOME is so in favor of individual users being able to theme their own things that there's a GNOME app signed on to the "stop theming my app" campaign that allows you to theme your desktop, just in a more rigorous and controlled way that won't break it: Gradience. Not to mention the supported and stable part of the libadwaita colors api.

This is being done by requiring vendors like Solus and System76 to develop their own libraries to handle styling of their own specific applications, fragmenting the look of GTK apps that either use a platform theme or don't use one at all. Through their enforcement of the Adwaita theme in their "platform library" libadwaita, which they pitch as more-or-less the blessed way of adopting their Human Interface Guidelines, they are eliminating both developer and user choice in the process. If you want to support and adopt the GNOME HIG via libadwaita but still offer third-parties the flexibility to make the app integrate well in their ecosystem, you cannot. This introduces a significant regression in the desktop Linux space.

First of all, isn't the entire point of having strict interface guidelines, and a UI library that is designed to basically only allow constructing interfaces that follow those guidelines, restricting choice in order to assure quality and consistency? Also, they were working on a recoloring API that vendors could use to brand things.

Secondly, I should note that the Adwaita theme is part of the UI/UX of a desktop environment (the 'visual API'), so of course the theme would be part-and-parcel of the human interface guidelines. What the hell else would you expect? If you can completely change the layout and look of everything, that's inherently going to make the interface different to use. So I don't know why anyone is surprised that Adwaita is hardcoded into.... libadwaita. It is quite literally in the name, people.

Again, this seems like another case of people wanting to use GNOME's stuff for the convenience it offers, but not wanting to actually use GNOME's stuff — they want to take advantage of GNOME's labor, but don't want it to have any GNOME touches, any whiff of anything GNOME-specific, or any element of GNOME's design philosophy, on it, all the same. They both want it to be built for them, so they can conveniently and easily follow the HIG, but also be totally flexible to however they want to modify some aspects of the toolkit that effect the HIG. They want to have their cake and eat it too, essentially. Honestly, the sentence (paraphrase) "we want to use libadawaita for implementing the HIG, but also still offer theming (i.e., not use Adwaita or follow the HIG at all, with our library that is for doing exactly that)" is the height of absurdity. GNOME finally did what everyone wanted and split out their GNOME-specific code into a separate library, and left GTK 4 completely platform-agnostic, and now people want to use GNOME's own library too, and are complaining when it's too... GNOME-specific. It's like the classic webcomic:

There are some new bits, though. Well, new for us, at least. There's the trite, stock accusation that GNOME is "suboptimal" on the desktop and a "mobile interface" (we will deal with this later):

While we have been consistent in this vision, though certainly not without flaws in its execution, we have seen a significant shift from GNOME's development efforts and vision being focused from their desktop experience, to a heavier focus on mobile-to-desktop application scalability and a more touch-oriented, almost iPadOS like user experience that does not (in our opinion) provide the most optimized experience for laptop and desktop users.

And grandiose accusations of groupthink because GNOME has a vision it wants to pursue, and doesn't want to serve every possible user that complains (and I should add, there is a 'silent majority' of users who use and love GNOME every day):

This is something I have noticed over the years as the maintainer for the GNOME stack on Solus and has become especially apparent in the last few years while I have been the lead on Budgie. What used to be a community welcoming diverse ideas, focused on providing an equitable ecosystem for many members of the Linux community, has gradually turned into an isolated silo of thought that pays little mind to the concerns raised by its users.

As well as accusations of, essentially, cancel culture:

To make matters worse, when some improvements were proposed by an engineer at System76 to libadwaita's Recoloring API, which is their alternative to theming that is specific to recoloring various elements of GNOME apps and is app-specific (not system wide), these improvements were rejected on the basis that some of the GNOME developers disliked the opinions expressed by the engineer on social media. ... Instead of debating more on technical merits, these developers are instead trying to devalue and discredit the contributions by intentionally misconstruing the opinions expressed by the engineer, attributing malice where none existed, and claiming the individual was "flamebaiting" to get attention.

...because GNOME developers didn't want to work with System76, who are transparently petulant and childish to them, routinely go and spread misinformation and grievances online instead of communicating with anyone, and most relevantly, take quotes from their own communications with GNOME developers out of context and use them as rage bait online. Ask yourself — does that count as merely a "dislike" of some "opinions," and a petty rejection, or is this obviously someone you wouldn't want to spend your time working with work with?

Additionally, looking at the actual thread, people from GNOME actually do discuss the technical merits of the merge request with the PopOS team, and several app developers not from GNOME also chime in to say that they don't like or want PopOS's solution, and they discuss the technical questions why. Things only take a turn away from the technical discussion when one of the app developers (I believe) mentions System76's behavior towards GNOME on social media as an explanation as to why GNOME devs might not want to collaborate with them, and then a discussion begins trying to explain to the System76 person how and why their behavior may have been unproductive. This doesn't seem like a smoking gun of GNOME being "abusive" to me — the worst you could say is oversensitive, I guess, but I don't think that's true either.

And if we look at the things linked by Alice, we see that, again, System76 is being the asshole here, pretty clearly. Delivering grandiose ultimatums in an unproductive manner:

Jeremy Soller on Twitter: "Something @GNOME NEEDS to realize is that …
archived 18 Sep 2021 20:20:25 UTC

Pretending that dark mode won't work on GNOMe (I'm literally using it right now, it does):

and posting flamebait to rally the haters (whether you agree with the quote or not):

Jeremy Soller on Twitter: ""First and foremost the recoloring API is …
archived 18 Sep 2021 19:35:13 UTC

I think GNOME was more than justified in the way they acted.

While I certainly recognize that the opinions, words, or actions of some of these developers may not reflect the entirely of GNOME, the regularity of this behavior from GNOME contributors clearly speaks to a cultural problem inside of GNOME. They aren't just being anti-user at this point (actively making it more difficult to curate their own Linux experience), but anti-developer as well. Rather than listening to the concerns of entire operating systems and many of their own users on the negative impact of GNOME's decisions, they have doubled down. This sort of behavior is destructive to the work so many of us, GNOME developers included, have done to try to ensure Linux is a viable desktop computing platform. It alienates folks and further perpetuates the view in the Linux community that GNOME does not listen and is hard to work with.

And yet again, more complaints that the GNOME developers don't do what the downstream developers want with their own time and their own project, insisting that people who don't contribute to a project should some how have a right to dictate how it works, and calling wanting a less customizable experience somehow "anti-user" (which, again, would only be true if there weren't other more customizable options, or users were somehow trapped on one DE).

Why can't Ubuntu, Mint, System76, and whoever else just fork GNOME, if they don't like where GNOME is going, instead of trying to use the GNOME devs as slave labor and crybullying others when they don't get their way? They do actually have the resources and manpower to do so — we can see this in the fact that System76 is, in fact, now developing their own entire DE from scratch.

GNOME Mess Is Not An Accident

Although it purports to demonstrate some kind of systemic problem with GNOME's developers, our next post does nothing of the sort. Instead it catalogues an interminable list of minor gripes — how dare GNOME require OpenGL 3.0 in 2023 (nevermind that 3.1 has become the de facto widespread standard across platforms and operating systems, and that OpenGL 3.0 was 2008) — and bugs, the likes of which one could easily replicate for any other desktop environment, even, or perhaps especially, the vaunted KDE, and various features the author is personally mad they didn't implement fast enough. The only really egregious example is this:

Five years ago an issue was raised regarding mutter in Wayland not allowing applications to inhibit the screensaver, making tasks like watching a movie something unbearable [25]. The fix would involve implementing support to a well-established Wayland protocol that at that time was already implemented in KDE and Sway. Only four months ago GNOME finally addressed the issue, but not without embarrassing discussions, including GNOME developers trying to bend logic:

Most people either don’t seem to watch long movies on their desktop or just don’t seem to be bothered by the bug.

Which, like, yeah, that's dumb, but that quote is taken out of context. This isn't the GNOME team rejecting that it's an issue at all, saying it isn't a feature they need to get around to implementing, or dismissing anyone's complaints. Here's the actual full quote:

I totally understand the frustration, but "basically unusable" is an exaggeration. Most people either don't seem to watch long movies on their desktop or just don't seem to be bothered by the bug. Why else would we receive so few reports about the problem in 5 years? ... I want to reiterate though, that is is a bug, and one that GNOME shouldn't still have.

So yeah, I think we can leave this disingenous article alone. GNOME doesn't implement features fast enough for them, they introduce bugs sometimes, and that means they're the devil incarnate and incompetent developers. Great.

Symbolic icons only have the -symbolic suffix, breaking compatibility with FDO-compatible apps

Finally, in the latest development — and the catalyst for this entire article — we have this bug tracker issue and this Hacker News thread about it. What we're going to do here is look at conclusions the people on HN draw about GNOME's behavior from reading that issue, and then look at what actually happens in that issue, and see if they line up.

chris_wot: I have no sympathy for them. They implement a spec and make a big song and dance about being open and standards friendly... and then when they don't implement the standard correctly they say they have implemented it correctly, argue about it and then when they are proven incorrect they just close the ticket, even though they could make small changes to fix the problem.

cullmann: I as Kate maintainer can not understand their position in that bug. I see that one might forget about the implications of that rename, but now it got reported and the fix would be, at least the simple one, to just keep the old icons for these names. That would have zero bad impact on 'modern GNOME apps'.

Intralexical: That would make sense if they cared about solving the issue. Rather than about proving they're right and showing they're in control.

The specific issue and facts don't actually matter. Y'all said something that was different from what they were already doing/thinking, therefore, you must be wrong.

mook It sounds like an alternative where they just don't pretend they support the thing the don't support was proposed, and shot down because that means they won't show up in UI that only lists things that support the thing?

… And they also control the UI in question?

meibo: Wow, those RedHat guys in the gitlab tickets and commit descriptions related to this are insufferable. Is this what happens when you get paid for open source work?

LightFog: There does seem to be a culture of contempt for the dribbling masses (aka users and application developers) ruining the beautiful visions of RH devs.

Intralexical: Nobody should be surprised anymore when GNOME pulls some shady and technically questionable crap to try to make their "product" look better by actively breaking other people's work.

Once again, we're presented with a nearly unanimous narrative that sounds really horrible. Let's look at what this thread seems to be saying is happening:

  1. GNOME broke these icons for no relevant reason
  2. The GNOME devs are being insufferably contemptuous of people just asking for a simple fix to a problem
  3. They're advertising their icon theme as supporting a standard it doesn't, a standard that basically all other non-GNOME apps use
  4. They're refusing a simple fix that doesn't cause any problems at all

Ouch. Well, let's actually take a look at the bug tracker thread for ourselves and see what's going on.

We open with the issue itself:

Nate Graham: [Here I use the copy icon as an example, but the issue affects everything]

The Adwaita icon theme has an icon-named edit-copy-symbolic for its copy icon.

The FDO icon theme name spec specifies that this icon should be named edit-copy; see

As a result there are 18 years of FOSS apps that ask the active icon theme for edit-copy, not edit-copy-symbolic.

When Adwaita is the system's default icon theme, and such an app asks for edit-copy, it's not found. Per the icon loading spec, the icon loader will chop off the last part and look for edit. That won't be present in Adwaita either. Hence no icon will be found, and the the app will have a blank space instead of a copy icon. Users will file bug reports, complain on Reddit, and make 20-minute YouTube videos crooning "Whyyyyyyyyyy??????" into a camera.

Now, I understand why Adwaita wants its symbolic icons to have -symbolic appended. In KDE we like this convention you came up with, and we're moving towards it as well, and porting our apps to ask for edit-copy-symbolic. However we retain the old icon names for backwards compatibility with FDO-compatible apps that have not yet adopted this convention. ... Consider adding or re-adding compatibility symlinks, so that apps outside of GNOME and KDE aren't missing almost all of their symbolic icons when using Adwaita.

So, right off the bat, already we're seeing some differences from the dominant narrative in the Hacker News thread. It looks like this isn't something GNOME did completely at random, or even by themselves, but something GNOME and KDE and probably other DEs are all doing together, it's just that GNOME is moving a little faster and cares less about backwards compatibility in the meantime. That's still not great, but let's see how the discussion develops:

Jakub Steiner: This doesn't feel very actionable from my side. the -symbolic suffix separates the different recoloring behavior of symbolic icons. Linking to symbolic icons to expose them in the non-recolorable codepath will introduce all sorts of issues. adwaita-icon-theme is not a generic icon theme from the 2000s anymore. It's scope narrowed to serving a few core GNOME apps.

Now things are beginning to diverge from the narrative a little bit more, huh? These icons have different names because they fundamentally don't have the same behavior as the old icons they're replacing, so just linking from the old icons to the new ones might cause bad behavior (perhaps unreadably low-contrast icons or something). Please note, "recoloring behavior" — they're doing this in order to be able to support the recoloring API they're working on to let people theme safely without using raw CSS themes. Those evil GNOME devs! Moreover, the developer points out that GNOME isn't designed to be a generic icon theme anymore, but is a GNOME-specific icon theme, for the GNOME apps (we'll see why in a second). I will admit this is phrased in a somewhat condescending manner, but considering the tone of the original issue, and the fact that they're not engaging in any other bad behavior honestly, a little condescention is forgivable. Let's continue.

Nate Graham: If Adwaita doesn't want to be an FDO icon theme, that's fine. But the problem is that Adwaita is advertising itself as an FDO-compatible icon theme ... As a result distros are setting Adwaita as the default FDO icon theme, and then apps that expect the default icon theme to be FDO-compatible get broken in the way I described. ... It sounds like maybe you should remove the metadata that advertises Adwaita as being an FDO icon theme ...

Seems fair enough. Except, a quickly following this, Nate realizes that GNOME already did this:

I see with 85e22163 you have removed some metadata.

Let's look at the commit:

Relying on adwaita-icon-theme as the all encompassing icon theme it long isn't is going to break in all sorts of ways. Don't confuse old timers into thinking adwaita-icon-theme is a good fallback theme for KDE.

So they've explicitly removed all of the information specific to acting as a fallback icon theme for KDE, so that properly programmed KDE apps wouldn't end up in this situation, since the icon set is not an FDO compatible icon theme anymore. So they explicitly aren't trying to advertise themselves as something they aren't, right? But Nate continues:

Nate Graham: However that's not enough; with that commit applied locally, Adwaita still appears as an FDO icon theme on the Icons page of KDE's system settings app.

I think you also need to delete this part:

[Icon Theme] Name=Adwaita Comment=The Only One Example=folder Inherits=hicolor

When I remove that stuff locally, Adwaita disappears from the Icons page as I would expect. That's the correct way to de-register Adwaita as an FDO icon theme.

None of that looks to me like it's advertising itself as a workable icon theme for KDE apps — that seems like it's just there so it's discoverable to Adwaita applications at all. It already isn't actually advertising itself as compatible with KDE apps as a fallback icon theme, but their software is still picking it up for some reason, and their solution is to just ask GNOME to make their icon theme completely undiscoverable at all. And sure enough, Jakub says exactly this:

Jakub Steiner: I'm afraid you're asking to break a-i-t. Nothing that remains hints at a-i-t presenting itself as a fallback theme.

I don't feel like investigating the fallbacks of the KDE side of things, but that would be my suggestion to start your journey on why your app breaks by depending on adwaita-icon-theme.

Nate reiterates the same point again, so Jakub expands:

Jakub Steiner: It doesn't advertise itself as such anywhere. The Inherits line? That just tells the lookup to go searching for a missing assets in the inherited theme, hicolor in this case.

Nate disagrees, and finally gives some sources so we can go look at them:

Nate Graham: It's right here:

Together, that metadata says, "I'm an FDO icon theme. If I'm marked as the default one, please use me as the source of icons for any app that asks for themed icons." Reference:

That first link is just the Adwaita icon theme entry he already showed, so we don't need to look at that. But let's look at the FDO icon theme spec and see if any of the properties set by the Adwaita icon theme indicate it's an FDO-compatible theme:

I don't see any specific property that is supposed to indicate implementing the FDO icon theme spec completely, which seems to be what the GNOME devs are keying off:

Jakub Steiner: That's your misinterpretation.

Maybe what Nate is referring to is the idea that simply having an INI file with this format at all indicates you must be a fully-FDO-compliant icon theme? If that's the actual behavior KDE's apps have, under that assumption, then I can sort of see where he's coming from, but (1) he never says that and (2) it's just an INI file specifying the icon set so it's discoverable to GNOME apps and has some metadata attached to it, that's not really FDO-exclusive, and why not use the same format for FDO and non-FDO icon sets, so you can easily discover them both, instead of a bunch of different organizations for each? It seems weird to assume that any file that happens to have some of the basic properties of a standard adheres to that standard. Maybe I'm too used to files with explicit file type and version headers but that would be odd. I think there's definitely two sides to this, but the issue isn't as clear cut as the KDE developer seems to think. Another commenter, Michael Catanzaro, seems to agree with my interpretation, although he doesn't seem to see how it's helpful: "I guess theoretically you could say 'adwaita-icon-theme implements the icon theme spec but not the icon naming spec.' But I'm not sure this would be a very useful state?"

In any case, this doesn't seem to be a case of the GNOME developers intentionally setting their icon theme to claim to be something it isn't. In fact quite the opposite — they seem pretty cleary they don't want it to show up as something it isn't, even going so far as to suggest adding a full icon theme for KDE apps to fall back to if they can't find an icon they're looking for, he just doesn't want to keep legacy icons around in GNOME's own icon theme just for legacy KDE applications, which seems reasonable to me:

Jakub Steiner @mcatanzaro I'll be happy to roll out some legacy fullcolor icon theme for the fallback to use downstream, but it's hardly a reasonable proposal to continue shipping ancient fullcolor assets for KDE to fall back to here.

This doesn't seem like a brick wall of unhelpfulness at all. Unfortunately, Nate misunderstands what he was saying:

Nate Graham: Again, KDE apps are not falling back to anything. They are asking for icons in the active icon theme (not any fallback icon theme) and those icons are missing with Adwaita.

He thinks they're still discussing the idea that KDE applications might be erroniously treating Adwaita as a fallback theme, when Jakub is actually proposing adding a fallback icon theme in case, as Nate described in the original issue, an icon can't be found. So, sadly, this reasonable suggestion falls on the sword of FOSS developers' communication skills.

At this point, another developer enters the discussion to point out that most modern Linux applications don't use or support icon themes, but bundle their own icons, and (as we see with the fact that symbolic icons have different behavior than hicolor icons, which is the source of this whole controversy in the first place) when they do, the behavior is different enough that implementing the spec would be actively misleading:

Matthias Clasen: All of this is fighting yesterdays war.

Icon themes are not a very prominent feature in current app development, and demanding that we do lots of extra work to implement specs that were conceived in a very different time and environment is not helping the situation.

He even points out, as I hinted at above, that the reason the Adwaita icon theme shares the same format — despite the simple reason that there's no reason to duplicate discovery code and create a whole separate alternative way to specify icon theme metadata for non-FDO-compliant icon themes just to be different so choosers that expect everything with an Icon Theme INI section to automatically be fully FDO-compliant don't have to change:

Matthias Clasen: We can't do that until there's alternative apis for apps to rely on. Until then, Adwaita will still be an icon theme, so apis like GtkIconTheme can be used to load whatever icons exist in it.

And I think its a misconception on your part that "registering as an FDO icon theme" comes with any requirement - there's no such thing

Unfortunately, Nate is a brick wall and refuses to listen:

Nate Graham:

Registering as an FDO icon theme creates the implicit assumption that the so-registered theme is actually usable by apps that request themed icons from an FDO-style icon theme. Maybe this is an implicit assumption rather than an explicit one, but it's still clearly there. ... All I'm asking for is symlinks ...

To which the GNOME crew points out:

Michael Catanzaro: The problem is the symbolic icons are not appropriate replacements for the non-symbolic icons, because they have to be recolored or they don't work well. I'm not sure whether Qt even supports recoloring. Older toolkits like GTK 2 do not. Then maybe newer GTK relies on the naming to decide whether to recolor (not sure)? So it's not as compatible as you'd like.

The easy solution is to bring back the fullcolor icons mandated by the icon naming spec. I don't know what else to suggest.

I recommend reopening this bug, because distros will stop using adwaita-icon-theme if we don't figure something out on our end. Kate isn't doing anything wrong here.

So the GNOME developers are actively offering solutions, even pretty labor-intensive ones, to try to get this working and make everything ironed out. Nate just completely ignores this offer of an easy solution that satisfies all parties, though, as if it was never offered, and offers two interesting but not necessarily better suggestions about this:

Nate Graham: I gather that in GTK 3 and 4, re-coloring is only enabled for icons that end with -symbolic? Maybe that could be relaxed, in favor of a more sophisticated check of some sort. For Breeze icons, the determination for whether an icon is re-colorable or not is baked into the icons themselves via embedded CSS stylesheets, so no special naming scheme is required. ... To work around this issue, we provide a dedicated dark version of the Breeze icon theme with all the icons defaulting to a light color so that if the toolkit doesn't support re-coloring, the icons' standard colors are at least correct. Such an approach could theoretically work for Adwaita too.

And the GNOME developers even consider one (!!) despite offering their own solution that should've satisfied everyone:

Michael Catanzaro

To work around this issue, we provide a dedicated dark version of the Breeze icon theme with all the icons defaulting to a light color so that if the toolkit doesn't support re-coloring, the icons' standard colors are at least correct. Such an approach could theoretically work for Adwaita too.


I could see a possible future where the fullcolor icons are automatically generated (and recolored) from the symbolic sources. To us, the fullcolor icons are legacy, and Jakub clearly doesn't want to maintain them anymore. Maybe just not having them in the git sources would suffice.

Jakub then joins the conversation again to explain why each of the proposed solutions has problems, but reiterates that he is committed to solving this too:

Jakub Steiner:

Kate being broken because it's missing icons is a severe break that I wish to find a solution for, but it can't be one of:

  • Maintaining a set of fullcolor assets in a-i-t that isn't actually used by core GNOME apps, not [sic] Circle apps or any modern maintained apps.
  • Symlinking names to -symbolic variants which will break recoloring (and probably introduce more issues in context we don't foresee).
  • Mangling index.theme metadata so adwaita-icon-theme drops from the icon lookup machinery. While it may fix Kate, it will break GNOME.

Something that might work, but I'm fairly skeptical about:

Inheriting from a legacy icon theme (tango-icon-theme). Potential lookup issues if fullcolor takes precedence over -symbolic.

Will do some testing for the last one.

In response to this, Nate again completely ignores the offer on the part of the GNOME devs to create or choose a fallback icon theme to provide the icons KDE applications expect, and drops some important information about the situation: KDE is the only set of applications and only desktop environment that relies on FDO icon themes by default, and everyone is increasingly moving away from using FDO icon themes. So in actuality, this isn't really GNOME refusing to be compatible with everyone else — it's KDE still holding on to something that nobody else really does anymore, and asking everyone else to slow their roll, despite everyone else being ready to move on, just to make their applications more compatible:

Nate Graham

Maybe you folks didn't think there even were any remaining consumers of FDO icon themes. I could see how that seems like a reasonable conclusion to reach if you didn't look at any KDE apps; I'll admit that in my own investigations, I have found no apps outside of KDE that do use FDO icon theming by default (most that do support it make it opt-in, and bundle needed icons). However in KDE we have thus far adhered to the FDO icon theming spec and use it by default. We have over 200 cross-platform apps, so hopefully we're not chopped liver. :)

Now, it is fair to want to support two hundred applications, especially ones as featureful and well-maintained as KDE's, so I won't say I'm completely on GNOME's side here, but this does paint a rather different picture than the Big Bad GNOME just breaking everyone else's shit just to be mean. This looks more like a disagreement over how much backwards compatibility is important, and how to implement that backwards compatibility without breaking other things when there aren't really any great options, all to have compatibility with one desktop environment and its applications (KDE), where the GNOME team repeatedly offer solutions and are willing to commit labor and testing to make them happen, but the KDE people completely ignore their offers.

A GNOME developer even agrees that they can make their icon theme metadata format even less compatible with FDO so nothing is "tricked" (Nate's words) into thinking it's an FDO compatible icon theme just because it has some shared metadata properties with generic names, and agrees that this was poorly coordinated:

Sonny Piers:

I have found very few apps outside of KDE that do use FDO icon theming by default (most that do support it make it opt-in, and bundle needed icons).

I agree it sucks for KDE apps, and surely we could have better coordinated. I would have hoped distros to help catch this. ...

It sounds like you folks should work towards [...] doesn't use the FDO icon theming machinery at all Yeah we've been talking about that for a while - I will bring it up at GUADEC and see if we can make progress.

They then ask an all-important question:

Out of curiosity is it KDE intention to keep using host icon themes by default?

To which Nate responds:

Nate Graham: So far we have no plans to abandon FDO icon theming in KDE. On the contrary, we have desired for a while now to try to rehabilitate the FDO specs for it to improve the situation, and @mak being their new maintainer is a promising development from our perspective.

It's pretty clear that in its current form, FDO icon theming only works if you control your own icon theme, which is why KDE and some other DEs with their own icon themes (e.g. Budgie with their own apps, Cinnamon with Xapps, XFCE apps) still happily use it. ... The fact that 3rd-party apps without their own icon themes have largely abandoned it is a sign it's not working out as originally envisioned.

So basically, this spec only works for applications developed directly by DEs who also control the icon themes, so that if you need a new icon for an application it can be added to the icon theme, but third-party applications have basically stopped using it. And so some DEs are still sticking to it with their own applications, including KDE, but most of the ecosystem is moving away from it.

At this point, the other threads essentially repeat the same discussion, although it seems like eventually falling back to Tango, for now at least, was agreed upon.

More importantly, though, the decision of the GNOME team seems to be agreed-upon even by non-GNOME developers:

Jakub Steiner The icon naming spec was created in a world where we believed we can come up with a fixed set of names and metaphors and cover a large enough base that we can achieve interchangeable icon themes. Users would replace a full icon set and get a completely different look without breaking all apps.

It was naive to think there will not be that one extra addition. No matter how much resources you'll throw at the problem, icon themes means apps will have a broken or off-looking icons. Widening the coverage will simply make it impossible to pick the right icon for the appropriate context and you'll just have harder times updating your assets. Unless you think Tango & Crystal were the pinnacle.

Christoph Cullmann I can agree with that, Breeze still tries to cover most stuff, but I see that issue. And I can even live with if we agree that themes are dead in the future and we all hardcode something or the different libs provide different ways to do that theming. I would just have hoped that would be first raised between all projects to allow us to fix our side and not that we now are in a situation where the side that seems to believe most in the old spec is just stranded and we have broken stuff there out in the wild.

Nate Graham That's what I believed as well until yesterday, but when I went looking for evidence to support that position, I unfortunately found the reverse: that most 3rd-party apps already ignore FDO icon theming. So @matthiasc's earlier "yesterday's war" comment makes more sense to me now.

It prompted me to open to see if there's anything that can be done from the spec perspective. I get that GNOME folks will probably still ignore it, that's fine, it's their right, but maybe those of us who do still care about icon theming can work to make it better for our own use cases even if GNOME doesn't participate.