With everything that’s been happening in the industry of late, more than a few lines by the late Ursula Franklin have been roiling about my head. More recently, this excerpt from one of her talks has been especially front-of-mind:
We cannot be part of a discussion on what risks a certain technology has without asking whose risks. It makes an awful lot of difference. …It’s quite pointless to talk about risk-benefit without saying, “Are those who are at risk also getting the benefits, or are those who are getting the benefits very far removed from risk?”
This is particularly the case if you look at development in the Third World, for example, where women are often in the end more disadvantaged than they were before. The questions to ask are “Whose benefits? Whose risks?” rather than “What benefits? What risks?”
“Whose benefits? Whose risks?” As powerful as they are brief, these questions are design tools: they offer us a lens through which we can view our work, to help us create technology that’s more than just effective, more than just attractive. By shifting the focus from features (“what benefits”) to people (“who benefits”), these questions help ensure the systems we design—as humans, as companies, as governments—are just, and created to serve those who most need them.
These questions can be helpful in smaller, more mundane matters, too. A month or so back, I shared some concerns I have about Google’s Accelerated Mobile Pages (AMP) Project, and the impact it’s having on the open web. Feedback on the post has generally been quite positive, and traffic-wise, it’s my most popular blog entry this year. But I did receive one piece of critical feedback from a few folks, each of whom said something like this:
“But AMP isn’t a ‘proprietary format’; it’s an open standard that anyone can contribute to.”
On the face of it, this statement’s true. AMP’s markup isn’t proprietary as such: rather, all those odd-looking
amp- tags are custom elements, part of the HTML standard. And the specification’s published, edited, and distributed on GitHub, under one of the more permissive licenses available.
So, yes. The HTML standard does allow for the creation of custom elements, it’s true, and AMP’s license is quite liberal. But spend a bit of time with the rules that outline AMP’s governance. Significant features and changes require the approval of AMP’s Technical Lead and one Core Committer—and if you peruse the list of AMP’s Core Committers, that list seems exclusively staffed and led by Google employees.
Now, there’s nothing wrong with this. After all, AMP is a Google-backed project, and they’re free to establish any governance model they deem appropriate. But when I hear AMP described as an open, community-led project, it strikes me as incredibly problematic, and more than a little troubling. AMP is, I think, best described as nominally open-source. It’s a corporate-led product initiative built with, and distributed on, open web technologies.
Again: there’s nothing wrong with this. But as experts ranging from Safiya Umoja Noble to Sara Wachter-Boettcher have told us, we need to look critically at the systems and technology we use. In other words, when we’re evaluating technology, or discussing a particular strategy, we can’t give a project a pass because anyone can open a pull request. Instead, it’s worth asking ourselves Franklin’s questions: when a site adopts AMP, who benefits? And who, or what, assumes the risks in using AMP?
I don’t pretend that these are easy questions to answer. But if we need technology that’s not simply fast or pretty, but just, it’s worth putting AMP under a critical lens. (As well as, yes, Facebook Instant Articles, and Apple News, and, and, and.) If we fail to do that, we can’t be sure how well it measures up to our needs, much less the needs of the web as an open medium. And we definitely won’t know how well it serves entities other than Google.
Note: My thanks to Elizabeth Galle for reading earlier drafts of this post.
As an aside: if you haven’t read Robinson Meyer’s wonderful, wide-ranging interview with Ursula Franklin, I wholeheartedly commend it to you.