> AMP is not a "well-lit" project.

How so? As the blog post points out, the whole thing is open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo. You might not agree with the direction the project is going, but I'd say it's about as well-lit as any open source project can be.

It seems like that until you start asking questions. Then you discover that AMP4Email is controlled by Gmail team, that you can't get a straight answer to save your life, and when they don't like the topic, they subtly threaten the Code of Conduct when no violations are occurring to indicate they are actively searching for an excuse to close down discussion.

AMP4Email has nothing to do with AMP as a validatable preloadable subset of HTML and the web packaging standard discussed in this article.

Posting some discussions in the open doesn't make it well-lit. There are many projects following this path where the real decisions are made in private meetings by people in the controlling companies. Open washing is not open source.

Indeed, while discussing AMP4Email, it seemed that, despite being a proposal in the AMP Project, all decisions for it's implementation were already made (and committed to) by the Gmail team, it had already been "reviewed" by a security team (although any such security protections are limited to Gmail's own internal protections, other implementers are on their own), and there seemed to be no opportunity for the greater email community to comment before these things were decided.

Having it up on GitHub after that doesn't really mean much. This is the same for Android and Chrome, of course.

Well, technically, it is. Open source doesn't imply governance by an independent standards body. There are just requirements for what counts as an open source license.

A project run by a "benevolent dictator for life" (like Python or Elm) is entirely compatible with open source. The same is true for a project run by a corporation (like React).

With difficult discussions being locked and limited to collaborators.

With the main answer to questions being, we can discuss this somewhere else, some-other (unknown) time in the future, usually in a more private setting. Unless pressed further.

Case in point: https://github.com/ampproject/amphtml/issues/13457#issuecomm...

Or as carmforce(Ubl) so nicely put it. "our project, our rules" but those rules keep changing, are not public and the raised issue about defining/clearing up those rules is obviously not a priority.

https://github.com/ampproject/amphtml/issues/13597#issuecomm...

https://github.com/ampproject/amphtml/issues/13603

> ... open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo.

Yeah, well... "Open-source" in the sense that they throw something over the wall from time to time. "Almost all discussion" in the sense that they use a heavily-moderated public newsgroup for some things. It's better than completely internal development, I guess, but don't kid yourself: it's a PR exercise coupled to a near-complete capture of the RFC process.

Handing over AMP would prevent the standards committee from making backward-incompatible changes to please other participants. It seems better to start fresh and have a compatibility break? Not to mention that there's little point in preserving a name that's pretty controversial.

And in the meantime, AMP would still need to be maintained.

We've seen this before in less controversial areas. For example, SPDY was proprietary and HTTP/2 is a standard that entirely replaced it.

I'm wary of AMP4Email as well, but the process of doing something quick and dirty and then standardizing the 2.0 version (under a different name) is pretty common.

Google is not replacing AMP, or promoting the standards group to replace AMP. Google is using things like web packaging with AMP, and intends to continue to do so. Their statements today, if anything, state a clear intent to continue to invest in and build on AMP.

So, while all of these other components are going to be going to standards orgs, why not let them also have AMP? (A standards org is never beholden to keep an existing standard, they can always make a new one.)

Moreover, if you read their proposed “standards”, you can see how they want to just have the same AMP treatment for other pages.

iframe promotion explicitly describes how AMP pages become “fast” (through preloading on Google Search pages)

web packaging is just a way to have signed pre-rendered pages on a CDN.

Together they give Google the power to cache/promote/“speed up” pages at will

No, together they give anyone aggregating content to do that, and they allow CDNs to serve up top level content with the original domain intact.

So much noise in these threads deliberating trying to concoct some hidden agenda around this rather than the obvious: the mobile web was a looming disaster, years of people advocating for writing fast pages failed, to the point that native apps were becoming silos to serve proprietary news content from. All of the macho-code jockeys here boasting how they can write fast pages don't seem to get that like 100 million pages out there are slow as molasses and efforts like AMP manage to fix A LOT of load issues that independent super-hackers didn't.

Independent efforts to spur people to optimize their sites and get some loading consistency failed -- multiple times. An industry wide effort is needed that deliberately pushes those, by carrot or whip, to improve the situation, giving them a cookie-cutter formula -- a subset of HTML and structure, validated for optimum parse, render, and caching, so that it is easy and consistent.

AMP was the first attempt at this. People don't like it because it's proprietary, don't like the UI choices, ok then, let's rectify that and get the W3C and browser vendors on board to have a neutral version. Let's address all of the problems and criticisms and make a public standard.

