6 ms·

The only reason we cannot have a single browser engine that everyone uses is governance and ownership. That's the key problem with Chromium, it is largely unde

The only reason we cannot have a single browser engine that everyone uses is governance and ownership. That's the key problem with Chromium, it is largely under Google's thumb. If control of Chromium could be fairly split between Apple/Google/Microsoft/Mozilla/et al within a nonprofit, with no one party having ownership or override, Firefox could be Chromium based. The thing a lot of people ignore is that having one OSS engine that everyone uses is the most efficient way for all parties. You just have to solve governance and ownership, which aren't technical problems (they're about power). And, yes, standards would largely be dictated via this one monopoly-engine but again if governance and ownership were healthy that too wouldn't be problematic within itself (you could even include standards orgs/committees within the structure). User choice would largely be the add-ins, unique settings, niche features, and UI (see Chrome Vs. Edge Vs. Brave, for example).

ethbr0 5y ago
The failure mode of a single shared engine is extremely brittle. What would happen if that engine decided to ignore standards bodies? (coughMicrosoftAppleGooglecough) What would happen if a single party managed to upsurp governance and obtain de facto single party control? Better to have 2+ options, so there's always a "What if..." life raft.
- 323 5y ago
  Does this criticism also apply to the Linux kernel? Which is as widely used as Chrome on servers?
  - samwillis 5y ago
    There are other OSs available though. Including other POSIX compliant OSs
  - addicted 5y ago
    There's at least Windows, macOS, FreeBSD as popular and fairly used alternatives. Also, the Linux kernel itself is just one small part of a Linux distro, which means everyone from kernel maintainers, to distro creators/maintainers, to particular app makers have some direct to indirect sway on the kernel development.
    - 323 5y ago
      You could say the same about WebKit, that it's just a small part of a browser - Chrome/Safari/Edge/Brave/...
      - moron4hire 5y ago
        Note that Chromium hasn't been based on WebKit for almost a decade. Google forked WebKit and created Blink as their rendering engine in 2013. The two have diverged quite a bit. Safari is the only major browser still based on WebKit explicitly. Chrome, Edge, Brave, Samsung Internet, etc., are all based on Chromium and thus have Blink as their rendering engine.
- mminer237 5y ago
  If Microsoft, Apple, and Google all disagree with WHATWG or W3C, they're winning regardless of whether or not Firefox exists. The second scenario is just repeating the problems with Chromium. In theory, if one engine was agreed upon as ideal and collaborated on fairly, the other parties could just fork it and maintain that branch separately from the usurper and make that the standard.
  - ethbr0 5y ago
    The hypothetical here is FLoC. If everything were based on Chromium, and Google really wanted FLoC, how would that play out? They'd add support to the codebase and... what? Everyone else would fork? Or how about for DRM support? It's the "collaborated on fairly" that's the difficult and unsustainable piece. Especially when we're talking last mile things (i.e. that interact with the user) and the additional rewards those entice less altruistic parties with. Java/Oracle/IBM is what you realistically get when there's serious $$$s on the table and multiple parties. And that's probably about the best possible outcome.
- Shish2k 5y ago
  What happens when the Linux kernel decides to ignore standards bodies? What happens if a single party manages to usurp governance?
  - ethbr0 5y ago
    "The Linux kernel", in this analogy, doesn't also own a major cloud platform and/or device ecosystem and/or top ranked websites. I think in the 21st century we should have clearer glasses about what key enablers corporations can leverage to push their visions, even on ostensibly open source codebases.
  - otherotherchris 5y ago
    Google did this with Android. It's GPLv2, 'standards bodies' (and Linus, but he seems to be cool) can go pound sand.
123pie123 5y ago
daft question, but could mozilla fork Chromium and run it more openly?
- mulmen 5y ago
  Firefox is open source and predates Chromium. Why didn’t Google just contribute to Firefox?
  - deleted 5y ago
    [deleted]
- Someone1234 5y ago
  Sure, but what is the leverage for others to join their fork? If Chromium had better governance that is "leverage" for Mozilla to join as an equal party and for them all to work together on a single engine.
- curt15 5y ago
  Does Mozilla have the resources to maintain a Chromium fork?
VWWHFSfQ 5y ago
Google tried this with WebKit. But they had to fork it to Blink because Apple is a very poor steward of open source. So that will always be the problem.
- samwillis 5y ago
  Google forking WebKit to make Blink has nothing to do with pore stewardship of open source. They have different agendas and Google wanted total control.
  - saagarjha 5y ago
    Indeed. WebKit has historically been managed fairly reasonably by the team–at least, about as well as you'd expect a corporate-backed project to work.
