Portability

Many platforms and companies enable users to export their data. Twitter lets you export your followers, Substack lets you export your email subscribers, and Facebook lets you export a list of all your Facebook friends.

This data is considered portable: you can export it, archive it, back it up, print it out, frame it - the choice is yours.

Usability

However, the usability of this portable data varies. While you can export your Twitter followers' usernames, it doesn't grant you the ability to interact with them on other platforms or contact them outside Twitter. As such, Twitter data, though exportable, has limited usefulness.

Substack is a bit better: exporting a list of your subscriber's emails allows you to contact them directly.

The intersection of portability and usability can be visualized on a spectrum, with companies frequently moving along the scale as they evolve and achieve product-market fit (or, if they simply change their mind). Mailchimp allows users to export their subscriber emails but later changed their rules, locking out several cryptocurrency newsletters from accessing their subscriber list and abruptly shifting their position on the spectrum, moving from portable & usable to unportable.

The concept of data ownership is also relevant here. On Mailchimp, users technically did not own their email lists, as access to them could be revoked at any time. Truly owned data would always be both portable and usable, with no possibility for companies to alter the rules and restrict access.

Generally, companies lack incentives to make their data both portable and usable, as some degree of lock-in benefits them. For example, Twitter's network effects would be weakened if users could seamlessly migrate to Mastodon with a single click, taking their audience with them.

Interoperability

If a platform provides both portable & usable data, it's generally easy for users to migrate to competitors if they decide they dislike the platform. Though, why should leaving the platform be the user's only option if they dislike a particular feature or want a specific functionality not offered? Why should there not be some level of extensibility built in by default, letting developers customize to their liking and giving users more choice?

This is where interoperability comes into play. If data and functionality is interoperable, it can be extended and augmented and modified and built upon. Data isn't just portable anymore - it's composable.

Interoperability typically occurs using APIs: companies can expose core bits of their product through APIs, allowing other developers to interact with the underlying data or functionality.

Like portability and usability, interoperability exists on a spectrum, ranging from non-interoperable (no APIs) to partially interoperable (exposing a subset of functionality) to fully interoperable. Again, like portability and usability, companies can and often do move along this spectrum.

Substack data is currently portable - you can export your email subscribers - but they offer no APIs, and thus no ability to customize or extend the platform beyond what they offer.

Twitter, on the other hand, famously had a thriving developer ecosystem - they had nearly full interoperability, letting developers build whatever they wish. Users had an array of choice in how to interact with their followers - if they disliked the official Twitter client they were free to use an array of others. Retweets and other core primitives came as a result of developers - not Twitter! - building 3rd party apps. Then, some of these apps emerged as competitors, so Twitter crippled API access and shut them off.

Striving for full interoperability can align platform owners' incentives with those of their users, encouraging competition based on product quality rather than lock-in. Though, even with fully interoperable platforms, there's no guarantees that they'll continue to be fully interoperable in the future, as evident by Twitter.

The future

Users & developers alike should strive for portability, usability, and interoperability on the far end of the spectrum:

• Fully portable. Users can export it and take it elsewhere if they wish.

• Completely usable. Exporting the data actually allows the user to make use of it elsewhere.

• Entirely interoperable. All data & features are exposed via APIs, letting developers extend & build upon functionality.

Of course, this is not sufficient - we also need strong guarantees that the level of portability, usability and interoperability won't change. To make these guarantees, the data needs to be owned by the user that created it or governed by some code that can't change. There can't be a centralized entity determining what data users are allowed to export, or what functionality is exposed via APIs (and how), since we've seen repeatedly that rules can be changed on a whim.

Building on top of sufficiently decentralized protocols and their associated primitives - not platforms - can help provide these guarantees. Networks like Ethereum, applications like Farcaster, and primitives like NFTs are making strides toward this future. For a developer building on top of Ethereum and using NFTs as a core primitive, there are protocol-level guarantees that rules won't abruptly change.