The trick is to find a working bootstrapping strategy.
Our approach with sandstorm.io is to make sure it's easy to port existing open source apps. Even with just the platform we have now and the apps we're porting, I feel like Sandstorm is already a product useful enough to stand on its own. Crowdfunding (as we're doing; http://igg.me/at/sandstorm) can't pay for a revolution, but can pay for the MVP, which can then pay for the next iteration, and so on.
"Joining hands" sounds nice in theory but in practice more developers simply does not equal more productivity. At the early experimental stage, it's important to have many small teams iterating quickly on different approaches; a single large team will simply spend all its time arguing and will get nowhere (a lesson I have unfortunately learned the hard way). I am happy to see lots of people working on solutions to this problem because it makes it more likely that one of them will succeed. :)
Thanks for the comment. I agree that in practice more developers don't equal more productivity. And I agree that things happen better in small teams. But I still don't see the point of not talking to each other, and learning from each other. One reason I suggested what I suggested is this:
If you just run some one else's Linux applications on linux boxes, and call it a personal data store, you have a bunch of problems to solve:
1. No cohesion in UIs
2. No cohesion in APIs
3. A crappy user experience.
4. Code Maintenance
As soon as you think of solving these problems, you'll see the problem of scale, of the number of programmers needed to do things (both frontend and backend).
I still think that the people interested in this should talk to each other(, and perhaps try a divide and conquer approach -- whenever possible), compared to just trying to patch each other's code to make it work in a small team.
I hope you agree, that this is not an easy problem to solve technically. At least I think so.
I think all of the problems you bring up are indeed hard problems, and important ones to work on, but they are also problems that exist already, in the current ecosystem of open source web apps, and even often in proprietary apps. About the only way you get "cohesion" on the web today is by limiting yourself entirely to services from one company (Apple; Google), and even then it's far from seamless. Yet, somehow we make progress.
So our goal is not to solve these problems, but to incrementally improve the state of the world. Clearly, the first thing that needs to happen in order for open source and decentralized web apps to be viable is there has to be a way that common, non-technical users can actually use them. Sandstorm is trying to offer a solution for that, and we think we're pretty close. As much as possible, we actually try to stay out of the question of UI or API standards. IMO that's a problem that can only be solved organically.
Our approach with sandstorm.io is to make sure it's easy to port existing open source apps. Even with just the platform we have now and the apps we're porting, I feel like Sandstorm is already a product useful enough to stand on its own. Crowdfunding (as we're doing; http://igg.me/at/sandstorm) can't pay for a revolution, but can pay for the MVP, which can then pay for the next iteration, and so on.
"Joining hands" sounds nice in theory but in practice more developers simply does not equal more productivity. At the early experimental stage, it's important to have many small teams iterating quickly on different approaches; a single large team will simply spend all its time arguing and will get nowhere (a lesson I have unfortunately learned the hard way). I am happy to see lots of people working on solutions to this problem because it makes it more likely that one of them will succeed. :)