A few months ago Google announced a new open source project called Accelerated Mobile Pages (AMP) that promised to “dramatically improve the performance of the mobile Web,” and now Google features AMP content at the top of mobile search results. As the amount of AMP content continues to grow, more questions are being asked about whether or not AMP benefits the open web, and whether AMP is a closed silo.

The AMP project has occupied my mind quite a bit lately: not only am I one of the developers of the new AMP module for Drupal, I am also an outspoken free software advocate and host of Hacking Culture, which features in-depth interviews with open source and free software advocates. I have had to decide whether or not I think AMP represents a positive change for the open web. Although I think it is still rather early to assess the full impact of AMP, I have concluded that it is a move in the right direction.

One fact that cannot be disputed is that AMP content loads quickly. AMP content loads an average of four times faster and uses 10 times less data than non-AMP pages. We all desire to see statistics like that when loading content on our devices.

We should also admit that this is no longer just “Google’s Accelerated Mobile Pages project.” Google created AMP, but the company has convinced many other publishers and platforms to get involved with the project. Current partners include the likes of LinkedIn, Medium, Brightcove, Vine, Pinterest, The New York Times, Vox Media, The Washington Post, The Guardian, BBC, and The Wall Street Journal.

Unlike other solutions to the problem of a slow mobile web, AMP is an open source project. The code for the project resides on GitHub. It’s an active community with lots of open issues and thus far includes contributions from well over 100 people. The project provides clear information about governance, as well as a code of conduct (based on the Hoodie Community Code) that describes the project as a “positive, growing project and community” that aims to provide a “safe environment for everyone.”

More than just open source, the project seeks to be an open standard. Whereas previous attempts to build websites for mobile devices (“m.” sites, anyone?) had similar goals, they did not provide the kind of strict rules that AMP dictates. Anyone can implement the AMP standard, and it is already being used by Pinterest, Twitter, Google, and others. Because it is a standard, AMP HTML could potentially work in any browser or app, making it a much more “open” solution than any other proposed plans, especially those suggested by Apple and Facebook.

While AMP focuses primarily on maximizing speed, it provides publishers with flexibility that other proprietary solutions do not. Unlike solutions such as RSS or Apple News, where 3rd parties (e.g. designers at Facebook or Apple) control the appearance of content, publishers dictate the look and feel of their AMP content and those publishers have complete control over the elements on the page. In Poynter’s analysis of AMP, it is the publisher that is “in control of their product, they’re in control of serving the product. They’re in control of the business model of the product. Effectively, they’re in control of their own destinies.” Consequently, I disagree with the characterization of AMP as another closed silo.

The fact that Google’s AMP Cache servers store cached versions of AMP pages and serves them in search results is not altogether different from other CDNs caching those pages. Companies such as Akamai charge a lot of money for use of their CDN, and Google provides AMP caching at no cost. Not only does Google’s AMP Cache speed up the loading time of search results, it allows visitors to page through the AMP results in the carousel with a flick of a finger. Google’s search results carousel is simply one implementation of the standard, and the publisher is still in control. The charge in Wired magazine that “AMP is speeding up the web by changing how it works” feels hollow, unless the author equates Google’s search results with the web.

What might AMP mean for a site such as Opensource.com, which happens to be a Drupal site? With the new Drupal AMP module, the barriers to serving AMP for Opensource.com are greatly reduced. Adding AMP would provide the opportunity for Opensource.com articles (like this one) to appear at the top of Google’s mobile search results and allow for AMP content to load more quickly on social media. The articles would look the same and load faster if other platforms implemented the AMP standard. None of this would make Opensource.com dependent on AMP, as AMP would simply be served in addition to non-AMP content from the same server. In that respect, AMP content reminds me of David Weinberger’s blog, which he offers in three styles (“Style 1,” “Style 2,” and “Default”) and allows visitors to change it.

I am not ready to christen AMP the savior of the web, but I appreciate the philosophy behind it. AMP is not trying to feed the hungry or provide shelter to the homeless—it makes web pages load faster on phones. Short of teaching the world how to build fast web pages that do not bounce around as they are loading, I do not see any better proposals to speed up the mobile web. In essence, AMP forces people to build fast-loading websites. AMP may not be the ideal solution for strong advocates of copyleft licenses (AMP is Apache License 2.0) or those who mistrust Google (the only company mentioned in the AMP project governance document), but AMP feels like the most open solution.

I remain open to other opinions. If not AMP, then what?