[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transparency and the AMP Project #13597

Closed
ldstevens opened this issue Feb 21, 2018 · 25 comments
Closed

Transparency and the AMP Project #13597

ldstevens opened this issue Feb 21, 2018 · 25 comments

Comments

@ldstevens
Copy link
ldstevens commented Feb 21, 2018

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:

  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
Copy link
Member

Lets put this on the agenda of one of the next design reviews.

@ldstevens
Copy link
Author

What's blocking you from writing a response here?

@cramforce
Copy link
Member
cramforce commented Feb 21, 2018

Easier to transport nuance in person. Your questions transport a lot of misunderstandings about AMP, and we should clear that up first and then based on that proceed with answers.

This is our open source project and it has an established path towards resolving tough questions through our weekly public meetings.

Our process also includes private pre-meetings if would prefer that over public meetings.

@cramforce
Copy link
Member

Should we put it on the schedule for 2/28 (Americas friendly time) or 3/7 (European friendly time) or would you prefer a dedicated meeting?

@simpss
Copy link
simpss commented Feb 21, 2018

@cramforce sorry, but why does the appropriate discussion location/moment/tool keep changing?

At first it was the mailing list #13457 (comment)

Then there was a request made for a separate meta-issue #13457 (comment)

Now it's a meeting sometime in the future. Which means not everyone will be able to attend. What's wrong with clearing up these misunderstandings here, in public, with a papertrail, so that everyone can read and understand? Maybe even reconsider their position on AMP.

@ldstevens
Copy link
Author

No that's simply not good enough. Either you have answers or you don't, whether you relay them to me personally or not is neither here nor there. I'm not writing because I want an explanation in person. I'm writing as someone who cares about the web & web standards, and I'd like straightforward, considered answers to my straightforward, considered questions. You are the one driving the initiative, if this truly is an "open source project" it's your responsibility as the BDFL to explain the rationale of the decisions taken by the project which impacts everyone who works (and uses) on the internet.

I'd be very happy to share your written answers far and wide, on Twitter, HN and beyond. I'm sure that will clear up a lot of "misunderstandings" that apparently hundreds of us (if Twitter is any indication) share. I can't do that if you only respond in person.

@cramforce
Copy link
Member

@simpss These meetings have minutes. There are 3 times available for daylight time across the world. Our project our rules.

@cramforce
Copy link
Member
cramforce commented Feb 21, 2018

@ldstevens I think the relevant sentence from my talk at AMP Conf was "We aren't idiomatic about the implementation of AMP, we care about the UX invariants it provides". You will see us act in accordance to this in the future. The invitation to join our meeting is open.

@ldstevens
Copy link
Author
ldstevens commented Feb 21, 2018

I can't attend due to issues which I very much do not want to discuss. Please respond here in text.

I think the relevant sentence from my talk at AMP Conf was "We aren't idiomatic about the implementation of AMP, we care about the UX invariants it provides". You will see us act in accordance to this in the future.

I have no idea what this means.

@cramforce
Copy link
Member
cramforce commented Feb 21, 2018 via email

@ldstevens
Copy link
Author

Thank you, I appreciate it.

@ocdtrekkie
Copy link
ocdtrekkie commented Feb 22, 2018

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.)

@cramforce
Copy link
Member

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
Copy link

I really love that you are "in this to make the web win", but I hate that you don't realize that Google and the web are two different things, and this project has, in fact, made one the enemy of the other.

Now you are stating that Gmail is "building the product the way they want to", which suggests a whole new paradigm: That no matter how altruistic any goal of this allegedly open project is, Gmail is going to fork email because Gmail wants to. Between the early state of AMP4Email here (one post of one issue, apparently), and the fact that Gmail already has made a commitment to roll it out this year, that we really need to be engaging with the Gmail team, and that the Internet needs to increasingly view Gmail as a threat.

@ocdtrekkie
Copy link

Just because something operates over HTTPS and shows up in a browser does not make it part of the open web. I regularly have started to see people accidentally sharing AMP URLs instead of real web URLs and have had to request that they provide real web links to content they want to share.

@cramforce
Copy link
Member

@ldstevens
Copy link
Author

