[Barrin92]

>The value proposition is not having vendor lockin

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.

[justusthane]

I’m not an expert in this field, but I don’t think I agree. The problem with a browser monopoly is that the monopolist does not have to obey specs — you can just do whatever you want, and force the specs to follow you.

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.

[rhdunn]

The issue is around maintenance/development burden. For example, when manifest V2 was dropped in favour of manifest V3 it is possible for a downstream project (Edge, etc.) to maintain V2 support. However, that gets harder the further along the projects go and the code diverges; that may mean keeping more code around (if interfaces or utility classes are changed/removed), or rewriting the support if the logic changes (such as the network stack).

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.