A mental model for decentralization

The only article I read this week that stood out was Avoiding Internet Centralization:

While the Internet was designed and founded as a decentralized network-of-networks, it is continuously subjected to forces that encourage its centralization. This document offers a definition of centralization, discusses the risks involved therein, attempts to identify different types of centralization, catalogues some limitations to common approaches to controlling it, and recommends best practices for protocol designers.

Previous to reading the article, my mental model was something like this: a system can be centralized or decentralized, and there are pros and cons to both designs. In decentralized systems, it's easier for unaffiliated participants to come and go, which has evolutionary benefits. Weaker participants tend to be replaced with stronger ones. However, there tends to be a lot of duplicated effort across participants, and it can be difficult to make fundamental improvements to the system since it requires coordination from many different participants. Centralized systems have the opposite trade-offs. In practice, it's usually best for systems to have a decentralized foundation, with various centralized things built on top.

That's pretty abstract, so let me give an example. The web has a decentralized foundation in the sense that anyone can make a website, and people can visit that website using any one of several different web browsers. You can even make your own web browser and have it work with existing web sites. There isn't any single company you have to go through to participate. But on top of all that, we have some very large centralized platforms like Facebook, Google etc. which do act as gatekeepers for their respective ecosystems. You can't message someone on Facebook without having a Facebook account.

A lot of the debate in this area seems to be a bit too black-and-white. On one hand, there are the decentralization maximalists who think that blockchain will make tech platforms obsolete. On the other end of the spectrum you have defeatists who think that as great as that might be, it'll never happen because it's too hard to overcome the network effects of existing centralized platforms.

Given my mental model of centralization vs. decentralization, I think it's more productive to think about the boundary: how much decentralization do we need? If there's too little, then software will stagnate from lack of competition; if there's too much, then it'll stagnate from lack of coordination. So we want to figure out where the sweet spot is.

Anyway, Avoiding Internet Centralization piqued my interest because it gives a glimpse into a more nuanced model—in particular, it describes different kinds of centralization, and it gives practical advice on how they can be mitigated. So far I've read it only once, and it hasn't really sunk in yet; but it feels valuable.