I don't see what advantage any company gets from choosing to build products that enable personal data ownership. I say this as someone working on a venture with these sorts of design aims, it feels like pushing a boulder uphill often.

The business model of cloud service providers makes a lot of sense- we have a system which stores and operates on your data, you pay some rental fee for us to store it and operate on it, easy peasy. The cost is related to both the utility of the operations the operator performs (to both the operator and the user) and the amount of data the user stores.

Fundamentally this is how everything from Dropbox to Facebook is governed- Dropbox does not devise much utility per GB and users store a lot, so you rent per GB, but at Facebook, they don't store lots of your stuff, and on the data side maybe you don't get much value from it as it's a cesspit, but the data is valuable to Facebook to sell ads, etc, so they can provide the service for free.

Importantly, you don't need to improve the product to continue extracting this rent, because the product you are selling is not Dropbox v4, Facebook v2.3, rather you are selling ongoing access to the rental.

As soon as you introduce even simply a federated system where a few corporate operators are involved, it becomes very hard to justify extracting rent there as the network designer, as the operators are taking on the cost of actually storing the data. You have to really be iterating on the core product to use a SaaS business model here. Some things simply don't need a v4, does Dropbox really need that much iteration?

Meanwhile as the system designer, life has become a lot more complex for you. Suddenly you cannot push unilateral sweeping changes to APIs, you need to version things in a way that is compatible between, say, one university updating their system but not the other. Since your users are a few large operators rather than millions of individuals, you lose the network effect advantage of being able to screw over a few users for the "greater good", since if you irritate one corporate client, you lose a lot of your install base. Why would you voluntarily choose this harder path as a company?

Things get even worse as you increase the level of decentralization. The reality is users expect the polished experience that the rental companies can give you; they want their data always accessible so that their friend can see the pic they shared without needing to keep their own computers running, they want the "like counter" to go up without their personal node subscribing to messages from other nodes, etc. The only users that will accept a worse experience are people who have are motivated by their philosophy re: personal data ownership, and this crowd will want a FOSS solution, so you can say goodbye to charging them for Dropbox v4, they are simply not interested if you're not giving them the source code for free. (I suspect this is where the author sits, but fundamentally I don't think it will get mass appeal, most people simply do not care about data ownership above something that "just works".)

So now you are dealing with problems like dynamic generation of redundant data and fault- and Byzantine-tolerant consensus algorithms so that your system can maintain function even when the user turns their computer off, and you have to deal with wrapped-key cryptography so that the redundant data can be split across all these user nodes without you worrying that an unauthorized user can read it, and then you have issues like how do you deal with nodes that are too slow to process updates (perhaps some user data needs to be stored in this conflict-free replicated datatype you devise), and eventually you go through all of this to... create a system that is less monetizable than the rental model, because you can't extract that rent for ongoing data storage, and we know users are not interested in actually paying for software.