Thank you for taking the time to write a considered response; that's very helpful in understanding the motivations of the project.

On question (1), I'm still unsure who is actually responsible for the project. I'm not sure why this is difficult to answer. For example, to whom at Google exactly does the "We" in this paragraph refer?

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.

In any case, it's nice to have the rationale for AMP put out there for others to see clearly.

I'm very glad you're passionate about the web, but I'm deeply concerned that you are conflating Google's corporate interests with the web, and indeed if you parse comments like "We wanted to make the web competitive" with "We wanted to make Google competitive" it makes far more sense of the entire endeavour, and confirms my own and I suspect many others' suspicions.

To me (and I suspect many others) it appears as though you have -- with all the best intentions in the world -- destroyed the village in order to save it. It's no longer the "open" web; it's Google's. Indeed, you see them as one and the same. To compete with one walled garden you have created another and dressed it up as open source. It's open insofar as it suits Google, otherwise: "Our project, our rules". (I concur with @ocdtrekkie's comments about that statement.)

It's an extremely dangerous place to be in where you see corporate competitive interests and the common good as one and the same. Google's actions will be. by default, beyond critique because hey, it's for the common good: the open web. We're the good guys, right?

You might see yourself and your work as a benevolent force for the good of the web. Will the person (and their VP) who comes after you be so inclined? Will the person (and another VP) who comes after them?

This is the problem of corporate control of the web. Of course you can get more done if you act like your competitors. To do so you just have to give up the "open" part of the web. That is a faustian bargain if ever there was one. The web wasn't yours or Google's to fork. It's upsetting you cannot see that.

I'm not being hyperbolic when I say this is one of the most profound changes to the nature of the web in its history. I imagine it will take you a long time to come to terms with the consequences of this course of action.

I hope for the sake of the web that your obviating of the web standards process by taking corporate control at Google is worth it. I suspect it won't be.

Thanks again for the response.

@dmitriid
Copy link

I’ll pick apart just one small part of @cramforce’s answer:

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

The problems:

  • (4) and (5) are very small questions. For example, nowhere do they mention “extending scope to proprietary integrations”. That’s not what those questions ask.

  • if the discussion is “happening here”, why are so many attempts made to stop the discussion then? (beginning from “I don’t know where to have these discussions” to trying to move discussions to a dead mailing list to delaying discussions to an ineffecient “in-person discussion “ some time in the future”)

If you can’t write well-articulated non-contradictory answers to very straightforward questions (so that these answers can be shared with anyone here, or on twitter, or in media), why would anything be different in a meeting in person?

Even in this small passage above you: don’t answer the questions (and answer some totally unrelated question) and provide a yet another contradictory piece of information. All of the questions in the original issue above are: simple, straightforward, and should be known to you as the lead of the project.

@cramforce
Copy link
Member

@ldstevens I appreciate the concern. We obviously disagree on whether it was necessary to safe something to give it a chance whether not trying and hoping for the best. I think it is best to leave this discussion at this stage.

I any case, only further actions and not picking apart semantics counts. The next steps from us are refining governance rules, the increased "unbundling" of AMP into web standards and working towards not requiring AMP for the embedding properties for apps that AMP provides.

@ldstevens
Copy link
Author

Fair enough, thanks for engaging @cramforce.

@ampproject ampproject locked as resolved and limited conversation to collaborators Feb 22, 2018
@cramforce
Copy link
Member

I locked this conversation since it was linked to on the web and may attract off-topic attention–and is in a decent stage given achievable states :)

New issues can be filed here https://github.com/ampproject/amphtml/issues/new

@ampprojectbot
Copy link
Member

This issue seems to be in Pending Triage for awhile. Please triage this to an appropriate milestone.

2 similar comments
@ampprojectbot
Copy link
Member

This issue seems to be in Pending Triage for awhile. Please triage this to an appropriate milestone.

@ampprojectbot
Copy link
Member

This issue seems to be in Pending Triage for awhile. Please triage this to an appropriate milestone.

@kristoferbaxter
Copy link
Contributor

Since this conversation and discussion appears to have reached a conclusion, I am closing this issue. If there are new items to discuss in this matter, please consider opening a new issue, or bringing the topic to the AMP Advisory Committee.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants