This article from the WSJ is neither deep nor particularly novel, but I like it because if focuses a laser on propagation of identities and the history of identities in popular social networks. This is the most important metatopic for social networks.
If you have a few more minutes, this article by MIT Media Lab prof Judith Donath gets a lot clearer on the signals that make up identities online, and how the mechanics of those signals can function.
In a the social graph model, people are usually the nodes and their relationships to one another are the edges. Profile data become node properties. Relationship data (worked with, married to, used to date) are the edge properties. There are some twists on this, like making a company or school (say Stanford) into a node that people connect to, rather than an aspect of a relationship ("used to go to Stanford with").
Proposition 1
Today's graphs have lots of node data, but are very weak on edge data. It's the problem where
This binary friendship is the weakest form of social graph, especially as it gets syndicated via apps and APIs throughout the Internet. It's poor quality information.
Proposition 2
The next step, the of 1.1 of edge data, appears in schemes like FOAF, and apps like LinkedIn. LinkedIn at least asks how you know someone ... did you work with them? where? when? That information adds value to their network.
The uber-social-graph (the hypothetical union of graphs) that we imagine and talk about can only have real value when the edges have quality (how do you connect), quantity (how well), sign/directionality (let's face it, there some people I might like, know, or relate to more than they do me, even if we're generally on the same level). In fact, the edges are multidimensional ... multiple different linearly independent quality/quantity/sign groups might all apply over a single relationship. Like anytime you've spent time working professionally with a good friend. If it's someone you've been romantically involved with, toss another set of attributes on there as well.
Proposition 3
One way to get to 2.0 would be to ask people to create a profile for each relationship (friend) they add. Probably not likely to happen, because it's labor intensive in proportion to the value of the data: Saying I worked with someone is not as good as saying where it was and when, adding that we were pretty friendly and had beers a lot after work, adding that we were both really interested in, say, programming languages or biking, adding that I convinced him to volunteer with me on so-and-so's political campaign.
It's a lot of work.
Passive acquisition of the data would be easier and more accurate: my emails or IMs with someone would tell how often I talked to them, what about, in what context, etc. The existing email, IM, and soc net comms providers (e.g. facebook messaging) have most of this data already. Ideally they would get my approval and once-over before asserting any conclusions, since it's still early days as far as accuracy of automated semantic analysis.
Proposition 4
Even if passive acquisition and analysis were occurring and were accurate, the data could be quite wrong as long as my life spans multiple systems. E.g., gmail sees 50 emails with someone, all related to Java work. The Google graph system draws one conclusion. But if there are 2500 AIM messages somewhere else, about wacky topics and at different times of day or night to the same person, the picture of the relationship might look a lot different. So the data from many modalities of communication (chat, IM, email, TXT, phone calls) and many systems needs to be analyzed together.
Proposition 5
This will require an ingenious entity to manage the graph. The government's attempt to do more or less exactly what I'm talking about is likely to be kept far from us law-abiding citizens. (I consider it only a matter of time before the world's top cybercrime / warfare / terrorism groups actually compromise this database, but they're not about to give us an API to it either.)
It won't be practical to keep this data secret; users will need to understand that once they allow data to flow into the system, it will be syndicated and replicated forever; it can't be pulled back. This should not shock current users of social networks, who must assume that not only their friends list/network, but the history of its deltas over time, and any tracking-cookie-enabled assumptions about the people it, may already be in a Google cache somewhere or in someone's data scraping startup.
What is to be hoped is that there is some centralized mechanism for auditing, correcting, and marking things as questionable. I.e., some group of graph engines that have a higher degree of trust than generic web scraping. Incorrect data could be challenged by allowing the engines access to additional information.
Proposition 6
Automation in turn gives rise to graph spam and graph phishing: if a med vendor sends me 100 emails a day, does that imply something? If a foreign con-man tricks me into clicking his link or sending him an email, does that get him mileage in my social graph?
One way or another, this stuff is coming, so we may as well start figuring it out right now.
So XSpace is actually, well, everyone in the social networking space except for Facebook.
And the Red Pill app itself is still a hypothetical, but it's getting closer and it's clear where that data would be helpful now.
Scoble's suggestion that his friends would all have to move before he'd look outside the "walled garden" of Facebook, and Don Dodge's suggestion that Facebook users won't just leave are both missing the point.
Users don't need to make up their minds now, they only have to decide that at some point in the future they might want to spend more time somewhere else. That's where Red Pill and its data come in.
Meantime, Bebo's press release headline ("[...] REVEALS PLANS TO LAUNCH FACEBOOK-COMPATIBLE DEVELOPERS PLATFORM") appears to overreach the actual article content -- namely, that Bebo will "make it easy for Facebook developers to port their applications," not necessarily host Facebook apps directly.
But there seems to be no clear reason why an OpenSocial proxy system could not actually host F8 applications. Except for maybe some terms-of-service issue. All those "fb" abbreviations and tags may have to get ROT13'ed or the like.
Suppose I build a skeleton social networking app, call it "XSpace" for convenience. Maybe it has a couple of clever, unusual features, but there's nothing much there, and no users.
Now I build a Facebook application called "Red Pill."
If you add the Red Pill app, and give it permission, it will export data from your profile into storage on XSpace. None of this data is published or shared or anything else that would violate the current Facebook TOS. In fact, at this stage, it's a lot like FriendCSV, a current friend data exporter app -- it's actually a strict subset of FriendCSV, since the data is not actually downloaded as a file, just stored in a private spot in XSpace. (The FB Terms of Service prohibit storing user data for more than 24 hours, but this is less of an issue than it seems: we'll talk about this later)
Now I add a feature to Red Pill called "Take Me"
Take Me brings you into the XSpace app, with all of the social graph structure already in place, from everyone who has installed Red Pill, even if they've never "taken" it.
If a lot of people run Red Pill, then the core value of Facebook -- the network itself and to a much lesser extent the profile data -- is replicated into XSpace.
What happens next?
In the Facebook-success scenario, XSpace becomes an interesting alternative world to Facebook, linked by Red Pill "tunnels," and mirroring some parts of the social graph. Maybe a nice symbiosis evolves or XSpace is subsumed into a pure traditional Facebook app.
In the Facebook-failure scenario, something kicks off an exodus from the 'book. Whether it's a change in functionality, rules, service level, or just "cool factor," a mass of people pop the Red Pill and just start logging into XSpace instead. They keep all their original friend and profile data, so it's a smooth transition. Maybe XSpace also implements the Facebook API (it's a small, public API after all) so that Facebook apps can run in XSpace as well...
It is only a matter of time before the "Red Pill" and "XSpace" show up. That's the risk you take building a platform with a API -- it's actually to be expected, even desired.
But in the world of network-effect applications, there's a twist: these apps do not derive their value from being "the best implementation of the platform" (typically the way a platform implementer tries to assert value). Instead, the value is page views driven by the social graph itself and by the apps on the platform. Since both of these areas can be trivially replicated in XSpace, there's not much left. That is, there is no core value-add (aka Sustainable Competitive Advantage) left to Facebook as such.
Could Facebook cut off (or dial down) the API? Sure, but at the risk of slower growth and possibly aggravating users and developers who might like to play in someone else's open sandbox. And if they were too late in doing so, the move could actually spark the emigration to XSpace.
Could Facebook assert intellectual property rights over the data? Maybe, but facts cannot be "owned" as intellectual property. So the fact of my having a friend relationship to someone, or having met them in a class, or being married, are all things that no one owns. There is some user-generated content that the user has "signed away" rights to, but we're not talking about that. I.e., we are not proposing scraping out and re-using any content outside the core profile facts (age, name, etc.) and social graph.
Could Facebook complain about XSpace storing user data more than 24 hours? Maybe, but it depends on how the boundaries of the systems are defined, and in any case the better solution is for Red Pill to pull updated user data every 24 hours rather than archive the old data. If the app is ever cut off from retrieving this data, then it will keep the last snapshot, and then who cares, 'cause it's "game on."
As long as Facebook's valuation can be reinterpreted as an artifact of a Microsoft marketing expenditure (i.e., not a true investment, as some have suggested), this doesn't matter to anyone except maybe Microsoft.
But if Facebook is looking at taking really big money in, or eyeing an IPO, they'll be forced to think about cutting some of the Matrix exits. What will they do? What can they do?
On Monday, Om wrote about the commoditization of social networks. A couple of days earlier, dojo added a nice section to its docs comparing AJAX frameworks ("Why Dojo?").
What do these things have in common? Only that they reminded my of a couple of other technologies...
Remember "portals"? A portal was how to make your site sticky, customizable, get users to spend lots of time there, view lots of ads make you lots of money. Maybe they would even set it as their homepage! A few companies made big money as purpose-built portals. Then there were content-management sites where every group of accounts shared a portal that they could customize themselves -- using the site itself! How amazingly meta! And then came open source portal and CMS products and finally the sign that portal magic had surely jumped the shark, a JSR for portal components. Ok, portlets, I said it.
That first part was fun though ... sounds a lot like social networking sites. Groups of users. Widgets. Social. Sticky. Ad views. Customizable. And as Om points out discussing Ning, you can roll your own right online. The next step is code I can download and run locally, or that godaddy.com sells me with my domain name registration. Like CMSs, storefronts, and shopping carts, the basic software form of a social networking site is stabilizing (stabilized?). Freshmeat lists nearly a dozen social networking apps/projects in varying states of maturity.
I'm not criticizing these sites; quite the opposite -- I'm suggesting that their success will be so complete as to make them just another page in another site. Eventually one ASP.net template or Rails script will import all the social networking features you could want.
AJAX frameworks and libraries remind me of application servers:
I'm not trivializing app servers. Standardization was a boon, and the decision of which to use had long-term consequences. Painful ones, if the decision was taken incorrectly.
Eventually, though, in part thanks for Moore's Law, commodity hardware, open source software, and the nuclear winter, it became no big deal. They all work. More or less fine. Some are better than others for certain things, but no one's gonna waste time arguing that PHP or IIS/ASP.net is "just no good," and (non-technical) business concerns or the right talent often makes the case for one or the other today.
Aside from their being interesting in themselves, these comparisons are meant to put some perspective on where we are in the technology cycle. We're getting past the "hey wow" part of AJAX, widgets, and social networking features. Commoditization comes, standards emerge, infrastructure value-add declines.
These bits become the new top layer of the stack, and we should be thinking about the apps that we will build to ride atop them.
