Otherwise if it's just on a whim of the lead dev, that often does not scale. And we've seen with lots of projects, that actual regular-user feedback, not power-users, is crucial in taking those decisions. Switching off telemetry is easy, but I suppose you also have concerns about technical issues, and those can be really difficult to compromise on (a lot of people suggested forks when XUL was removed.. but today probably very few people would want XUL back).
To have a successful fork, you need devs with either a business model behind it, or enough motivation to maintain it as a hobby. For a while, it worked for Iceweasel, but it was just branding. Firefox is complex, requires a lot resources to build, distribute binaries, etc.
I'm not affiliated to Mozilla, but I do help maintain another open source project, where, in my opinion, power-users and consultants drove the project in a direction that made the product more difficult to use, and therefore gave it a bad reputation and limited growth. I can say that because I have access to some of the telemetry, and also because I talk to a lot of random users as part of my work.
In general, that's true. But Firefox is an exception to this.
The most important thing to a regular user, is that their websites work. But for websites to work, the developer had to test in Firefox. So, Firefox's alienation of power users has hurt its regular userbase.
There's also the distinction between users vs customers. Most users pay nothing for Firefox. A relatively small number of free-software lovers provide donations. If they want more of those people to give more money, Mozilla would have to cater to power users. This leaves Mozilla's main customer as being Google, who doesn't really want Firefox to be good.
The other exception to this, is if the software you're making is so specialized, that you can get by on a handful of large institutional customers. Obviously this is not where Mozilla is, it's just another case where telemetry is not necessary.
It more read like some marketing FOMO inducing lingo like "use the new feature better now or you will miss out once they're gone".
Do you have a user panel at Mozilla to vet stuff like that? I would love to participate. Being a Moz suite user since 1998.
https://blog.mozilla.org/en/products/firefox/introducing-new...
But reading this and answering for Mozilla staff should get them some feedback:
> What’s next for Firefox colorways?
We’ll see. We’ll go where our customers take us.
Well, I saw and I clicked to skip this BS.
With that said, I don't really like telemetry and will turn it off.
Some of the replies to your question state "money" but there are also more fundamental reasons of choosing Chromium over Gecko: technical functionality and performance (especially on mobile).
You'd think an ex-Firefox programmer and Mozilla co-founder such as Brendan Eich would have chosen Gecko for Brave but he didn't. He explains in a previous comment why he switched from Gecko to Chromium: https://news.ycombinator.com/item?id=22062636
So the "hidden" reason people are not comfortable saying (except maybe Brendan Eich) is that Gecko isn't as good as Chromium as a foundation for forking. That's why you get a bunch of companies independently choosing Chromium instead of Gecko such as :
- Github Electron based on Chromium
- Qt QtWebEngine uses Chromium
- Opera Vivaldi switches from Presto to Chromium
- Microsoft Edge switches from Trident to Chromium
- Brave switches from Gecko to Chromium
Some speculate Gecko's MPL license instead of Chromium's BSD might also be a factor.
That said, I work on Gecko and it is indeed an old crufty codebase with numerous issues. From what I've seen of Blink, it seems surprisingly similar (overall; the specific problem areas are different). And Gecko has a surprising willingness to rewrite or revamp core aspects of the codebase -- by some metrics, it appears to be more nimble than Blink (eg, site isolation to separate processes was a massive project for both codebases, and it looks like although Gecko started and finished later, the elapsed time is a couple years less.)
On the other hand, Eich was pretty well in touch with the Gecko codebase, so his opinion should carry some weight. (Somewhat counterbalanced by his seeming enthusiasm for burning some bridges behind him, but that gets into very speculative territory.)
I tend to agree that Gecko isn't as good as Chromium as a foundation for forking, though. I think working with the Mozilla development community is actually quite a bit better than working with Chromium's, but Gecko is pretty unapologetically focused on Mozilla's product needs and Mozilla doesn't have the resources to properly support external embedders or forks.
Your "seeming enthusiasm for burning some bridges behind him" is bunk. On what did you base it?
Again, we started Brave based on Gecko (multiprocess sandboxed embedding via Graphene, which was developed for FirefoxOS). We did not just jump to Chromium upon founding. A startup is a no-BS/little-room-for-error setting with scarce capital. To suggest I did anything uneconomic out of spite is silly.
Perhaps "vague" is too loaded a word? I did not mean it as an insult or complaint, I was just pointing out the fact that the reasons were unclear because they were mentioned but not described. Twitter's character limit is a perfectly valid reason for that. And the literal meaning of the word "vague" applies perfectly.
> Your "seeming enthusiasm for burning some bridges behind him" is bunk. On what did you base it?
> ...To suggest I did anything uneconomic out of spite is silly.
I was not suggesting that.
Sorry, it seems I did not describe myself well. "Burning bridges" was not a reference to making anti-Gecko technical decisions. It's about unrelated public postings that I object to, but I don't think that here is a place to get into it.
I am confident that the bases for your technical choices were well-founded and I have no reason to suspect that they were made out of spite.
https://twitter.com/search?q=from%3A%40brendaneich%20mozilla...
and wondered which ones you meant. If I burned a bridge I should try to rebuild, let me know.
If you mean the ones about Mozilla holding back tracking protection while Monica Chew was there, or the ones about Mitchell's ridiculous salary, then we must disagree on "burning bridges". I'm not going back to Mozilla, and even if I hoped to, I see no reason to lie or self-censor about bad things they did after I left.
At some point we compared gecko with a blink port on Gonk, maintaining both while we were doing performance comparison on low end mobile devices. We were looking both at memory usage and page loading speed. I was expecting to see blink way ahead of gecko, but that was not the case at all. For some content blink was a bit better, for some it was gecko, but never with a large gap either.
Maintenance of the blink product was not easy, with barely documented internals changing a lot (it's very different to build a new product on top of blink compared to just fork an existing one like chromium). I'm not blaming the blink team, that makes sense in the context of what they do, and we were not as familiar with blink code base as with gecko. Finally we stayed on gecko because this was the best choice for us (eg. including team velocity and the amount of non standard apis to rewrite).
In my opinion if you want to start on a new browser product, the main Chromium benefits for a commercial project are: - web compat, which unfortunately is self sustaining. - licensing. The MPL vs. BSD doesn't matter for open source projects, but many companies (especially VC funded) are adverse to copyleft licenses. Gecko's xpcom architecture was actually not a bad fit with the MPL, since you can ship new xpcom components without publishing their code if you don't want, but that didn't make much of difference (some chipset vendors used the capability for FirefoxOS to replace the implementation of telephony apis with closed source ones).
But you need to be comfortable being subject to the whims of google (and a little bit MS now). For instance, consider the changes to web extension resource blocking capabilities with the "manifest v3": some forks plan to keep the resource blocking api working, but it's very unclear if they will be able to do so in the long term without a growing complexity of their fork that may become too high.
If you are an open source project, please don't cement Google's dominance of the web by using chromium.
Gecko deserves to have a future - it may just not be Mozilla's corp current leadership that is the best for that to happen.
I'd rather have the ability of ad-blocking and similar extensions to work on a deeper level, instead of crippling them, like on chromium-based browsers.
What about mono-culture and the risk there of?
edit: Availability of working DRM is what it all boils down to.
[1] https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
How do the people working on it get money to cover their bills? If they don’t have this they will work on something that does that.
A financial model is usually the blocker.
Consider this, a lot of the people who work on Linux or many other projects are corporate backed. The companies pay the developers.
Maybe we need more 501c3 and benefit corps providing basic stuff like an internet browser?
They've already adopted some infrastructure software projects into their governmental operations, not only using them, but also participating and maintaining them.
They also have many initiatives mandating the use of open source where applicable, and also suggestions of liability for closed source software by law. Harr! Unheard of! Those naughty Gauls!
https://news.ycombinator.com/item?id=29106440
Another is that doing so, and sustaining the effort, is a non-trivial amount of work. Throwing up a web page and a single release is one thing. Keeping up with the release cadence of an org like Mozilla, and the demands and expectations of a browser user base is something entirely different.
Also, "Libre" is a terrible moniker.
But that's a symptom of a different pair of issues, namely: (1) it's ambiguous what language the word is in, and (2) neither of those languages are really tech field lingua francas (English, Russian, maybe Hindi, probably in that order).
For me, as a fan of open source, Libre-something means something focused on being open source, than being a good product. And in my humble opinion, open source governance is generally not good at making big sweeping, or even just focused changes when needed, so the "Libre" moniker to me has an aftertaste of "good enough, but could be much better" compared to commercial offerings or products that have paid volunteers and stronger governance.
Something called Libre usually means it will never get nor accept any paid sponsorship, and sometimes it's what is needed to turn a decent open source product into a killer product.
None of these things are rooted in hard facts, that's the "feeling" the libre word gives me. To be honest, the only popular libre products I know of are LibreOffice (just good enough IMO) and LibreSSL, which was born after the OpenSSL fiasco, yet is still living in the shadow of OpenSSL. The "Open" word has similar shortcomings, but is less strict that the definition of libre and thus carries fewer negative connotations in my view.
Even their own developers objected to the policy, but they went ahead anyway.
That's incredibly vague. Can you explain? How are the many forks/variants of Chromium and WebKit not affected by this "money" factor in the same way
> How are the many forks/variants of Chromium and WebKit not affected by this "money" factor in the same way
They are, but the main Webkit/Chromium forks are either large companies (microsoft) or companies trying to make money off of their forks (Brave, Vivaldi).
This here is trying to do the exact opposite. Vivaldi has ~50 employees, Brave has 150 and tens of millions in investments. Even if not all of them work on the fork management, that's a lot more resources than a dozen peeps doing that in their spare time.
More seriously, is the suggestion that FF is too complex to properly fork without full time devs?
The same is true of Chromium, btw.
>> is the suggestion that FF is too complex to properly fork without full time devs?
How many Chrome forks don't have "full time devs"? A lot of them (Vivaldi, Opera) aren't even open source!
The only one I can think of is ungoogled Chromium which is basically equivalent to this Firefox one in that the actual changes being made are miniscule.
>>>It's 20 million lines of security sensitive code. Of course it's difficult to properly fork.
Did you forget to switch accounts? Which is it? Easy or hard?
No, but nice accusation.
> Which is it? Easy or hard?
Could you spell out what the contradiction is, here? I said it's hard to fork both browsers, and then pointed out that the only real "community" ones are miniscule patchsets which pretty much exclusively delete code - that even then, the list is only one or two forks long for each browser - and the rest all have multiple full-time professional devs behind them.
Company trying to make money off of its fork.
> Vivaldi
Company trying to ???
> Edge
Microsoft, who found that maintaining a chrome fork would be less expensive than playing catch-up with their own in-house browser.
Examples of this are the Electron Framework [0], Vivaldi, Brave, Opera, Yandex, Edge, etc.
Firefox instead is a nightmare to fork. They used to have something called XulRunner[1] that allowed to create your own XUL application (things like Seamonkey, Thunderbird used it) thus making it fairly easy to fork Firefox. After the 41 release Mozilla removed it completely. XulRunner's components were intertwined with Firefox code. Mozilla deliberately killed the easiest way to work their product.
Only light forks like Waterfox, LibreWolf are viable. Hard forks fail or struggle every single time Mozilla releases a new version (SeaMonkey, Waterfox Classic, Pale Moon, etc), lagging behind in features and performance.
Even WebKit is easier to integrate with your own UI (Safari, Gnome Web [2], etc).
[0] https://en.wikipedia.org/wiki/Electron_(software_framework)
The choice between forking Chromium and Firefox is mainly one of business[0]: Chrome has a >70% global marketshare, adding Edge & co even ignoring Safari it's probably around 80. Since Google also keeps pushing their own stuff, that means forking Chromium gives you much better compatibility guarantees.
[0] though the history of Chromium — and Webkit before that — forks also means there's probably a lot more knowledge floating around about maintaining such a fork, especially since Chromium itself was originally a fork (running concurrently with its source and regularly synch-ing from it, forking a dead codebase or hard-forking with no sync is a different concern)
Firefox forks tend to dislike associating with any of the above.
It's still not comparable for a fairly simple reason: the list of companies in the world that are as big as Microsoft consists of Google, and Apple, both of whom already have their own browsers.
As for why Microsoft chose Chromium, it's probably a combination of marketshare, the fact that it is a bit more cleanly architected as a result of having a decade less history than Gecko does, and the fact that they have ambitions of making a stripped down version of Electron part of the standard Windows userspace.
Options:
1. Fork Firefox, people install Chrome anyway 2. Fork Chromium, some people realize that it's essentially the same as Chrome and don't install Chrome and just use Edge
Also, especially on mobile, Firefox is an extremely niche browser engine. The biggest browser forks in therms of global user count are actually not the likes of Edge, Brave, etc, but android Chromium forks popular in asia.