samwillis 5y ago
I disagree that this would be a good idea. I think it’s important that the Standard rather than an Implementation is the source of correctness. Also, rendering engines are so tightly tied to the underlining drawing apis of different platforms this would be impractical and stifle innovation. Safari, for example, is more closely tied to the drawing apis in iOS and MacOS, which in turn are tuned to the hardware Apple sells. This allows it to be more energy efficient, particularly on mobile. You could abstracts the drawing with an intermediate api, but that prevents different browsers from experiments or moving toward different drawing architectures.
- BenoitEssiambre 5y ago
  I've made this comment before. It seems to me that there is an almost unsolvable information theoretic problem with the human language spec approach. Browsers need to have a standard specification for interoperability and one that includes an open source reference implementation of the core parts. Chromium seems to have become that standard. I argue here against pure natural language specifications in favor code based specs. I just don't think human language is nearly precise enough to write an adequate specification. Natural language words are incredibly polysemic and contextual. Look for example, at how many meanings the word "break" has: https://www.merriam-webster.com/dictionary/break https://www.merriam-webster.com/dictionary/break Kolmogrov has long ago suggested that fully specified information distills down to a computer program: https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity, https://en.wikipedia.org/wiki/Minimum_description_length https://en.wikipedia.org/wiki/Minimum_description_length The ideal language for a pure specification might be a mix of natural language and pseudo code with a pseudo test suit. However, if you are writing that, you might as well go one step further and write working testable code. Other technical fields usually go beyond language for specifications, using blueprints and diagrams which are their version of code. There is also an history of trying to tackle the inadequacy of natural language for technical specifications. A pioneer of this is Donald Knuth with his Literate Programming (https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming) and the descendant concepts of having code with extractable inline comments that you can use to auto generate documentation. https://en.wikipedia.org/wiki/Documentation_generator https://en.wikipedia.org/wiki/Documentation_generator I would argue that modern platforms with pull request based workflows that tie discussions to version controlled code changes are also the progression of this line of thought. A cleaned up version of these might make sense for a specification. And I get some of the concerns. While natural language under specifies, reference implementations over specify. This is more of a problem with low level languages however. Modern, high level languages are getting fairly close to a form of pseudo code. I fully agree that the reference implementations shouldn't contain or should hide, low level optimizations. I also understand that reference implementations can unduly tie specs to specific hardware, OSs and platforms. But to me, over-specification is less of a problem than under-specification and it can be mitigated by labeling particular functions or blocks of code as implementation specific and not part of the spec. Without spec written in code, the different implementations always have subtle incompatibilities. I see egregious versions of under-specification in government where horrendously vague specs are created in order to issue RFPs for getting software built. They usually end up with non working software at mind blowing cost. People have this weird misconception that they are contracting out to build software. They are not. Building software is really easy. You press the build button or type the compile command. Building software has been fully automated for a while now. What is difficult is designing software and specifying what it must do. This is because there is a vast jungle of protocols, business flows, hardware and software platforms that need to be interacted in different ways for different needs. This is what needs to be specified and only computer code can do it adequately. I wish that Mozilla adopted the chromium core. We really need a well funded non-profit managed release of the reference browser.
