gecko-b2g

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.