Ever since Google’s instant article format, Accelerated Mobile Pages (AMP) launched in 2016, the company has stridently pushed back on the idea that it was a Google-specific project. Instead, executives said that it was a part of the open web, with open-source contributions both from Google employees and non-Googlers, and that it is utilized not just by Google search, but also Bing, eBay, and others.
That message didn’t really resonate with the web community, which has largely seen it as (at best) a Google project and (at worst) an attempt to co-opt the entire web with a Google-controlled format.
Now, Google is announcing that it intends to give up some control of how the code behind AMP is managed. It plans to move the AMP Project to a “new governance model,” which is to say that decisions about the code will be made by a committee that includes non-Googlers. Until now, final decisions about AMP’s code have been made by Malte Ubl, the tech lead for the AMP Project at Google.
A model with a single person in charge is not actually all that rare in open source. That person is often cheekily referred to as the BDFL, or “benevolent dictator for life.” Ubl’s been that person for AMP, but, he writes, “we’ve found that it doesn’t scale to the size of the AMP Project today. Instead, we want to move to a model that explicitly gives a voice to all constituents of the community, including those who cannot contribute code themselves, such as end-users.”
A new governance model for an open-source project doesn’t sound particularly interesting on the face of it, but it’s a bigger deal than it seems because the project we’re talking about has taken over a sizable portion of the mobile web. Many news sites (including this one) serve AMP and have seen AMP grow to constitute a significant portion of their overall traffic.
From a technical perspective, the easiest way to set up an AMP system is to cede just a little control of your pages to Google by allowing Google’s caching servers to send your content to users. That’s not a requirement of AMP, of course, but it is how most websites tend to do it. What is a requirement for getting your AMP to show up in Google search is adhering to the standards for the format — standards that, so far, have been decided within Google.
That’s why the new plan is important: it takes a large and still-growing part of the mobile web and puts the decisions that determine its future into the hands of a group instead of a single company. The plan is to create a Technical Steering Committee, an Advisory Committee, and also Working Groups. Ubl says the structure was inspired by how the Node.js project is run. Ubl also says that the group is “exploring moving AMP to a foundation in the future.”
Google has already signed up non-Google people for the Advisory Committee, which will include representatives from The Washington Post, AliExpress, eBay, Cloudflare, and Automattic (which makes WordPress). Ubl says that it will also include “advocates for an open web,” including “Léonie Watson of The Paciello Group, Nicole Sullivan of Google / Chrome, and Terence Eden.”
Of course, as anybody who’s taken part in a committee knows, it’s neither a fun solution nor a guarantee that a single company or person won’t dominate it. But it’s a step in the right direction, and Google is encouraging people to comment on the plan at the AMP Contributor Summit on September 25th.
Google has also been trying to open AMP up via an entirely different track: by helping create new web standards with similar benefits that are separate from the AMP Project itself. As it announced in March, Google hopes that the larger committees that decide on web standards — the W3C and WICG groups within it — will adopt new technologies that are inspired by AMP. That process is slow and likely to always be slow, however; the AMP Project’s tracking page for the various standards it’s proposed hasn’t changed since March. But work on stuff like Web Package does appear to be ongoing. (There are plenty of other associated projects, too.)
I asked Ubl what the relationship between the two tracks is, and he says that “these two things are in many ways independent, but they do, of course, happen in the same wider context and are motivated by the same strategy.”
As with all things web standards, progress on both tracks is likely to be a little slower than everybody would like. But if you’re willing to give Google the benefit of the doubt (and for many, that may be a big “if”), then you could say that today’s news shows that the “strategy” in both cases is laudable. Namely: making the mobile web suck a little bit less without resorting to a centralized gatekeeper.