OK, this is the standard argument so I’ll try to shine a light into the holes in it.
Blink is open source, but it’s more in a look-but-don’t-touch sort of way. Google uses their position to push their own standards without consulting others. This has the effect of making the web less open, since it is more closely tied to a single implementation.
The first part where it’s open source in a look-but-don’t-touch way is obviously false since anyone entity can fork Blink and change it in the manner they see fit. For example to remove changes done by Google they disagree with. This is not a hypothetical, there are multiple forks that do this and are used by enough people to show on market share charts.
Then the next part about Google driving changes into Blink that hurt the open web, which is true, falls apart because of the above hole. There already are forks that do this. The open web doesn’t see the browser source code, just its behavior. A Blink fork that doesn’t support Google’s new DRM dream or Privacy Sandbox for example is no different to a web app that looks for these features than Gecko without support for them in this regard. The effect of X% of browsers supporting DRM and Y% not on the open web is the same regardless of exactly what source code was used to compile those browsers.
So let me add another leaky argument that’s typically leveled against the forking solution - that it’s too difficult and that Google can make it even more difficult. The software engineering world has lived with large forks since the beginning of the open source movement. Maintaining a fork even of a codebase as complex as Blink is not an insurmountable task. In fact browser engines have been forked and maintained for a long time proving this is false. We even have an example of maintaining forks of Google’s projects. The Android OS comes to mind. This is actually one I personally have lived with as part of my job. CyanogenMod lived with it, along with all the currently active projects today. The amount of work needed to reimplement large codebases is not smaller than the effort needed to change parts of it, until these parts begin approaching the size of the modules they change. It might look easier way to inexperienced engineers but this is proven to be false by the existence of counterexamples.
Finally on the point of Linux, there’s plenty of important applications that do use APIs only available on Linux, which hasn’t been POSIX for a long time. Just look at the massive use case of Linux containers and the large software projects using it - Docker, Podman, etc.
In conclusion, when Google makes changes to Blink that people disagree with, it gets forked. That’s already a reality and by all accounts much smaller teams than Google’s are able to do this. This is true for all forkable open source projects and It’s not unique to this situation. It’s a fundamental difference between open source projects and proprietary where this defensive option is not available. Monopoly of a proprietary software can absolutely and often does cause harm to it’s users. Open source software under a license that allows forking simply cannot do this.
All of the above is grounded in fact.
Now on an opinion note, I think Mozilla can actually have stronger counterbalance effect if they forked Blink removed disagreeable features from it, implemented theirs, and replaced Gecko with it. Replacing Gecko would remove the “I can’t use Firefox because it doesn’t work for X” that is currently hampering its adoption. Where X isn’t one of the disagreeable features of course. If Opera can do it, so can Mozilla. In fact if they did that, chances are that every other browser that is in alignment will switch to Mozilla’s fork instead of maintaining their own, increasing Mozilla’s influence over the direction of web standards.
In case you’re taking me for someone that doesn’t believe in Mozilla’s mission, I do use Firefox and contribute a monthly sum to Mozilla.
OK, this is the standard argument so I’ll try to shine a light into the holes in it.
The first part where it’s open source in a look-but-don’t-touch way is obviously false since anyone entity can fork Blink and change it in the manner they see fit. For example to remove changes done by Google they disagree with. This is not a hypothetical, there are multiple forks that do this and are used by enough people to show on market share charts.
Then the next part about Google driving changes into Blink that hurt the open web, which is true, falls apart because of the above hole. There already are forks that do this. The open web doesn’t see the browser source code, just its behavior. A Blink fork that doesn’t support Google’s new DRM dream or Privacy Sandbox for example is no different to a web app that looks for these features than Gecko without support for them in this regard. The effect of X% of browsers supporting DRM and Y% not on the open web is the same regardless of exactly what source code was used to compile those browsers.
So let me add another leaky argument that’s typically leveled against the forking solution - that it’s too difficult and that Google can make it even more difficult. The software engineering world has lived with large forks since the beginning of the open source movement. Maintaining a fork even of a codebase as complex as Blink is not an insurmountable task. In fact browser engines have been forked and maintained for a long time proving this is false. We even have an example of maintaining forks of Google’s projects. The Android OS comes to mind. This is actually one I personally have lived with as part of my job. CyanogenMod lived with it, along with all the currently active projects today. The amount of work needed to reimplement large codebases is not smaller than the effort needed to change parts of it, until these parts begin approaching the size of the modules they change. It might look easier way to inexperienced engineers but this is proven to be false by the existence of counterexamples.
Finally on the point of Linux, there’s plenty of important applications that do use APIs only available on Linux, which hasn’t been POSIX for a long time. Just look at the massive use case of Linux containers and the large software projects using it - Docker, Podman, etc.
In conclusion, when Google makes changes to Blink that people disagree with, it gets forked. That’s already a reality and by all accounts much smaller teams than Google’s are able to do this. This is true for all forkable open source projects and It’s not unique to this situation. It’s a fundamental difference between open source projects and proprietary where this defensive option is not available. Monopoly of a proprietary software can absolutely and often does cause harm to it’s users. Open source software under a license that allows forking simply cannot do this.
All of the above is grounded in fact.
Now on an opinion note, I think Mozilla can actually have stronger counterbalance effect if they forked Blink removed disagreeable features from it, implemented theirs, and replaced Gecko with it. Replacing Gecko would remove the “I can’t use Firefox because it doesn’t work for X” that is currently hampering its adoption. Where X isn’t one of the disagreeable features of course. If Opera can do it, so can Mozilla. In fact if they did that, chances are that every other browser that is in alignment will switch to Mozilla’s fork instead of maintaining their own, increasing Mozilla’s influence over the direction of web standards.
In case you’re taking me for someone that doesn’t believe in Mozilla’s mission, I do use Firefox and contribute a monthly sum to Mozilla.
gets off soapbox