Why DAOs Change Everything
getrevue.co
getrevue.co
> In 2008, he split the company into 30 divisions—which swelled to 40 a year later—each of which reported profits separately and had to compete with the others for resources.
> Divisions found themselves acting like separate companies, even drawing up contracts with each other.
As a result, the Kmart employees started to compete with each other instead of helping each other, and the whole thing went bankrupt.
This DAO design does not have direct "complete for resources" part, but it'll still be present -- there are only so many developers who buy into this "permissionless work" stuff, and only so many users willing to constantly switch software version. So visible and flashy features will be prioritized, and small increases in stability will go un-noticed, and as a result the thing will just turn so buggy everyone will flee it.
You cite a great example of central planning gone wrong. They had a creative strategy to run the company and it clearly didn't work.
What if someone could "fork" Sears and have the exact same business, except take things in a different direction (in parallel). Of course, that is impossible since Sears is not a digital product operated by a DAO. However, that is precisely why I claim "DAOs change everything". I lay out what I believe are the necessary conditions for this to work toward the end of the essay.
This will be much worse, of course, with the reliance on social components, which heavily benefit from the network effects. Even with shared database, there will be no interoperability.
Example: Fork A has 1000 users, it has recently implemented "snapchat-like stories". Fork B has 100 users -- now those 100 users cannot see content from popular authors because Fork B has not implemented stories support. And it cannot just borrow A's code, because Fork A recently switched from Angular to vue.js, while Fork B have not done so yet. People leave fork B and switch to fork A, fork B is abandoned, efforts of dozens of programmers are discarded and thrown away. Or alternatively, fork B's maintainers implementing the stories as well, duplicating exiting work and wasting their time. Meanwhile, new users look at dozen incompatible versions of the app, go "WTF is this I cannot figure this out" and go to Facebook instead.
Under my proposed system, apps are installed into a group. So you bring all of your social graph and data.
Alice could invite Bob and Carole to a group. From the group, instead of a chat UI, there would be an app launcher. They could launch into a chat app, a game, or any sort of social/multiplayer experience.
Essentially, there is never a bootstrapping problem for any app because the platform itself provides the social graph. There is also no interoperability problem because versions are consistent across the group (although you could run two forks in parallel, but they would never talk to each other).
Not all apps can be built on this platform, but a large number of useful apps can.