I'm part of the team maintaining the "boot 2 gecko" aka b2g fork (we push it to https://github.com/kaiostech/gecko-b2g https://github.com/kaiostech/gecko-b2g) s

I'm part of the team maintaining the "boot 2 gecko" aka b2g fork (we push it to https://github.com/kaiostech/gecko-b2g https://github.com/kaiostech/gecko-b2g) so I have some experience building a non-firefox product on top of gecko, and maintaining a non-upstream platform (the "android without java" stack called Gonk). 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.