Many developers work on the “web platform” because they believe in the model
of competing and interoperable implementations (i.e. browsers). These folks
(of which I am one) believe that competing and interoperable implementations is
what makes the web fundamentally stronger than other platforms. Unlike Windows,
iOS, or Android (for example), the web’s users have choice about how they
participate. If they disagree with how their chosen browser is being managed,
they can switch to
Without choice like that, users have no efficacy.
That’s why so many people feel threatened by the Chrome browser’s
ever-increasing dominance of the
It inspires them to use the term “monoculture” as a
for a future world where Chromium (the project that powers Chrome) is the only
Like any other hot-button issue surrounded by fear, uncertainty, and doubt, I
thought that things would seem less threatening after a little rational
analysis. I tried to keep an open mind, wondering if “natural selection” could
be a more appropriate analogy.
Believe it or not, I convinced myself that a Chromium monoculture could
actually be acceptable. For a minute. In this post, I’ll discuss that thought
process and explain why I’m still optimistic about the web’s future.
Parallels to Linux
The Linux kernel is the core of the GNU/Linux operating system, and it’s a
little like the Web Platform. Just like the web, it exposes various software
interfaces. Developers use those interfaces to build applications, and people
use those applications to learn, get work done, and express themselves.
That said, Linux is more like Chromium than the Web Platform in one critical
way: there is only one Linux kernel. Linux’s proven success may be a positive
signal for the Chromium-only future, thanks to another trait the two projects
All sorts of groups (both private companies and
ad-hoc communities) maintain customized configurations of
GNU/Linux with specific audiences in mind. These “distributions” afford choice
that’s meaningful to end users, and they do this on top of the kernel (i.e.
within the platform). Even though it’s not trivial to port an application
between some GNU/Linux distributions, it’s certainly less onerous than doing
the same between, say, macOS and Windows.
We’re already seeing evidence that Chromium is likewise able to support
innovation at a level which has meaning to end users.
Brave offers mutually-respectful relationships with
publishers and is built on Chromium. Vivaldi enables
advanced workflows through its non-traditional user interface and is built on
Chromium. Beaker allows you to participate in
peer-to-peer communication and is built on Chromium. As of April
Edge is built on Chromium. Maybe one day, Chromium could be made “extensible
enough” to satisfy the needs of all the web’s users… Just indirectly, by
enabling derivative browsers.
If flexibility really is a remedy for lack of diversity, then Linux’s example
might give us hope. There’s no such thing as a perfect metaphor, though. This
one hides a couple crucial differences between Chromium and the Linux platform.
Difference one: licensing
Although both Linux and Chromium are free software projects, the licenses they
use to declare this are fundamentally different.
Hey! Don’t you roll your eyes at me. Give me a chance: this might just “break
Linux is licensed under the GNU Public
License, a “copyleft”
license. This means that all derivative works must also be licensed with the
GPL. The GPL requires that projects which use the original code are also free
and open source.
Chromium is primarily licensed under the BSD
license, a “permissive”
license. That means anyone can take the source code and use it to make
proprietary projects–no need to share their creation or any improvements they
make along the way. Google itself does exactly this to produce the more
widely-known Chrome browser: it’s just Chromium with extra proprietary
This is a polarizing distinction because of its ethical considerations, but for
now, I’d like to focus on just one more objective aspect: fragmentation. A
programming platform is only useful if it’s distributed widely and
consistently. There’s fundamental tension between that need for consistency
and the rights guaranteed by free and open source software
Copyleft is a strong defense against fragmentation. Here’s what Linus Torvalds
(the creator of Linux) has to say on the
I used to be worried about fragmentation, and I used to think that it was
inevitable at some point. Everyone was looking at the history of Linux and
comparing it with UNIX. People would say that it’s going to fail because it’s
going to fragment. That’s what happened before, so why even bother?
[The Free Software Foundation] and I don’t have a loving relationship, but I
love GPL v2. I really think the license has been one of the defining factors
in the success of Linux because it enforced that you have to give back, which
meant that the fragmentation has never been something that has been viable
from a technical standpoint.
So Linux avoids fragmentation through copyleft. The web platform avoids it
through diversity of implementation. The would-be Chromium Platform would have
neither safeguard. If we go all in on Chromium, “breaking the web,” will become
a much larger threat.
Difference two: governance
The Linux kernel is maintained by a distributed group of people with no
allegiance to any particular state or corporation. This decentralization is
widely considered a strength; many people argue that it’s what allows the
project to serve a plurality of interests and dynamically respond to new
challenges. In turn, that may help explain why Linux thrives despite being
weakly guided by a standard that’s decidedly less ambitious than the
Chromium, on the other hand, is owned and operated by the US-based firm,
Google. It is still driven by profit (most concerning: profit in totalitarian
It is still subject to US law (most concerning: US intelligence
These weaknesses can’t be fixed by a custom build like Vivaldi.
In the absence of social and technical pressure to interoperate, Chromium won’t
be incentivized to make concessions for needs that oppose Google’s business
goals. Of course, a corporation is distinct from its employees, and outspoken
Googlers have publicly demonstrated this over the past few
I worry that issues of governance and user representation are too nuanced to
inspire such subversive responses (if indeed they are considered issues at
all). Chromium is
currently making a change that many feel puts Google’s interests ahead of
A corporation is an inherently single-minded entity. That makes it unfit as a
steward for any
especially one so essential as the web.
The Web Platform is strong against corporate tunnel vision thanks to the
standards process–researchers, implementers, and editors with disparate
motivations all collaborating on a single programming environment. Mozilla’s
public “standards positions”
repository is a great example
of the kind of discourse that can occur when differently-motivated
organizations attempt to cooperate. It’s hard to imagine any private company
fostering dissent at this level and in plain sight.
This would all be less concerning if governance was decoupled from Google.
Imagine if all the same people who currently work through the
W3C and WhatWG were involved in a
new Chromium Foundation. Maybe this could be enough to respect users’ rights
(though the term “monoculture” starts to feel less appropriate).
It’s possible that Google could acknowledge this and relinquish control of
Chromium to such a foundation. Then again, Chromium is open source, so Google’s
blessing isn’t strictly necessary. We can fork it whenever we want. Problem
Forking isn’t the answer
At any time, a new group could self-organize to copy the Chromium source code
and maintain their own version from then on. They couldn’t change the license
(we’re more or less stuck with it), but they could promote the kind of
resiliency and inclusiveness that we’re driving at with today’s web.
It’s a compelling possibility, and one that initially had me and my
pals thinking a
monoculture wouldn’t be so bad.
Here’s the thing, though: Forking applications is healthy. Forking platforms
is disruptive. Chromium’s current role as one application among many may
prime us to think in terms of apps. In the future we’re considering, Chromium
will be the platform. A fork wouldn’t just mean two different executables; it
would mean two different webs.
It’s tough to say if this would actually happen. The threat of a forked web
(not to mention the dim prospects of competing with a well-funded team) would
tend to demotivate those who are in a position to help. Once established, the
monoculture would have a lot of momentum. It would take a pretty big mistake to
We might never see such a divisive issue at the heart of the Chromium project.
Even in that ideal world, it’s unrealistic to expect any project (much less the
privately-held US-based one described earlier) won’t fail to satisfy some of
its constituents some of the time. These minor transgressions would be far more
common, but they wouldn’t motivate a fork. A less sensational risk, then, is a
death by one thousand cuts, and it’s the marginalized users who would feel this
What can we do about it?
There are things individuals can do to encourage a multi-browser future: Web
developers should test their work across all
Folks looking to more actively advance the cause should consider contributing
to one of the alternative engines. More volunteers could help projects like
Firefox and WebKit avoid Edge’s
For those without a technical background, the Mozilla Foundation is
particularly well-positioned to accept non-code
contributions. I’ve personally
found there to be a lack of awareness about these issues outside of the tech
industry. Talk to your friends and family about why we need choices, and
encourage them to make theirs
Despite our best efforts, the challenge of maintaining a competitive web
browser may be more than other organizations can bear. That doesn’t have to
look like the doomsday scenario laid out above, though. The biggest lesson to
take from Linux is that platform diversity is most meaningful in terms of
governance, not implementation. That’s why I feel no inconsistency in saying:
the web can’t survive a monoculture, but it might survive on a single
Google’s stake in the implementation of the web motivates a large investment in
the standards bodies. As mentioned above, in a Chromium-only world, the company
might develop the position that the committees are
need to make the web more resistant to that perspective; we need to expand and
diversify the leadership. The larger and more inclusive the leadership is, the
stronger its work will be and the more essential it will be to expanding the
platform. That would be a huge success even in a multi-browser future, so
there’s no reason not to push for it.
If you’re not already involved, you should get involved! Easier said than done,
I know. You could try fixing a bug in an open source web browser like Firefox,
and the maintainers would be delighted to help you get
That kind of work is outside the expertise of many web developers, but there
are many more ways to participate. My favorite? Testing. Not only are shared
tests expressed in the languages of web development (you won’t need to learn C,
for instance), but in many ways, unfamiliarity with browser internals is an
I work at a web development company named Bocoup, and
we’ve specialized in testing for many
years. We all
think participation is crucial, and that’s why documentation plays such a
central role in all of our work. We want to go further, though. We’re writing a
guide to help folks get involved with web standards. I’ll add a link here when
it’s published, but in the mean time:
- check out Test262 for shared tests of the
- check out the web-platform-tests
for shared tests of most other web technologies
- send me an e-mail if you’d like some more guidance
Web developers are right to fear a monoculture, but they don’t seem to
appreciate their agency in the solution. They have the power to protect the
platform if only they take the call.