Tobie Langel (tobie@unlockopen.com)
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.
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.
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 amp.dev 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 projects.md 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.
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.
- Chris Papazian, Pinterest - @cpapazian
- David Strauss, Pantheon - @davidstrauss
- Dima Voytenko, Google - @dvoytenko
- Malte Ubl, Google - @cramforce
- Paul Armstrong, Twitter - @paularmstrong
- Rudy Galfi, Google - @rudygalfi
- Saulo Santos, Microsoft - @ssantosms
- Ali Ghassemi - @aghassemi
- Charles Vazac - @cvazac
- David Merrell - @dymerrell
- Elisa Budelli - @elibud
- Graham Loh - @grahamle
- Guilherme Moser de Souza - @mobtec
- Jervay Singh - @jervay
- Joe Alicata - @wirelessjoe
- Kenji Baheux - @kenjibaheux
- Levi Durfee - @levidurfee
- Léonie Watson - @LJWatson
- Maggie Wettergreen - @mjwettergreen
- Melanie Sumner - @melsumner
- Melissa DePuydt - @msteffan
- Pablo Delgado - @pdelgadorodriguez
- Senthil Padmanabhan - @senthilp
- Sumantro Das - @sumodas
- Ted Shuter - @TedShuter
- Terence Eden - @edent
- Tim Jones - @tones
- Tobie Langel - @tobie
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.
AMP calls contributors with commit access, Reviewers. The process to become a Reviewer is described in contributing-code.md.
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.
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.
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.
- 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 (https://groups.google.com/forum/#!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).
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, Percy.io, 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).
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.
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.