Skip to content

Instantly share code, notes, and snippets.

Last active Jun 27, 2021
What would you like to do?

AMP Project

Project Applicant

Tobie Langel (


AMP is an open source Web component framework that provides a well lit path for Web performance and user experience best practices. Additionally, it allows platforms (such as search engines or social networks) to provide Privacy-Preserving Prerendering (PPP). PPP allows web pages to be displayed instantly without leaking the user’s interest for that page prior to them navigating to it.

Statement of alignment with OpenJS Foundation charter and mission

AMP is a large, multi-stakeholder open source project driven by the desire to improve the experience of users on the Web, and in particular, on mobile devices. AMP’s vision of a strong, user-first open web forever, is guided by a set of design principles which inform its development.

The AMP runtime ships in many billions of pages on +30 million domains. Both Google Search and Bing run their own AMP Cache, and countless other products and companies integrate with AMP in various ways. To deal with such broad reach and end-user impact, and to cater to such a diverse group of constituencies, AMP has moved to an open governance model last year, inspired by the Node.js and JS foundations, and by standard bodies. Moving to the OpenJS foundation would allow AMP to further this focus on transparency and openness.

Additionally, joining the OpenJS foundation is the occasion for AMP to demonstrate that it is much more than a limited subset of HTML for news publishers. AMP is also both a solid declarative alternative to other JavaScript frameworks and a battle-tested set of high-quality Web components, soon available independently of the AMP runtime and able to coexist with other web components and frameworks on the same page.

List of all repos that are part of the project

This application concerns all of the projects hosted by the ampproject GitHub org. This includes the AMP web component framework itself, the worker-dom project, the source of the website and related documentation, numerous dev tools and infrastructure-related repositories, and the repositories used by the various working groups and committees for their day-to-day operations. See below for a complete list of repositories with description, licensing information, and links to the issue trackers and Codes of Conduct.

The intent is for all Codes of Conduct to link to the same, org-wide document. We noticed during this application process that a few repositories were missing one. We plan to update them to point directly to the Code of Conduct of the OpenJS Foundation during incubation.

With a few exceptions, all code is licensed under Apache 2.0; documentation is licensed under Apache 2.0 for the code and the content(!) and CC BY-NC 4.0 for the visual assets; and governance-related material is licensed under CC BY-NC 4.0.

Governance Structure

Is there a leadership team?

Yes. AMP has a Technical Steering Committee (TSC) which is responsible for setting the technical and product direction based on the project guidelines.

The TSC delegates certain responsibilities to dedicated working groups (WG).

This governance structure was heavily inspired from Node.js and the JS Foundation.

Additionally, AMP has an Advisory Committee (AC), whose role is to give advice and perspective to the TSC and to WGs. Note that its advice is non-binding. Membership of the AC is composed of representatives from major AMP constituencies (publishers, CDNs, browser vendors, open web advocates, e-commerce, platforms, etc.), and includes a number of AMP critics that are AMP Letter signatories. It is the AC's duty to ensure it is as representative and diverse as possible.

Who are the members of the leadership team?

TSC members:

AC members:

How are members of the leadership team nominated?

Both the TSC and AC were seeded by:

  • reaching out to project contributors,
  • reaching out to partners which had implemented AMP,
  • reaching out to attendees of the AMP Contributor Summit,
  • opening up applications to members of the public when the governance plan was announced (but before it was implemented),
  • working with an external consultant to identify relevant candidates, and
  • reaching out to open critiques of the project (notably AMP Letter signatories).

Once the AC and TSC were bootstrapped, responsibility fell on committees themselves to organize their own election system.

The AC just successfully ran its first election and elected six new members. Nominations were open to the public and members were elected through a consensus-driven process.

How are individuals outside of leadership given commit access?

AMP calls contributors with commit access, Reviewers. The process to become a Reviewer is described in

Additionally, AMP has a Chromium-inspired Owners system which gives certain contributors authority over parts of the codebase. Owners may also be Reviewers and thus have commit rights, but this is generally not the case.

Finally, there is the Approvers Working Group, which is responsible for approving changes that have a significant impact on AMP's behavior or contain significant new features as described in the feature and bug fix process.

It is worth noting that despite 78% of contributors not being Google employees, Reviewers and Approvers are all current or past Google employees.

There are a number of reasons for this:

  • There wasn’t a clear path to becoming a reviewer until recently.
  • The current governance model is less than a year old. Previously, the project was completely controlled by Google and thus less attractive to non-Google employees.
  • Most contributions which do not come from Google employees are either centered on specific components or are drive-bys.
  • AMP is an already mature project with a complex architecture, mastering it sufficiently to be able to fulfil the role of a Reviewer takes time.
  • Because AMP is evergreen, it is deployed every week to about 10 billion Web pages. This creates additional security requirements as to who has access to the codebase, even if there are additional downstream mitigation strategies in place.

We are well aware that this is AMP's greatest challenge to become an Impact Stage project, and welcome input from the CPC during the incubation to help address this issue.

Please share links to all existing documentation e.g. /

Specific projects have their own contributing guidelines. For example, for amphtml itself:

Additional both the TSC and AC have a published working mode which sets expectations as to how both committees operate.

Desired Initial Project Phase

As mentioned, AMP seeks to become an Impact project. However, we understand that AMP may not yet meet all the requirements to do so. We look forward to working with the foundation, during incubation, to determine the best path forward.

Official Communication Channels

  • AMP has its own Slack workspace.
  • The TSC, the AC, and each working groups use a dedicated repository (and in particular its issue tracker) for day to day operations and broader conversations, similar to how the OpenJSF CPC uses GitHub.
  • Additionally, the AC and WGs have dedicated Slack channels which are documented here: AC, WGs.
  • There is a public mailing list/google group with light traffic (!forum/amphtml-discuss).
  • A number of private mailing lists exist to coordinate logistics (e.g. around face to face meetings, events, etc.), or when otherwise required (e.g. to protect privacy, for security reasons, etc.)
  • An email address to enquire about or report Code of Conduct violations.
  • There are public design reviews every week with a rolling schedule to accommodate all time zones.
  • AMP accepts responsible security disclosures through the Google Application Security program. The goal here would be to transition to an OpenJSF solution if such a solution existed (tracking this in CPC issues #326) or to adopt an external solution otherwise (e.g. HackerOne or similar).

Project Website

Social Media Accounts

Existing Financial Sponsorship

Currently, AMP is mostly funded by Google, although other companies have started contributing to the funding, notably by hosting meetings and covering catering costs.

Funding currently supports infrastructure costs (e.g. Travis,, Saucelabs), AMP Conf, AMP Contributor Summit, the AMP Roadshow, marketing efforts, a diversity fund to attend events, travel expenses for AC and TSC members who are not backed by corporations, an OpenCollective to help fund open source dependencies on which AMP relies.

The Google AMP team intends to continue funding the project at this level and plans to work closely with the OpenJS Foundation to enable project directed funding (see notably CPC issue #90).

Infrastructure Needs or Requests


AMP’s current tooling includes a small number of GitHub bots, CI tools, and services for the approximate cost of $100K per year.

Google currently supports these costs and intends to continue doing so, directly, at first, and then through directed funding once this becomes possible.

A CDN for the AMP runtime

Currently the AMP runtime is hosted on the same infrastructure as the Google AMP Cache.

The end goal is to separate the AMP runtime from the Google AMP Cache. Ideally, hosting and deployment of the AMP runtime to the CDN would fall under the purview of the OpenJS Foundation, much like the foundation is already handling the jQuery CDN today. Google would be willing to support hosting costs if necessary.

The Google AMP Cache would continue to be hosted and operated independent of the OpenJS Foundation, by Google, much like Microsoft operates its own AMP cache today.

Untangling the runtime from the cache is a complex endeavor requiring significant investments of time and effort which would be planned and implemented in collaboration with the foundation during and after incubation.


We’ve outlined our two main concerns above which are worth repeating here:

  • the lack of contributors with commit rights who aren’t past or current Google employees, and
  • the current entanglement between the CDN hosting the runtime (which should be under the purview of the foundation) and the Google AMP Cache (which should continue to be operated by Google, much like the Bing cache is operated by Microsoft).

We plan to address both issues in collaboration with the foundation.

It is also important to mention that the architecture of the AMP project, which enables privacy preserving pre-rendering, has undesirable side effects that have been called out by AMP critics, notably in the AMP Letter:

  • Instead of displaying the URL of their own origin, cached AMP pages appear as if they were hosted by Google (or by Bing), which is obviously less than ideal. This is being addressed by a combination of emerging W3C and IETF standards (namely Web Packaging and Signed HTTP Exchanges), which, to be fully transparent, haven’t yet obtained the full support of all browser vendors.
  • Because, for now, only AMP pages meet the privacy requirements to allow them to be displayed in the Google Search Top Stories Carousel, AMP pages about news topics have exclusive surfaces in Google. Google's team is working on removing the technical limitations that make the exclusivity necessary as outlined in this blog post and most recently updated on the AMP Blog: part 1, part 2, and part 3.

We’re happy to provide added context if necessary.

Finally, we are very excited about the possibility of joining the OpenJS Foundation and look forward to further AMP’s involvement in the JavaScript community, notably by:

  • releasing software as independent library whenever possible, consider for example worker-dom, which although it was designed for the <amp-script> component is a standalone library,
  • allowing AMP Web components to be used standalone and in collaboration with other JavaScript frameworks, without a dependency on the AMP runtime,
  • driving diversity and inclusion, notably through diversity funds for events and forward looking governance solutions such as the advisory committee,
  • pursuing open source sustainability by funding AMP’s open source dependencies through OpenCollective.



Dev tools




  • design-docs — Design docs contributed to AMP.

  • meta — Information about the AMP open source project.

  • meta-ac — The AMP Advisory Committee

  • meta-tsc — The AMP Technical Steering Committee

  • wg-access-subscriptions — Working Group responsible for user specific controlled access to AMP content (amp-subscriptions, amp-access and related extensions) Facilitator: @jpettitt Slack: #wg-access-subs

  • wg-ads — Working Group responsible for ads features and integrations in AMP. Facilitator: @lannka

  • wg-amp4email — Working Group responsible for the AMP4Email project. Facilitator: @choumx

  • wg-analytics — Working Group responsible for analytics features and integrations in AMP. Facilitator: @lannka

  • wg-approvers — Working Group responsible for approving changes that have a significant impact on AMP's behavior or significant new features as described in the feature and bug fix process. Facilitator: @dvoytenko

  • wg-caching — Working Group responsible for AMP's validator and features related to AMP caches. Facilitator: @Gregable

  • wg-codeofconduct — Working Group responsible for enforcing AMP's Code of Conduct. (The Technical Steering Committee delegates its responsibility for enforcement of the Code of Conduct to this Working Group.) Facilitator: @nainar

  • wg-infra — Working Group responsible for AMP's infrastructure, including building, testing and release. Facilitator: @rsimha

  • wg-outreach — Working Group responsible for helping developers who use AMP remain productive and keeping the AMP community healthy. This includes maintaining and enhancing AMP's developer-facing sites and documentation, maintaining communication channels, organizing community events, etc. Facilitator: @pbakaus

  • wg-performance — Monitoring and improving AMP's load and runtime performance for compliant documents. Facilitator: @kristoferbaxter

  • wg-runtime — Working Group responsible for AMP's core runtime, such as layout/rendering and data binding. Facilitator: @jridgewell

  • wg-stories — Working Group responsible for implementing and improving AMP's story format (amp-story). Facilitator: @newmuis

  • wg-ui-and-a11y — Working Group responsible for AMP's visual components & interactions and AMP's overall accessibility and user experience (including published guidelines for AMP UX). The UI WG also has overall responsibility for ensuring AMP is accessible, though each WG is responsible for ensuring accessibility within their areas of responsibility. Facilitator: @nainar

  • wg-viewers — Working Group responsible for ensuring support for AMP viewers and for the amp-viewer project. Facilitator: @ericfs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment