Notes on Adversarial Interoperability
Tags: reflections, tech, strategy
Published: 2020-09-13 23:37:49

---
title: Notes on Adversarial Interoperability
published: true
description: Summarizing thoughts from Seth Godin and Cory Doctorow on Interoperability
tags: Reflections, Tech, Strategy
slug: adversarial_interoperability
canonical_url: https://www.swyx.io/writing/adversarial_interoperability
---

I just caught up on Seth Godin's podcast on [Adversarial Interoperability](https://play.acast.com/s/akimbo/adversarialinteroperability), and it reminded me of a [great YC podcast episode with Cory Doctorow](https://www.ycombinator.com/library/6c-cory-doctorow-on-adversarial-interoperability) on the same topic. Cory himself has written reams of blogposts on [how Adversarial Interoperability has been applied repeatedly over tech history](https://www.eff.org/deeplinks/2019/10/adversarial-interoperability). 

The way to frame this is that there are two types of actors: 

- a (bigger) **core platform**, sometimes controlled by a single company, or sometimes a public commons
- a group of (smaller) **third parties**, which want to connect to or use the core platform for their own benefit and the benefit of users

Based on these basic desires, we have three types of interop:

- **Cooperative Interoperability** is when the platform explicitly works with third parties to enable them, mostly because the platform sees the benefits of adding capability without paying to develop it (in fact, it could be their primary revenue stream, as with Stripe or anything else in [the API economy](https://a16z.com/tag/the-api-economy/)). We may be familiar with these as an "API marketplace" or "plugin ecosystem", but also this happens on a "spec" level with major languages, protocols, and file formats.
- **Adversarial Interoperability** is when the platform does NOT explicitly want third parties to connect for whatever reason, whether it is about control of data or of revenues or of content available on a platform, BUT, crucially, third parties are **still able to interop with it anyway**. [Plaid, the fintech unicorn](https://qz.com/1784765/the-seeds-of-visas-5-3-billion-acquisition-of-plaid-were-planted-more-than-a-year-ago/) still mostly operates via [screen-scraping](https://searchdatacenter.techtarget.com/definition/screen-scraping), as do [Mint and Quicken](https://www.scrapehero.com/mint-com-and-quicken-data-scraping-blocked-by-bank-websites/).
- **Indifferent Interoperability** is when the platform doesn't care, e.g. a fridge maker doesn't care what magnets you put on the door. Usually platforms here claim they are "unopinionated", but I don't think this attitude lasts forever.

The star of the show is of course Adversarial Interoperability. It means that if users are not being served well, someone else (often a technically proficient user themselves) can come along and make some sort of hack to fix that problem (analogous to the [Right to Repair](https://thecounter.org/right-to-repair-elizabeth-warren-john-deere/)). Open Source is itself an inherent promise that adversarial interoperability will always be possible - anyone can fork a project if their priorities diverge from the maintainers.

You can make a lot of money via Adversarial Interoperability - and this has at least some legal protection thanks to [hiQ vs LinkedIn](https://www.eff.org/deeplinks/2019/09/victory-ruling-hiq-v-linkedin-protects-scraping-public-data), a landmark court ruling that even made it *illegal* for platforms to *try* to prevent screen scrapers from getting already-public data. In fact, one could argue that every new social network should be bootstrapped off existing ones, since it's legal anyway.

In tech, progress is fastest with cooperative interop, as all interests are aligned. But progress is also *possible* with indifferent and adversarial interop. 

The problem arises when technology **prevents** adversarial interop, which helps monopolistic platforms keep a stranglehold on their users. This is most prevalent in closed ecosystems like with Apple's iOS.

I think this is an incredibly important idea in [tech strategy](https://www.swyx.io/writing/dev-guide-to-tech-strategy/) - I've forgotten it before, so I wanted to take this occasion to note it down.