Users can still interoperate with other Facebook users, so they don't need to migrate their social graph, which is the greatest hurdle to Diaspora's adoption.
No, the greatest hurdle to Diaspora's adoption is that Facebook doesn't provide the user with any means to export their own part of the social graph -- and in fact takes legal action against people who do.
I'm not interested in the argument of whether Facebook legally can or can't do this; the point is, for many people, this is not a world that they want to live in. Your suggestion doesn't do anything to address the central problem.
My next social networking service is going to provide me control over my social graph. It should also allow me to port basic profile features from one hosted service to another, much as I might do with an email address or a web site.
You're right that moving people off Facebook is going to be difficult, as there is a sunk cost issue. However, I doubt that the establishment of a Facebook-scale social network is going to be a unique event in human history, any more than MySpace or Friendster were. It may not be Diaspora that coaxes people away, but people will take the trouble if there are benefits to be had, and Facebook can't entirely stop all the tools to export friend lists.
Diaspora does not necessarily need to provide photo hosting, events, groups, and other core Facebook services (but it can).
Once again, the whole point is to interoperate seamlessly with services outside anyone's walled garden, especially for commonly shared items like photos, events, and discussion. It is already deeply annoying to have to make separate invites for Facebook and non-Facebook friends. I can't believe that you are even seriously proposing a dual system this while touting your own expertise on what users really want.
BTW, I personally have tried to make an FB app that unified Facebook events with events from other services such as Upcoming.org, and FB's API thwarted me in this regard. Certain bugs made it impossible to distinguish between the user's private and public Facebook events, so my app was inadvertently publishing private events to their FB page. Some of my users complained loudly about this -- you know, that privacy stuff that users don't care about. So I determined this was due to a FB API bug, but amazingly the developers WONTFIX'ed it as a documentation bug (the assertion that the API provided privacy was the "bug"!)
But that's what we get for relying on a service provided by kids just out of college who think they're god's gift to programming.
So, no, I'm not buying that one again.
No matter how well-funded, Diaspora is just one team with zero track record, so they're not likely to be the solution to these problems. But I'm definitely looking for something that fits the bill, and I highly doubt it's going to be a Facebook app.
Can't you add a button (either “Join Diaspora to Friend me” for non-members, or “BeFriend on Diaspora” for non-connected members, or “UnFriend of Diaspora” otherwise) on each Diaspora-Profile page? That would allow users to switch their relations by hand to another Graph, presumably distributed —— a lengthy process, but one that would kick-start the transfer, and could be accelerated with a “BeFriend all Fb-Friends with Diaspora accounts” button later on?
The private Events is a very good exemple of why cross-platform scuks, but I don't see any other option than trying anyway.
No, the greatest hurdle to Diaspora's adoption is that Facebook doesn't provide the user with any means to export their own part of the social graph -- and in fact takes legal action against people who do.
I'm not interested in the argument of whether Facebook legally can or can't do this; the point is, for many people, this is not a world that they want to live in. Your suggestion doesn't do anything to address the central problem.
My next social networking service is going to provide me control over my social graph. It should also allow me to port basic profile features from one hosted service to another, much as I might do with an email address or a web site.
You're right that moving people off Facebook is going to be difficult, as there is a sunk cost issue. However, I doubt that the establishment of a Facebook-scale social network is going to be a unique event in human history, any more than MySpace or Friendster were. It may not be Diaspora that coaxes people away, but people will take the trouble if there are benefits to be had, and Facebook can't entirely stop all the tools to export friend lists.
Diaspora does not necessarily need to provide photo hosting, events, groups, and other core Facebook services (but it can).
Once again, the whole point is to interoperate seamlessly with services outside anyone's walled garden, especially for commonly shared items like photos, events, and discussion. It is already deeply annoying to have to make separate invites for Facebook and non-Facebook friends. I can't believe that you are even seriously proposing a dual system this while touting your own expertise on what users really want.
BTW, I personally have tried to make an FB app that unified Facebook events with events from other services such as Upcoming.org, and FB's API thwarted me in this regard. Certain bugs made it impossible to distinguish between the user's private and public Facebook events, so my app was inadvertently publishing private events to their FB page. Some of my users complained loudly about this -- you know, that privacy stuff that users don't care about. So I determined this was due to a FB API bug, but amazingly the developers WONTFIX'ed it as a documentation bug (the assertion that the API provided privacy was the "bug"!)
But that's what we get for relying on a service provided by kids just out of college who think they're god's gift to programming.
So, no, I'm not buying that one again.
No matter how well-funded, Diaspora is just one team with zero track record, so they're not likely to be the solution to these problems. But I'm definitely looking for something that fits the bill, and I highly doubt it's going to be a Facebook app.