Imagine if you could follow an Instagram user from your Twitter account and comment on their photos without leaving your account. If Twitter and Instagram were federated services that used the same protocol, that would be possible. With a Mastodon account, you can communicate with any other compatible website, even if it is not running on Mastodon. All that is necessary is that the software support the same subset of the ActivityPub protocol that allows for creating and interacting with status updates.

Mastodon is a fascinating project. At surface level, it is similar enough to Twitter for people to consider it a valid alternative: the UI and the fundamental social constructs could not be more familiar. At the same time, you don’t need to dig too deep to encounter esoteric concepts like ActivityPub and the fediverse.

A common viewpoint is that Mastodon has failed to appeal to a broader, less tech-savvy audience so far due to its federation model, but I tend to disagree: after all we are using federated messaging systems every day and we’ll likely keep doing so until the end of time.

There was a moment when email itself was an esoteric concept and it was important to know what SMTP is in order to send a message, but we have managed to abstract all that complexity away, so I am cautiously optimistic about federated social media in the long run. Arguably the biggest challenge so far is the network effect (or lack thereof), as it’s hard to move to a new platform when all you friends are somewhere else. In that respect, feel free to follow me @maffeis@mastodon.social. Don’t be shy!

In all of these cases, the back pressure that gives wide review any force, beyond a moral high ground, is the fact of multiple implementations. To put it another way, why would implementers listen to wide review if not for the implied threat that a particular feature will not be implemented by other engines?

So yes, I absolutely think multiple implementations are a good thing for the web. Without multiple implementations, I absolutely think that none of this positive stuff would have happened. I think we’d have a much more boring and less diverse and vibrant web platform. Proponents of a “move fast and break things” approach to the web tend to defend their approach as defending the web from the dominance of native applications. I absolutely think that situation would be worse right now if it weren’t for the pressure for wide review that multiple implementations has put on the web.

Microsoft’s release of its new, Chromium-based, Edge browser has sparked renewed concerns about the rapidly decreasing diversity of browser engines. “All browsers becoming Chrome” is problematic in many ways, but while having bigger contributors like Microsoft in the Chromium project could actually help steering the project away from its Google-centric agenda, the issues intrinsic to relying on a single implementation remain open.

My recommendation is to go for replaceability instead of re-use. Replaceability leads in the right direction: you think about how to separate responsibilities in order to make them replaceable, which gives you loose coupling. You think about separating clients from the implementation in order to keep it replaceable, which gives you client-driven APIs.

And, if you might realize after a while, that a component tends to be used several times, you go the extra mile to make it really re-usable in terms of additional testing, documentation and hardening. Therefore I would like to add one more line to the learnings: strive for replaceability, not re-use. It will lead you the right way.

Premature abstraction really is the worst type of evil in engineering, as well as in any other design discipline.