Recent searches
Search options
Administered by:
so for years and years everyone on the correct side of the #tech politics spectrum has been weary of #mozilla foundation but also aware that the ... like 2%?... market share that #gecko holds among web engines is the only thing left from giving away the entire internet to google and apple.
whats keeping anyone from forking gecko and developing it separately? if the community rallies around it, then all the non-corpo aligned #foss browsers can build on it (significant proportion of them already do) and granted we have to give credit to mozilla but at least we don't have to constantly chase and disable every ai product they try to shove into their updates.
what am i missing?
@benda I've been curious about this too. I read some commenters suggesting that dumping Mozilla would cause the decline of its forks and/or the growth of Google. (I'm having 2024 US election flashbacks.)
But isn't that what forks are for? To fork code off before it gets shit? Should we be so concerned about markets? Isn't that what FOSS is for? Genuinely wondering.
@arendleejessurun yeah i think thats absolutely some dem-style notions of how software grows.
so off the fedi someone very wise said the biggest problem is pretty much money. ballpark of a million a year to operate. and i was kind of in disbelief but they pointed out that even microsoft stopped spending the money on it and just went with chrome.
but like... i dont think a million a year is impossible. i do think the time is right as a lot more people care about tech politics, and privacy and recognize how its affecting them. and like this is last stand. gecko is already practically dead.
maybe the correct first step is to get a lot more folks on librewolf? bc despite what i claimed, that i feel a lot of people are interested right now, theres almost no one using librewolf by the numbers.
@benda The herd mentality, what @witchescauldron would probably deride as #mainstreaming?
> whats keeping anyone from forking gecko and developing it separately?
It's already been done. Multiple times in fact, and all done by Pale Moon, with the final one in 2018 (due to XUL being completely abandoned by Mozilla).
The problem IMO is that Mozilla keeps participating in the WHATWG, which is ultimately a Google-led cartel controlling web browser development and enforcing its will on all other browsers with its agile attitude towards software development (if you don't implement this feature which was totally not pushed by Chrome developers at all with their "implement first, spec later" bullshit, too bad, you can no longer access 80% of the web). If WHATWG was really a net positive for the open web we wouldn't get DRM and "Web Components" (both of which contribute to actually closing the web, with the latter literally being meant for making proprietary extensions to HTML easier). WHATWG would be using its power to pressure web frameworks to not require the new JavaScript and CSS features they add, and prioritize backwards compatibility. They don't.
What we need is not just a fork, but a complete change in attitude towards web development. No more "moving and breaking things fast" and "implement first, spec later". No more "syntactic sugar" that turns JavaScript into C++ and break backwards compatibility. No more turning the web into a complete replacement of operating systems.
@job i agree with a lot of this but i think also we're at a point where we need a sizable shift in end-users' behavior before we can even address all the problems you've outlined. which again, i think are valid concerns. a web browser should not be running applications. given the internet is a shared resource, there should absolutely be well-defined and open standards. but if the entire web is geared for chrome and webkit, then its up to google and apple to decide if these things are important (spoiler alert...).
i'm not aware of Pale Moon and their work in this respect. Was pulling XUL the only reason for the project being abandoned? Because I'm talking about a hard fork. Fork and never look back. Whatever Moz does from here on out is independent of the fork's development. LIke libreoffice and openoffice. because, as you point out, moz cannot be trusted to do the right thing.
but if the entire web is geared for chrome and webkit, then its up to google and apple to decide if these things are important (spoiler alert…).
Indeed, but I think we’ve tried playing nice with them long enough in the hope that maybe they’d at least change their approach and backtrack on the bad stuff they made, and it just doesn’t seem to feel like the web is getting any better with what is pretty much a wait-and-see approach.
Independent web browser developers tried getting a license from Google for Widevine so we can at least try getting sites like Spotify and Netflix to work (with the latter having moved away from doing DRM via Silverlight, and I still think a plugin-based approach is best for DRM instead of baking it in to the web). They never gave any independent browser (including Pale Moon/Basilisk) such license, and so are doomed to never getting DRM-protected sites to work. It’s not a big deal personally for me and other libre activists who hate DRM, but I’ve seen people point to the lack of DRM support as dealbreakers…
We’ve also seen how Chrome devs suddenly removing their support for JPEG XL has killed momentum (and therefore influencing Mozilla’s decision to put JXL support in Nightly limbo) for the new image format which is arguably our best bet for replacing JPEG, PNG, GIF, and WebP all at once. And despite the backing of literally the JPEG org itself, ISO, and a large CDN provider, it wasn’t enough to change the minds at Chrome’s devteam. Yet despite this we’ve still decided to add JPEG XL support into Pale Moon anyway (and I know this because I’m the one who did the porting of JPEG XL support from an unmerged patch for Firefox, along with some original code to make it work for our codebase ;)). Ironically if it wasn’t for Apple (which itself is a backer of JXL’s proprietary competitor HEIC) surprisingly adding JPEG XL support to not just macOS but also WebKit, we might’ve seen another failed JPEG effort (since it happened before with JPEG XR which was then backed by Microsoft itself, and was supported by PM before, only to be stomped on by WebP). And speaking of Apple they might also ironically be the least evil of all browser engine vendors (and that’s saying something of Mozilla) because I’ve seen so many webdevs complaining of WebKit adopting new features too slowly to the point that they even get accused of being the “new IE”…
I can probably point to more examples, but I think I’ve made my point that for end-user behavior to be changed, we should start with not getting ourselves (i.e. web developers and browser developers) bound to what Google, Apple and Mozilla think are important. We will unfortunately have to be the examples where people refuse to be. That could mean small things like using a completely different browser regularly (even if not as a primary browser), to supporting JPEG XL right now in our websites for images if possible (and it can be done in a backwards-compatible way, even something as tiny as storing all JPEGs as JPEG XLs and serving just JPEG versions from lossless reencodings on-the-fly can help), to supporting DRM-free alternatives to Spotify (like Bandcamp and even Soundcloud) and Netflix (the latter is a bit tricky but if CDs and vinyl can be revived, why not DVD and Blu-ray?), and to larger ones like trying to reduce bloat in where-ever web projects we can touch and taking some spare time for contributing to the development of independent web developers (like I used to do with PM).
We still take some code from newer Mozilla codebases, but they're primarily security fixes that apply to us (because of shared heritage), or backports of newly implemented features in JavaScript for the sake of web compatibility. There are plenty of stuff done originally too, like some of the glue I wrote for JPEG XL, the build system (still supporting the native MSVC compiler and linker and newer ones too like 2022, which Mozilla has long since dropped support in favor of Clang), and CSS (where new features are implemented from scratch in C++ because newer Mozilla write the implementation in Rust now, which we didn't adopt). We've also applied fixes that Mozilla has not adopted.
@job i don't think i disagree with anything you've posted. but i think the difference between us is in what we identify to be the fundamental problem. to be fair, i took for granted that everyone would see it the way i do, so let me back up.
In my opinion, the fundamental problem is how much of the web engine market share is dominated by corpos, and in moz's case, corpo friendly orgs.
The reason I think this is a fundamental problem and not something we can simply brush aside and use whatever web engine we want to use personally, is because that market share influences web development and industry standards.
If 97% of the market is dominated by chrome and webkit, there's not much motivation or reason (esp. commercial reason) for developers to insure their sites work with respect to any sort of standard besides those dictated by google and apple.
now to be fair, i was chatting with someone else (who btw, speaks very highly of pale moon), and i also jumped the gun with respect to my proposition of forking and running. i imagine a scenario where the community forks, all the current FF end-users come on board, and then we run. leave mozilla for dead, and concern ourselves with having enough of a market share for sustainability (not number goes up. but more like linux, where number is big enough with supportive, ideological user base that can maintain it and keep it going). getting all the ff users onboard is the hardest part, but i don't think it's as hard as we might assume. i imagine that ff user base is one that is already concerned with corporate control of the web, whether or not they are tech savvy beyond changing their device's default browser.