POSTS
The Web Can't Survive a Monoculture
Assumed audience: web developers and web platform implementersMany 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 another. 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 market. It inspires them to use the term “monoculture” as a metaphor for a future world where Chromium (the project that powers Chrome) is the only browser.
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 share: flexibility.
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 2019, Microsoft 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 the web.”
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 features.
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 licensing. Copyleft is a strong defense against fragmentation. Here’s what Linus Torvalds (the creator of Linux) has to say on the topic:
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 web’s.
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 countries). It is still subject to US law (most concerning: US intelligence agencies). 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 years. 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 users’.. A corporation is an inherently single-minded entity. That makes it unfit as a steward for any platform, 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 solved, right?
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 inspire competition.
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 most strongly.
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 browsers. 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 fate. 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 thoughtfully.
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 browser engine.
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 dispensable. We 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 started. 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 advantage!
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.
Update 2020-05-30 Here it is: the Web Platform Contribution Guide.
Also:
- check out Test262 for shared tests of the JavaScript programming language
- 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.