When AMP launched years ago, it was intending to speed the mobile web by restricting the use of certain page elements. Today, though, between workarounds and new developments, it can support dynamic content and even entire websites.
Still, the misconception remains that it’s only effective for static content. And this isn’t the only misconception. Today, we set the record straight about key components of the AMP format and how they’ve evolved.
How the AMP format has changed
1. AMP contributors are growing in number and variety
AMP started as a small, Google-backed project with only two contributors. By 2018, 700 people had contributed to the project. A year later, that number had increased to 1,000 contributors from other sites like Twitter, Yahoo, eBay, and Pinterest. Only 22% of the contributors were from Google:
AMP format updates contributors
2. Google has given up control
Since Google launched AMP, it’s been open-source, with major decisions about its future left to Matt Ubl, AMP project lead.
However, projects like AMP impact the entire web: businesses, people, jobs, information, and more. And that’s why Ubl and his team planned to relinquish control to a governing body representative of the community that helped to build it.
Recently, the team followed through with that plan, by putting a “consensus-seeking governance model” in place. Says Ubl:
When choosing a governance model (a system that describes how decisions are made) for AMP, we initially focused on agility. AMP has always been powered by the voices and feedback of the developers and organizations that use it. However, governance was centered around the tech lead (which is me, the author of this post), who ultimately decided what got executed and how.
While this works great for smaller projects, we’ve found that it doesn’t scale to the size of the AMP Project today. Instead, we want to move to a model that explicitly gives a voice to all constituents of the community, including those who cannot contribute code themselves, such as end-users. The change we are proposing is based on months of research, through which we’ve decided to follow the lead of the Node.js project and move to a consensus-seeking governance model.
Coming to this decision involved consideration of the goals they wanted to achieve:
They wanted to encourage a variety of people to dictate the future of AMP: deciding features, bugs, contributions, etc. And that includes people who don’t contribute code, but are affected by AMP.
They wanted to clarify how an individual and a company can contribute to AMP. This extends beyond approving code to activities like setting product and tech road maps.