Fanboyism/Fangirlism, and how it’s becoming problematic in Linux

NOTE: Anything referenced in this article is for educational purposes, please don’t go on witchhunts or anything against them — if anything just provide constructive criticism to them.

I feel the need to make this article for a fundamental reason — no one’s talking about this problem. It’s probably for the best — all the talk is usually going to stopping toxicity instead, but… I can’t let this problem go unanswered either as it provides its own implications for the future of Linux software quality.

To say the least, it’s definitely a good thing everyone’s focusing on toxicity tackling right now, that is for sure. However, toxicity is a topic for another time as it, indeed, also is a problem in Linux just as much as it’s a problem in Windows, in macOS, in Android, in iOS, you name it, everywhere.

The scale of feedback

In my honest opinion, there is a scale of feedback that is a prominent factor of this:

  • Toxicity — the most negative type of feedback possible (don’t do this, seriously)
  • Negative feedback — feedback that is negative and doesn’t provide that much in constructive feedback (not very helpful, but it’s not an attack against developers so technically isn’t toxic)
  • Constructive feedback — feedback that is both positive and negative and provides suggestions to the developers to overcome the negatives (the best kind of feedback)
  • Positive feedback — feedback that is positive and barely provides negative and constructive feedback
  • Simping — they can’t do anything wrong! (this is a problem)

In my opinion, the best type of review out of these would be constructive feedback. However, the problem I’d like to write this post over is ‘positive feedback’, and especially ‘simping’ for Linux software.

Why is this a problem?

There’s a bunch of reasons why this can be problematic, and I can even name a few examples of why they’re problematic. Suffice to say the main reasons are:

  • Without criticism there is no reason for issues to be fixed
  • Without issues being fixed software stay flawed longer
  • Software can fall behind against their competition if they don’t fix flaws
  • Developers can make dick moves freely and get away with them

Simply put, if there’s no criticism there is no reason for said issue to be fixed. Without criticism, developers won’t even know that issue is an issue to begin with most, if not all, the time. Believe it or not, but us developers actually desire our users pointing out problems that we haven’t noticed, most of the time, as it helps us make better software. Not giving us that criticism, whether it’s actual criticism or just feedback telling us it’s a problem, is detrimental to that goal.

This goes hand-in-hand with the previous point, but if flawed software hasn’t got issues fixed, it stays flawed for longer, and so those issues last for longer, and the users affected by said issues suffer with said issues for longer, hurting their user experiences.

This is potentially one of the biggest problems with unresolved fanboyism/fangirlism. If flaws aren’t fixed, but their competition fixes more of their similar flaws, the competition will be superior therefore in a user experience standpoint if this happens for so long that said competition has now got all the common features of your software on top of fixing any flaws with said feature-set that they have. I’ll delve into an example of this, later.

This is another thing I’ll delve into, later. I’ve seen programs abuse their fanboys/fangirls situation to make absolute dick moves, especially abusing simping to get away with these decisions. Without criticism being there in a big enough force, I’ve seen that some developers just won’t listen without said driving force against those dick moves.

PS: Providing ‘positive feedback’ isn’t necessarily a bad thing — in fact it’s rather welcomed, but there’s a point where too many people provide that instead of constructive feedback and that’s when it becomes problematic.

What happens if fanboyism/fangirlism makes software fall behind their competition? Mozilla Firefox for Linux happens.

We all know it, true Linux fans, most Linux fans simp for Mozilla Firefox. However, this has ultimately been a massive contributing factor to Firefox’s potential fate, on Linux at least. While y’all have been simping for Firefox, Chromium has been fixing their flaws piece by piece, mostly because of the existence of Linux-based Chromium OS and Chrome OS respectively.

Chromium has full touch screen support out of the box, Firefox has no touch screen support out of the box in unmodified Mozilla Firefox. Chromium supports most modern web standards, obviously, while I’ve seen Firefox lack modern web standards such as div scrollboxes (used in the Feren OS Start Page’s shortcuts area) and whatnot that have led me to prefer Chromium-based browsers like Vivaldi on Linux. This is by no means a good thing.

Mozilla has had no reason to fix most of this since barely anyone talks about just how many issues Firefox really has on Linux, because oh man does it have quite a ton of them on Linux. Touch Screen support is the tip of the iceberg regarding Firefox issues, and since no one is talking about those issues, Mozilla just ignores them, whether out of ignorance for Linux’s market share or just not knowing these are issues, since no one is telling them they’re issues, in the first place and is too busy adding more features to Firefox instead which only puts a bandaid on the mess of a browser issues wise.

