Let’s learn about standardization from Microsoft’s move to Chromium
Tags: architecture, webdev, chromium
Published: 2020-08-18 05:24:54

---
title: Let’s learn about standardization from Microsoft’s move to Chromium
published: true
date: 2019-11-04 07:30:00 UTC
tags: SoftwareArchitecture,WebDevelopment,Chromium
canonical_url: https://jehrhardt.blog/let-s-learn-about-standardization-from-microsoft-s-move-to-chromium/
---

In software development we often copy concepts from other industries like machine construction before we develop our own better fitting solutions. One of these concepts is standardization through standardized protocols. In the best case there is some consortium taking care of these standards. But there is an alternative to standard protocols: de-facto standard open source software.

## A real world case: Chromium’s rise

In the last couple of years Google Chrome has become the most popular browser in the world. Particularly on mobile devices this happened through the rise of Google’s Android operating system, which has become the dominant mobile platform in most countries. Additionally the Electron desktop framework and several other browsers are based as well on the [Chromium open source project](https://www.chromium.org) that backs Chrome. Also node.js uses the V8 JavaScript engine from Chromium under the hood. Which leads to a very high market share of Chromium in the HTML, CSS and JavaScript world.

In [one of the latest episodes](https://rework.fm/open-source-and-power-with-matt-mullenweg/) of the Rework podcast David Heinemeier Hansson (founder of Ruby on Rails) and Matt Mullenweg (founder of WordPress) discussed the topic of open source software and power. They also touch [Microsoft’s move to the Chromium](https://blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration/) browser engine for their Edge browser last year. While many web developers were happy about this. Others were sad about the potential risks for the open web. They have been reminded of an age where Microsoft’s Internet Explorer dominated the browser market, which led to a long period of stagnation in browser development. And with Microsoft’s switch Chromium’s dominance in the market becomes similar strong.

In the podcast David is one of those, who are sad about the now lower diversity in browser engines on the market. While Matt is happy about the lower differences between browsers. The risks David sees are stagnation as in Internet Explorer age and the decreasing importance of the [W3C](https://www.w3.org) in standardizing HTML, CSS and JavaScript. The latter might happen because of web developers starting to see Chromium as the relevant internet. On the other hand Matt points to the fact that Chromium is different from Internet Explorer because it is open source. And that changes the game for him.

## The problem with standardization documents

The discussion between David and Matt points us to the interesting problem of the best way for creating technical standards across the industry. The W3C approach is based on standardizing protocols (e. g. HTML, CSS and JavsScript) through documents. Then different browser vendors implement these protocols. This works great in the following cases:

- Create alignment across multiple existing vendors.
- No single vendor dominates the market.
- Some implementations are proprietary.

But this kind of standardization comes at a cost:

- The process can be slow.
- Sometimes it becomes victim to politics.
- Written documents always leave room for interpretation. This can even lead to incompatible implementations.
- Standards can become more restrictive than necessary.
- Sometimes standards are driven by theory not practice.

## De-facto standard open source software

An alternative approach is open source software that becomes a de-facto standard in the industry. This typically happens by taking over the complete market and becoming a monopoly. But as Matt points out in the podcast, if the software is open source, this monopoly does not hurt. People and other companies can fork the project, they can try out new ideas and maybe the good ones make it back to the upstream project. But they make it back as reusable software. Not as a document that leaves room for interpretation. Forks can even replace the original project as the de-facto standard. So the monopoly is not really a monopoly 😉.

A good example for an open source de-facto standard is the Linux operating system. There is nothing like a Linux specification that is implemented by multiple Linux vendors. Instead all Linux vendors are using the same open source Linux code in their products. And many of them contribute back to the project.

Something similar could happen to HTML, CSS and JavaScript. All relevant browsers and runtimes could be based on Chromium and the future of these technologies might be defined by Chromium and not the W3C. I absolutely understand why many web developers like this direction. In software development we have become used to this pragmatic way of standardization.

## Apply it to your company

Software development sometimes requires internal standardization as well. When you are building a microservices architecture for example, the goal is autonomy of teams. But the price for it is to have standardized ways to solve common tasks like deployments or observability.

I have seen both standardization approaches being applied internally.

Standardization documents sound like the most obvious approach. Companies create a team of software architects to define standards. And the group sits down in a small round to define plenty of rules. Everything is carefully written down and discussed at least three times. And in the end everyone is wondering why nobody reads all the documents and nobody is aware of all the rules.

The problem here is that internal standardization usually makes most sense when automation is the goal. Following the de-facto standardization approach is simple. If you want to standardize deployments, then create an automated deployment infrastructure first. The infrastructure will implicitly define a standard, without all the discussion and politics. And when the process is open, everyone will be able to contribute and improve the solution.

Of course de-facto standards are usually the result of one solution winning against all competitors. For internal standardization such competition can be an evaluation process that helps to find the best fitting solution, which will then become the standard in the company. But I highly recommend to document the decision and its context with an [ADR](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).

## And you?

What are your experiences with standardization in companies or across the industry? Do you have a different opinion on standardization documents? Leave me a comment below 👋🏻.