There’s still a very long way before they can compete with Chrome, of course. And I’m not sure I ever understood the value proposition compared to forking an existing engine.
Another example is around ad blockers -- if Blink is the only option, they can make it hard for ad blockers to function whereas having other engines allows different choices to be made.
It’s that Chrome and V8’s implementation has grown to match resourcing. You probably can’t maintain a fork of their engine long-term without Google level funding.
there by definition is no vendor lock-in by forking an open-source engine. The worst case is the original maintainers going evil tomorrow and you being on your own, which is no worse than starting from scratch, except you saved yourself some ten million odd lines of mindless spec implementation in the case of a browser.
If you fork that monopolist’s engine, you’re not making any immediate difference to the market. You’ll adopt all their existing behavior, whether or whether not it conforms to spec (and I would guess you would continue to pull in many of their changes down the road).
A brand new implementation is much more difficult, but if it works it’s much more meaningful in preventing a monopoly.
It's like projects trying to keep Firefox XUL alive, or GTK+ 2 or 3.
The project has now moved from just updating the external dependency to working on that and possibly actively fighting against the tide. That is a lot harder and requires more work each time you update the dependency.
So in effect you have vendor lock-in. And if the vendor controls or affects downstream products like plugin developers (targeting manifest V3) or application developers (targeting GTK+ 3 or 4) then its even harder to maintain support for the other functionality.