If anyone’s curious, the main issues that come to mind for me are the god-awful Client-Side Decorations implementation in Firefox, the god-awful Client-Side Decorations close/maximise/minimise buttons theming, the fact the CSD close/maximise/minimise buttons aren’t recoloured when applying Firefox themes despite GTK having DARK MODES just for stuff like this, the lack of touch screen support, and the lack of certain browser-agnostic standards like using divs as scrollboxes horizontally. Don’t get me wrong — I’ve had my fair share of issues with Chromium too, especially with styling its CSDs, but nowhere near as many issues as I had with Mozilla Firefox.

People who simp for Firefox, it’s time to stop. If Mozilla ends up going by the way-side, then take this as a message: THIS is why you don’t simp for software — because of your simping, they’ve fallen behind in quality and, to a certain degree, critical features.

If they’re still around when you read this — it is not too late — point out issues with constructive criticism, and hopefully if enough people start doing so contributors and developers will see this outcry, things might finally get fixed, and Firefox be a competition-viable quality product once again like it was back in the good ol’ days that isn’t behind competition.

PS: Touch Screen support will especially become a prevalent issue as Linux Phones and Tablets become a growing idea.

‘Dick moves’ — GNOME

In this case, a ‘dick move’ is a move where the developers don’t show much remorse for it, potentially instead attack those affected who don’t support the alternative they’re forcing them to use therefore, and do nothing but add a headache for the people affected.

If you know me, you’d see this coming. People aren’t talking about things like this enough, and it’s really starting to become a problem now, especially with GNOME’s recentish dick move.

Now, there’s plenty of dick moves (whether intentionally so or not) I could talk about, here, such as removing the ability to execute files from Nautilus for a good few years, or not showing download size in GNOME Software for updates, but those are very minor dick moves as they have effectively no domino effects, and to a point the first one of them might even be a necessary evil ‘dick move’ (excluding the fact that basically all other platforms except iOS allow executing files from their Files applications). I guess there’s also their removal of the System Tray, but in their defense they did provide links to Extensions to restore the functionality immediately.

But, the main thing I’d like to highlight here is their refusal to support Server-Side Decorations in GNOME on Wayland (despite nearly all other Wayland DEs supporting them).

For the uninformed, Server-Side Decorations are the titlebars that the window manager renders. You can tell because they’re all fully consistent with each other in shape and form.

Two Server-Side Decorations living in harmony

On the other hand, there are Client-Side Decorations (CSDs), which are ‘titlebars’ that the program itself renders instead of getting the window manager to do so, and they’re one of the worst standards to exist, period. Not only do they have no normal way to hit a close button in that very window if they aren’t responding, but if they’re not the most inconsistently designed titlebars imaginable, then they’re the most inconsistent type of titlebar imaginable in functionality:

Image Credit: Aleksey Samoilov — https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_263617

That above image shows just how bad CSDs can potentially get design-wise. Now, to tell you about some functionality inconsistencies they usually have:

  • Some CSDs don’t have functioning right-click menus
  • Some CSDs don’t respect your titlebar buttons layout
  • Buttons are inconsistently sized across different types of CSDs, including their own hitboxes

You can also see some modern-day types of CSDs in the form of Microsoft Teams, Microsoft Edge, Chrome/Chromium, Vivaldi, Firefox with titlebars off, and so much more.

So, tell me then, knowing this: Why is THIS what GNOME wants to force users to experience in GNOME on Wayland by refusing to support Server-Side Decorations (SSDs)?

For those uninformed, XDG-Decoration is a specification for Wayland that effectively provides Server-Side Decorations (applications can request the ‘compositor’ gives them SSDs if they want them), basically.

To point this out clearly, this also brings headaches for developers, not just users. Developers suddenly HAVE TO support Client-Side Decorations to support GNOME now, once they go Wayland, and you know what some GNOME Developers and Maintainers think of you, developers, if you don’t?

https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_263617
https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_356808
https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_356822

People tried to tell them that this is an actual specification now, instead of just being KDE’s specification (it was a specification that KDE made, if I recall correctly), but…

https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_354770
https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_356839
last chunk of https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_356839

For some extra context, even an application and game developer or two came in this issue asking GNOME to support SSDs:

