[theamk]

Even you "fork" Sears, you can't fork the customers. Now you have two versions of software competing with each other for customers, and each fork is slightly worse off. Fork enough times and you will only have a handful of users.

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.

[lzrs]

Absolutely correct. I propose a solution at the end of the essay.

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.