mfer 5y ago
> The only reason we cannot have a single browser engine that everyone uses is governance and ownership. Consider the governance and ownership angle a little more. Apple, Google, and Microsoft are LARGE companies. These companies do things that many have ethical issues with. Putting a bunch of large companies in such a point of control is something that should give people pause. Large multi-national companies aren't democracies and their end goals are fiduciary responsibilities to shareholders. These are often super wealthy or large funds.
phendrenad2 5y ago
Firefox doesn't help with this though. Chromium is technically superior, thanks to all of the money Google has invested in it. Chromium is open-source and there are many popular forks (Edge, Brave, Opera, Vivaldi, ungoogled). Those forks provide a much more robust "safety net" than Firefox does. If Google starts pushing something egregious on users, I'm sure Vivaldi and Brave would jump at the opportunity to promote their forks without that problem. And have you seem the Edge ads?
kaba0 5y ago
If you only have a single implementation of a standard, you don’t have a standard.
sfink 5y ago
Incorrect. The easiest place to see where this breaks down is in backwards compatibility. Web browsers need to be backwards compatible with the vast majority of web pages out there. That's half the point of the Web. If you define standards by implementation, you can never fix bugs once web sites start using them. (If you think you can just tell web sites to suck it up, consider the vast number of configuration web pages burned into ROM. And yes, they do use new features.) The standards themselves have this problem already, even though they're at a much higher level. (See Appendix B in the JS spec, for example.) The problem is far, far worse at the lower level of implementation. Relying on a single implementation will quickly produce the next IE6. And if you think Google programmers (or any company X's programmers) are good enough to avoid that sort of thing, then consider how well resourced those programmers will become once there's no longer competition or even a basis for comparison. Monoculture is bad, m'kay? (More detailed argument: https://blog.mozilla.org/sfink/2013/02/14/browser-wars-the-game/ https://blog.mozilla.org/sfink/2013/02/14/browser-wars-the-g... )
dblohm7 5y ago
Would such shared stewardship of Chromium really help, though? I don't believe that a shared governance structure for Chromium would stop Google from going their own way with Chrome, while effectively yielding the same problems. "Oops, we added this experimental feature to Chrome, now it's be come a de facto standard, I guess you all had better let us upstream it!" EDIT: Or even worse, they stop upstreaming anything at all!

ethbr0 5y ago

The failure mode of a single shared engine is extremely brittle. What would happen if that engine decided to ignore standards bodies? (coughMicrosoftAppleGooglecough) What would happen if a single party managed to upsurp governance and obtain de facto single party control? Better to have 2+ options, so there's always a "What if..." life raft.

323 5y ago
Does this criticism also apply to the Linux kernel? Which is as widely used as Chrome on servers?
- samwillis 5y ago
  There are other OSs available though. Including other POSIX compliant OSs
- addicted 5y ago
  There's at least Windows, macOS, FreeBSD as popular and fairly used alternatives. Also, the Linux kernel itself is just one small part of a Linux distro, which means everyone from kernel maintainers, to distro creators/maintainers, to particular app makers have some direct to indirect sway on the kernel development.
  - 323 5y ago
    You could say the same about WebKit, that it's just a small part of a browser - Chrome/Safari/Edge/Brave/...
    - moron4hire 5y ago
      Note that Chromium hasn't been based on WebKit for almost a decade. Google forked WebKit and created Blink as their rendering engine in 2013. The two have diverged quite a bit. Safari is the only major browser still based on WebKit explicitly. Chrome, Edge, Brave, Samsung Internet, etc., are all based on Chromium and thus have Blink as their rendering engine.
mminer237 5y ago
If Microsoft, Apple, and Google all disagree with WHATWG or W3C, they're winning regardless of whether or not Firefox exists. The second scenario is just repeating the problems with Chromium. In theory, if one engine was agreed upon as ideal and collaborated on fairly, the other parties could just fork it and maintain that branch separately from the usurper and make that the standard.
- ethbr0 5y ago
  The hypothetical here is FLoC. If everything were based on Chromium, and Google really wanted FLoC, how would that play out? They'd add support to the codebase and... what? Everyone else would fork? Or how about for DRM support? It's the "collaborated on fairly" that's the difficult and unsustainable piece. Especially when we're talking last mile things (i.e. that interact with the user) and the additional rewards those entice less altruistic parties with. Java/Oracle/IBM is what you realistically get when there's serious $$$s on the table and multiple parties. And that's probably about the best possible outcome.
Shish2k 5y ago
What happens when the Linux kernel decides to ignore standards bodies? What happens if a single party manages to usurp governance?
- ethbr0 5y ago
  "The Linux kernel", in this analogy, doesn't also own a major cloud platform and/or device ecosystem and/or top ranked websites. I think in the 21st century we should have clearer glasses about what key enablers corporations can leverage to push their visions, even on ostensibly open source codebases.
- otherotherchris 5y ago
  Google did this with Android. It's GPLv2, 'standards bodies' (and Linus, but he seems to be cool) can go pound sand.

123pie123 5y ago

daft question, but could mozilla fork Chromium and run it more openly?

mulmen 5y ago
Firefox is open source and predates Chromium. Why didn’t Google just contribute to Firefox?
- deleted 5y ago
  [deleted]
Someone1234 5y ago
Sure, but what is the leverage for others to join their fork? If Chromium had better governance that is "leverage" for Mozilla to join as an equal party and for them all to work together on a single engine.
curt15 5y ago
Does Mozilla have the resources to maintain a Chromium fork?

VWWHFSfQ 5y ago

Google tried this with WebKit. But they had to fork it to Blink because Apple is a very poor steward of open source. So that will always be the problem.

samwillis 5y ago
Google forking WebKit to make Blink has nothing to do with pore stewardship of open source. They have different agendas and Google wanted total control.
- saagarjha 5y ago
  Indeed. WebKit has historically been managed fairly reasonably by the team–at least, about as well as you'd expect a corporate-backed project to work.

samwillis 5y ago

I disagree that this would be a good idea. I think it’s important that the Standard rather than an Implementation is the source of correctness. Also, rendering engines are so tightly tied to the underlining drawing apis of different platforms this would be impractical and stifle innovation. Safari, for example, is more closely tied to the drawing apis in iOS and MacOS, which in turn are tuned to the hardware Apple sells. This allows it to be more energy efficient, particularly on mobile. You could abstracts the drawing with an intermediate api, but that prevents different browsers from experiments or moving toward different drawing architectures.

BenoitEssiambre 5y ago
I've made this comment before. It seems to me that there is an almost unsolvable information theoretic problem with the human language spec approach. Browsers need to have a standard specification for interoperability and one that includes an open source reference implementation of the core parts. Chromium seems to have become that standard. I argue here against pure natural language specifications in favor code based specs. I just don't think human language is nearly precise enough to write an adequate specification. Natural language words are incredibly polysemic and contextual. Look for example, at how many meanings the word "break" has: https://www.merriam-webster.com/dictionary/break https://www.merriam-webster.com/dictionary/break Kolmogrov has long ago suggested that fully specified information distills down to a computer program: https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity, https://en.wikipedia.org/wiki/Minimum_description_length https://en.wikipedia.org/wiki/Minimum_description_length The ideal language for a pure specification might be a mix of natural language and pseudo code with a pseudo test suit. However, if you are writing that, you might as well go one step further and write working testable code. Other technical fields usually go beyond language for specifications, using blueprints and diagrams which are their version of code. There is also an history of trying to tackle the inadequacy of natural language for technical specifications. A pioneer of this is Donald Knuth with his Literate Programming (https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming) and the descendant concepts of having code with extractable inline comments that you can use to auto generate documentation. https://en.wikipedia.org/wiki/Documentation_generator https://en.wikipedia.org/wiki/Documentation_generator I would argue that modern platforms with pull request based workflows that tie discussions to version controlled code changes are also the progression of this line of thought. A cleaned up version of these might make sense for a specification. And I get some of the concerns. While natural language under specifies, reference implementations over specify. This is more of a problem with low level languages however. Modern, high level languages are getting fairly close to a form of pseudo code. I fully agree that the reference implementations shouldn't contain or should hide, low level optimizations. I also understand that reference implementations can unduly tie specs to specific hardware, OSs and platforms. But to me, over-specification is less of a problem than under-specification and it can be mitigated by labeling particular functions or blocks of code as implementation specific and not part of the spec. Without spec written in code, the different implementations always have subtle incompatibilities. I see egregious versions of under-specification in government where horrendously vague specs are created in order to issue RFPs for getting software built. They usually end up with non working software at mind blowing cost. People have this weird misconception that they are contracting out to build software. They are not. Building software is really easy. You press the build button or type the compile command. Building software has been fully automated for a while now. What is difficult is designing software and specifying what it must do. This is because there is a vast jungle of protocols, business flows, hardware and software platforms that need to be interacted in different ways for different needs. This is what needs to be specified and only computer code can do it adequately. I wish that Mozilla adopted the chromium core. We really need a well funded non-profit managed release of the reference browser.

mfer 5y ago

> The only reason we cannot have a single browser engine that everyone uses is governance and ownership. Consider the governance and ownership angle a little more. Apple, Google, and Microsoft are LARGE companies. These companies do things that many have ethical issues with. Putting a bunch of large companies in such a point of control is something that should give people pause. Large multi-national companies aren't democracies and their end goals are fiduciary responsibilities to shareholders. These are often super wealthy or large funds.

phendrenad2 5y ago

Firefox doesn't help with this though. Chromium is technically superior, thanks to all of the money Google has invested in it. Chromium is open-source and there are many popular forks (Edge, Brave, Opera, Vivaldi, ungoogled). Those forks provide a much more robust "safety net" than Firefox does. If Google starts pushing something egregious on users, I'm sure Vivaldi and Brave would jump at the opportunity to promote their forks without that problem. And have you seem the Edge ads?

kaba0 5y ago

If you only have a single implementation of a standard, you don’t have a standard.

sfink 5y ago

Incorrect. The easiest place to see where this breaks down is in backwards compatibility. Web browsers need to be backwards compatible with the vast majority of web pages out there. That's half the point of the Web. If you define standards by implementation, you can never fix bugs once web sites start using them. (If you think you can just tell web sites to suck it up, consider the vast number of configuration web pages burned into ROM. And yes, they do use new features.) The standards themselves have this problem already, even though they're at a much higher level. (See Appendix B in the JS spec, for example.) The problem is far, far worse at the lower level of implementation. Relying on a single implementation will quickly produce the next IE6. And if you think Google programmers (or any company X's programmers) are good enough to avoid that sort of thing, then consider how well resourced those programmers will become once there's no longer competition or even a basis for comparison. Monoculture is bad, m'kay? (More detailed argument: https://blog.mozilla.org/sfink/2013/02/14/browser-wars-the-game/ https://blog.mozilla.org/sfink/2013/02/14/browser-wars-the-g... )

dblohm7 5y ago

Would such shared stewardship of Chromium really help, though? I don't believe that a shared governance structure for Chromium would stop Google from going their own way with Chrome, while effectively yielding the same problems. "Oops, we added this experimental feature to Chrome, now it's be come a de facto standard, I guess you all had better let us upstream it!" EDIT: Or even worse, they stop upstreaming anything at all!