Transparency and the AMP Project

Pretty dismal communication from @cramforce.

Seemed like a political response to the questions raised, and I don't think "making the web competitive to native apps and walled gardens" is the real goal (err, Google happens to control the world's biggest mobile platform and it's app ecosystem)

I think Google have just realised that if they create an obviously closed platform, a la Apple, everyone will resist it and it will fail or be supplanted by a more open one.

What gave Android power? The thousands of other companies that jumped aboard. And Google won all the spoils. Billions of devices running Android, with Google search by default.

Make it "open", but control it. Win.

One thing is what some technical lead thinks about the project. Another thing is its real purpose, its strategical value.

I've been engaging with AMP Tech Lead @cramforce about the serious concerns many have about the nature of the AMP project.

His response is perhaps the most direct explanation of the motivations behind the AMP I've seen to date. You can read the thread, or read his post here:

===

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.