But stop pretending that if no one does anything the problem will go away. Yes, eventually it will go away, as more and more websites are replaced by native apps or embedded viewers in messaging or social apps like FB or WeChat, which become new proprietary browsers that eschew the web.

Accusing the AMP guys of ulterior motives is really wearing thin, AFAIK these guys love the web with a passion, they're trying to fend off an assault from native platforms. Most of these guys could go work on new hot-news at Google like new machine learning projects, they could have their pick of work, but have dedicated a lot of effort to make faster, a platform that a lot of people don't care about anymore and view as legacy.

How about a holding your gun-powder for once and see what comes out of this rather than setting off nukes.

If they love the web, why are they fighting us, and ignoring everything we have to say? Google is not the web, and they are on two different sides.

> Accusing the AMP guys of ulterior motives is really wearing thin, AFAIK these guys love the web with a passion, they're trying to fend off an assault from native platforms.

You are confusing individual people working on the project and the corporation that ultimately decides the entire direction of the project.

You are also assuming that all people are inherently good and will immediately leave if something morally questionable is asked of them, and that people can even realise that something is morally questionable.

In no particular order:

- Google is a corporation which is driven by two metrics: advertisement revenue and Monthly Active Users. AMP is driven to improve and increase the two.

- Every single discussion outside of implementation questions have been shut down by the AMP team. The latest round was about AMP4Email where the team has gone out of the way to derail, shut down and outright ignore any direct questions: https://github.com/ampproject/amphtml/issues/13597

- A regular AMP page rarely weighs less than 1 MB when reached from cold cache. The only reason they are fast is because: Google dominates search, and Google aggressively preloads AMP pages from its own huge geographically distributed CDN.

So when you click on an AMP page it's instant only because it's already been preloaded. Meanwhile Google's own page speed tools say that AMP are not fast. And to add insult to injury, AMP is not even valid HTML5. https://ferdychristant.com/amp-the-missing-controversy-3b424...

Of course independent superhackers can't do anything because they don't have Google-level infrastructure. Because Google makes AMP appear to be faster than even http://motherfuckingwebsite.com which is just text.

Just a quote: "The performance benefit of prerendering is enormous, so enormous that prerendered pages can load hundreds of KB of JavaScript and still display “instantly” by the time the user taps on a link." https://redfin.engineering/how-to-fix-googles-amp-without-sl...

- Taking the previous bullet point further: AMP is a hack that has nothing to do with actual website performance or "slimming down" of websites. The only reason AMP exists is because of Facebook Instant Articles. It's not because of walled gardens. It's not because of "open web". It's just the desire to not be outdone by competition and the strive for ad revenue and MAUs.

It's a way to promote a few select websites and penalise every other website, even those who strictly adhere to Google's own performance guidelines: https://developers.google.com/speed/docs/insights/rules

Any and all concerns about AMP where entirely dismissed by Google (and AMP team) until a significant portion of publishers have started voicing their concerns and some have even started pulling out of AMP.

Why publishers you ask? AMP is primarily targeted at publishers and publishers are the only ones even allowed to somewhat participate in AMP. To quote "Standardizing lessons": "constant adjustment to publisher and user feedback." which is half truth at best. The only working group on AMP is amp-news-publishers (https://github.com/ampproject/amphtml/blob/master/contributi...), and any "user feedback" that is allowed is "intents to implement" and comments on how a feature is implemented. All other discussions are shut down.

- The new standards proposed by Google only seek to cement the status quo.

Web Packages is a way to store signed prerendered and preloaded pages on a CDN

iframe promotion explicitly describes how and why AMP pages are "fast": they are preloaded in invisible iframes during search. The only goal of this proposal is to help google make those frames visible and switch the browser URL when the iframe is presented to the user.

This does not actually solve any performance issues. You can still develop your 8 MB site. However, it will load instantly just because Google has preloaded it while you were searching.

Do not be fooled by the use cases. The primary benefactor of aggressive preloading and caching is Google, who already has the entire infrastructure in place, and dominates search. No mater how much you try and adhere to all the performance guidelines, you will never beat a pre-rendered and preloaded page stored on Google's CDN.

- And yes. Ultimately the AMP team in its entirety fails to accept or acknowledge any shortcoming of AMP. Even the "Standardizing lessons" spew the same easily falsifiable myths around AMP heavily sugar-coated in self-aggrandizement.

On top of that, no matter how many times they say that the process is well-lit (they say it three times in the article), the process is entirely opaque, developed by Google, for Google, and in Google's products and then presented post-factum as a "standards proposal".