Transparency and the AMP Project

Attempts to get answers to simple and straightforward questions regarding the AMP Project have been met with farcical responses so far. (“Where is the place to have this discussion?” “I don’t know”.)

I’d like to restate the questions here in the forum AMP Project prefers and uses (and not in the mothballed email list) in the hope of getting meaningful answers from people with real authority and insight into the AMP process. My questions are as follows:

1. Who actually has authority over the AMP project (not just the technical implementation)? E.g., who decides to proceed with AMP Stories, and AMP Email? Who decided to take the project beyond “Accelerated Mobile Pages”?

2. What discussions internally were had regarding AMP Email, and the implications it has for email as a fundamental part of the internet? What feedback (if any) was solicited from users, developers, and email service providers? What other options were considered?

3. What discussions internally were had regarding AMP Stories? What feedback (if any) was solicited from users, developers, and other search providers? What other options were considered?

4. How serious is the AMP Email initiative? AMP “Motivation” doc makes it sound like a fundamental change to email; @cramforce makes it sound like a low-risk experiment (“it seems like a good idea to try this”).

5. @cramforce says “I absolutely agree that there should be a wider discussion as to whether it is a good idea in email.”. What attempts have been made to start this discussion? If the discussion is important, why was this announced as “intent to implement”? If you’re not 100% convinced this is good idea for email, why are you doing it?

6. If there is a “well lit” process for feedback about the idea itself, what is it?

7. Google’s blessing of AMP implementations makes them defacto standards (and certainly not just-another-JS-framework) where you’re asking us to implement tags which are in effect <google-img>. Why have you not set up a W3C group (or participated in existing ones as per @hallmedia’s comment) to facilitate feedback and build consensus to implement the best version of this with the broadest support? I can imagine “HTML Lite” as a true standards initiative would have found much broader support than the suspicion and resistance now (quite rightly) being expressed by those familiar with web standards.

8. There is obviously very significant concern about the AMP project in the web community and beyond. What steps will you be taking to address this criticism? Will AMP Project Lead David Besbris respond to any of these concerns or engage with the community in any way? If not, why not? Examples:

• https://www.socpub.com/articles/chris-graham-why-google-amp-threat-open-web-15847
• https://ethanmarcotte.com/wrote/amplified/
• https://timkadlec.com/remembers/2018-02-14-the-two-faces-of-amp/
• https://adactio.com/journal/13035

1. If AMP succeeds in email (and on the web as it has done), what does this mean for Google’s competitive interests? What does it mean for Google’s control of this new format, given Google’s vested interests in AMP as a response to competitors (e.g. AMP Stories)?

2. Finally, why can’t the AMP project exist independent of Google’s corporate management?

Thank you.

[cramforce]

I first want to acknowledge that we are learning how to run such a big open source project and so many things are being figured out. E.g. we are currently rewriting our Governance guidelines to answer many of your questions more directly.

Having said that, I think amp-stories is a great example of our process. The Intent to implement (ITI) was send here in September and it has since been worked on with a set of publishers producing content to test out what the team working on code was producing. In that feedback loop between publishers and devs the product evolved. You can find the traces in dozens of issues in this project. It was “announced” last week. But only to people who weren’t paying attention to this project.

In AMP for email we took a different path (post ITI only on public announcement) but we are working with a product team (GMail) that is building a product they way they want to and we respect that. The ITI was posted last week and has not yet been approved (so is in active discussion). The scope of the ITI is not whether GMail launches the product, just whether the AMP project accepts the responsibility of maintaining the E-mail specific fork of AMP.

For your (4) and (5) questions: The discussion is happening here with the scope of AMP. We cannot and will not extend the scope of this GitHub project to proprietary integrations of AMP. That may be frustrating but it is the way it works and a very common setup for open source projects. Similar with (6): You can argue here that AMP for email is a bad idea. The outcome would be if you convince us that we would deny the ITI and the main AMP repo would not accommodate the project. I can’t answer the questions for the various integrations of AMP since (by design) AMP doesn’t mandate how partners like Baidu, Twitter, Microsoft and Google use AMP.

I’d like to avoid taking email out of the equation for the other points. Both because I’m not an email expert and the answers aren’t the same as for the web in any case.

First I’d like to acknowledge that we are learning how to communicate about AMP. I don’t think answering individual posts at this time makes sense. Although I have engaged in plenty of debate about them on the orange website and Twitter.

We were worried about the web not existing anymore due to native apps and walled gardens killing it off. We wanted to make the web competitive. We saw a sense of urgency and thus we decided to build on the extensible web to build AMP instead of waiting for standard and browsers and websites to catch up. I stand behind this process. I’m a practical guy.

Now, and this should answer your question (7) we are increasingly pivoting towards taking the learnings of AMP and bringing them into web standards. The Feature Policy work is the primary focus of this effort and you will see significant increases in velocity in that over the coming months.

I said above and in my talk at AMP Conf that we aren’t idiomatic about AMP’s implementation. With JS in AMP the “thingness” of AMP. But that is just the first step. Our goal was always to create a well lit path towards a web that can compete with native apps. We are hoping and working on making that path broader and not requiring people to use AMP. As said above: Work is under way and will accelerate.

To (10): As said above: We are working on revising the project governance to make it clearer how decisions are made beyond me being BDFL.

I will moderate this thread according to our code of conduct. In general, my statement from above remains that there is an open invitation to join our weekly design reviews (but put your topic on the agenda; and adhere to the COC).

I don’t think that the discussion here will lead to everybody being happy, but I think my post give a good perspective as to the future plans. We are in this to make the web win. We might disagree on the means, but we can agree on the outcome we are all aiming for.

[ocdtrekkie]

The fundamental issue that I see is that Google is using monopolies to push AMP, first Google Search, and soon Gmail, which by the nature of those monopolies, makes it a standard. (Sometimes Googlers do not seem to speak or act like they are aware they are operating a monopoly, despite Eric Schmidt himself admitting it is the case.) If it’s a standard, either Google is controlling it, and hence, it’s a proprietary standard, or it’s community-driven, and hence, an open one.

The problem is that Google is calling it an open standard while operating it like a proprietary one. “Our project our rules” is not something that should ever be uttered by someone hoping for the community to support it, and Google is already losing both customers and engineering talent over AMP. (In addition to quite a few industry members committing to leave Gmail if AMP4Email goes forward, at least one engineer has cited AMP as a “nontrivial” factor in refusing an employment offer with Google.)