https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_356424

Overall, this is still a problem all these years after that issue’s creation, over in GNOME Wayland, mainly because GNOME is too enticed in wanting to fulfil their technically flawed CSDs-only world I guess.

I’d recommend reading through all of it in your spare time.

Please… everyone, it’s time we settle our differences and provide a big enough constructive feedback force for GNOME to implement Server-Side Decorations support. Don’t be toxic about it, and definitely do not accept this dick move, period, but if we can come together as a community maybe the situation might change for the better if we can show GNOME there’s enough support for Server-Side Decorations support.

PS: Chances are this’d be complex to implement, so… I’d honestly like, if enough force comes in, developers to assist GNOME in implementing this if they decide they want to implement this in the end. They probably messed up by not accounting for this possibility, so I’m sure they’d appreciate help implementing support if they do decide to implement support for XDG-Decoration.

Anyway, enough about that. Remember, this is just one side of the coin regarding GNOME and not everyone at GNOME is like this at all.

The fanboyism/fangirlism issue in reviews

Now, the main brunt of this article and the actual reason (no, GNOME’s SSDs situation wasn’t actually the reason at all) I wanted to write this up — reviews.

Now, I’m gonna be mentioning GNOME 40 reviews as an example, but don’t stick any pitchforks up against GNOME — I could say the exact same about KDE Plasma releases, for example.

With the release of GNOME 40, there has been an almost suspicious amount of reviews where they’re all extremely positive… now this wouldn’t be a problem if it wasn’t for how… simpy they seem to be. I can barely name any reviews that actually mention at least one negative thing they have against GNOME 40, and that’s a problem as it makes it look like you’re simping for GNOME, in a similar way to when someone is paid enough money for a positive review in business.

In my eyes, the best kind of review would be one which nails that balance I mentioned earlier, exactly at ‘constructive feedback’, where it goes over both positives and negatives in their impressions of GNOME 40. For example, I really like the spit and polish that GNOME 40 has, and the style of it, but I really dislike the SSDs situation, their lack of care for other Linux application ecosystems like Qt5, their lack of a dark mode option (apparently they’re working on that now just like elementary OS…?), and a bunch of other things. That, in a review where those issues are also outlined and solutions suggested for them, such as theming Qt5 applications like Fedora does, and so on, would make a perfect review.

Go and mention them again. It might sound obnoxious, but the more you drill it into the reader’s heads the more they’ll get that it’s an issue that should be noticed, in my honest opinion. Others might call it nagging, but it’s better than letting that issue go by the wayside like I’ve seen happen too many times before. Given you’re a reviewer, after all, in this scenario, it’d mean then that more of your readers know you’re having said issue, can check if they’re encountering it too, potentially, and then, if they are, help let developers know what issues are truly affecting the most people by assigning themselves as also encountering said issues on adequate bug trackers.

I think I should also probably make this clear — someone who has negative impressions of a project, such as Dedoimedo in their GNOME 40 Review, is not HATING that project. They’re just passionate, and in many ways that’s a good thing.

They never attacked GNOME directly, they just expressed their opinions in their own ways… yes, it’s a very negative sounding review in this example with a clickbait title, but if they really ‘hated’ GNOME 40 they wouldn’t provide ANY pluses in their review.

That being said, I think it’s important to stress this for reviews in general. This mindset people have of it being ‘hate’ is likely a reason so many reviews are practically just simping for projects — because you all, as the Linux Community, scared them out of being honest by accusing them of drama, hatred, and whatnot!

Finally, don’t worry about us developers — if you’re giving us constructive criticism, we can handle it, and we’ll most likely make use of it to make the software you use better — if you bottle your true thoughts up about software, those issues you have will remain unless someone else tells developers about them. Just don’t be toxic or too negative, and you’ll be gouchie, in my honest opinion.

Look, I could probably say the same about KDE Plasma — granted, it’s got way more good to it in my honest opinion, but I can definitely think of multiple negatives, such as touchification ruining some of the user experience of Plasma Desktop (less Global Menu support, and so on), a Plasma Style system that’s way too restrictive right now, a complicated-looking translation process, System Settings being not so well laid out in my honest opinion, and more. There, I’m no Plasma simp, I can point out issues.

The Elephant in the room

Guess I’ll also append this to the post in case: Yes, fanboyism and fangirlism is also a problem for the generic reason that it spawns toxicity against other platforms. That’s a problem, too.