Author: Thom Holwerda
Source
There’s no denying that the browser is the single-most important application on any operating system, whether that be on desktops and laptops or on mobile devices. Without a capable, fast, and solid browser, the usefulness of an operating system decreases exponentially, to the point where I’m quite sure virtually nobody’s going to use an operating system for regular, normal use if it doesn’t have a browser. Having an at least somewhat useable browser is what elevates an operating system from a hobby toy to something you could use for more than 10 minutes as a fun novelty. The problem here is that making a capable browser is actually incredibly hard, as the browser has become a hugely capable platform all of its own. Undertaking the mammoth task of building a browser from scratch is not something a lot of people are interested in – save for the crazy ones – made worse by the fact that competing with the three remaining browser engines is basically futile due to market consolidation and monopolisation. Chrome and its various derivatives are vastly dominant, followed by Safari on iOS, if only because you can’t use anything else on iOS. And then there’s Firefox, trailing far behind as a distant third – and falling. This is the environment desktop Linux distributions find themselves in. For the longest time now, desktop Linux has relied virtually exclusively on shipping Firefox – and the Mozilla suite before that – as their browser, with some users opting to download Chrome post-install. While both GNOME and KDE nominally invest in their own two browsers, GNOME Web and Falkon, their uptake is limited and releases few and far between. For instance, none of the major Linux distributions ship GNOME Web as their default browser, and it lacks many of the features users come to expect from a browser. Falkon, meanwhile, is updated only sporadically, often going years between releases. Worse yet, Falkon uses Chromium through QtWebEngine, and GNOME Web uses WebKit (which are updated separately from the browser, so browser releases are not always a solid metric!), so both are dependent on the goodwill of two of the most ruthless corporations in the world, Google and Apple respectively. Even Firefox itself, even though it’s clearly the browser of choice of distributions and Linux users alike, does not consider Linux a first-tier platform. Firefox is first and foremost a Windows browser, followed by macOS second, and Linux third. The love the Linux world has for Firefox is not reciprocated by Mozilla in the same way, and this shows in various places where issues fixed and addressed on the Windows side are ignored on the Linux side for years or longer. The best and most visible example of that is hardware video acceleration. This feature has been a default part of the Windows version since forever, but it wasn’t enabled by default for Linux until Firefox 115, released only in early July 2023. Even then, the feature is only enabled by default for users of Intel graphics – AMD and Nvidia users need not apply. This lack of video acceleration was – and for AMD and Nvidia users, still is – a major contributing factor to Linux battery life on laptops taking a serious hit compared to their Windows counterparts. The road to even getting here has been a long, hard, and bumpy one. For years and years now, getting video acceleration to work on Firefox for Linux was complicated and unreliable, with every release of the browser possibly changing what flags you needed to set, and sometimes it would just stop working for several releases in a row altogether, no matter what you did. There’s a venerable encyclopaedia of forum messages, blog posts, and website articles with outdated instructions and Hail Mary-like suggestions for users trying to get it to work. Conventional wisdom would change with every release, and keeping track of it all was a nightmare. It’s not just hardware accelerated video decoding. Gesture support has taken much longer to arrive on the Linux version than it did on the Windows version – things like using swipes to go back and forward, or pinch to zoom on images. Similarly, touchscreen support took a longer time to arrive on the Linux version of Firefox, too. Often, such features could be enabled with about:config incantations for years before becoming enabled by default, at least, but that’s far from an ideal situation. With desktop Linux trailing both Windows and macOS in popularity, there’s nothing unexpected or inherently malicious about this, and the point of the previous few paragraphs is not to complain about the state of Firefox for Linux or to suggest Mozilla transfers precious resources from the Windows and macOS versions to the Linux version. While I obviously wouldn’t complain if they did so, it wouldn’t make much sense. The real reason I’m highlighting these issues is that if Firefox for Linux is already treated as a third wheel today, with Mozilla’s current financial means and resources, what would happen if Mozilla saw a drastic reduction in its financial means and resources? Firefox is not doing well. Its market share has dropped radically over the years, and now sits at a meagre 3% on desktops and laptops, and a negligible 0.5% on mobile. Chrome and to a lesser extent Safari have trampled all over the venerable browser, to a point where it’s effectively an also-ran for Linux/BSD users, and a few more nerds on other platforms. I’m not saying this to disparage those who use Firefox – I’m one of them – but to underline just how dire Firefox’ current market position really is. This shrinking market share must already be harming the development and future prospects of Firefox, especially if the slide continues. The declining market share is far from the biggest problem, however. The giant sword of Damocles dangling above Firefox’ head are Mozilla’s really odd and lopsided revenue sources. As most of us are probably aware, Mozilla makes most of
