While Gecko should absolutely be made available for iPhone, it’s worth noting there’s nothing wrong with WebKit per se. It’s open source (forked from KHTML), servers as the base for among others the GNOME Web browser, and is not a monopoly player (outside of iPhones).
In some messed up way, Apple’s WebKit insistance has helped competition in the browser market by making sure there’s at least one popular platform where Blink is not dominating…
Damn, I never saw it that way. In that regard the EU regulation could actually harm the browser market, because it lowers the incentive for service providers to support anything but Chrome. At the moment that would exclude all iPhone users (which hurts business, because that’s a lot of users with large pockets). But then they could simply shrug and tell their users to install Chrome. 😐️
In the other way, there are multiple hacky workarounds needed for bugs Apple is too lazy to fix, since everyone has implemented workarounds on their end.
I guess the pendulum swings in both ways… luckily, there are enough people using firefox on desktop , so that at least gecko is supported basically anywhere (this would still apply to webkit since most iPhone user just use the standard and don’t bother installing alternative browsers, except if their business uses Microsoft which forces you to have edge installed to open links from teams)
There’s nothing wrong with Blink per se either. It’s open source, forked from WebKit. This argument that a free open source project becoming a monopoly is a problem has some fundamental issues with it. Not to mention there are glaring counterexamples. The Linux kernel, the GNU suite among many others.
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.
It doesn’t really compare to Linux very well, as it’s very rare for an application to only support linux unless it’s very niche or for some reason tied to Linux. You don’t go to some government service site and have it show a banner “sorry, we only tested this on Linux, everyone else use that.”
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.
While Gecko should absolutely be made available for iPhone, it’s worth noting there’s nothing wrong with WebKit per se. It’s open source (forked from KHTML), servers as the base for among others the GNOME Web browser, and is not a monopoly player (outside of iPhones).
In some messed up way, Apple’s WebKit insistance has helped competition in the browser market by making sure there’s at least one popular platform where Blink is not dominating…
Damn, I never saw it that way. In that regard the EU regulation could actually harm the browser market, because it lowers the incentive for service providers to support anything but Chrome. At the moment that would exclude all iPhone users (which hurts business, because that’s a lot of users with large pockets). But then they could simply shrug and tell their users to install Chrome. 😐️
In the other way, there are multiple hacky workarounds needed for bugs Apple is too lazy to fix, since everyone has implemented workarounds on their end. I guess the pendulum swings in both ways… luckily, there are enough people using firefox on desktop , so that at least gecko is supported basically anywhere (this would still apply to webkit since most iPhone user just use the standard and don’t bother installing alternative browsers, except if their business uses Microsoft which forces you to have edge installed to open links from teams)
There’s nothing wrong with Blink per se either. It’s open source, forked from WebKit. This argument that a free open source project becoming a monopoly is a problem has some fundamental issues with it. Not to mention there are glaring counterexamples. The Linux kernel, the GNU suite among many others.
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.
It doesn’t really compare to Linux very well, as it’s very rare for an application to only support linux unless it’s very niche or for some reason tied to Linux. You don’t go to some government service site and have it show a banner “sorry, we only tested this on Linux, everyone else use that.”
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