October 31, 2007

Google leading a consortium of YASNS for a common application API is, of course, a fantastic idea.

I can run my app. on Ning, Orkut (which, if you live in this part of the world is a big deal), SalesForce (!!!) and LinkedIn? I am there, baby! (Or at least, just as soon as my FB application is done, I'll be porting it there. ;-)

Will it work to overthrow Facebook? Who knows?

One question is, what resources of access to the users the API will offer developers? This is where the cultural component of the YASNS becomes tricky.

The "killer" part of the YASN-as-platform is what it lets you do with people. And that varies with the culture and privacy policies of the YASN.

The crucial test here will be not "do these networks all provide the same API call to place a chunk of HTML on the user's home-page?". That's pretty boring and not what YASNS-as-platforms are about. (Aside : in fact, a good high-level language ought to be able to abstract away from those differences. ;-)

No, the crucial test is "will their query language (equivalent to Facebook's FQL) allow the same kind of searches to be done on the social network?"

The paradox is, that if the answer to that question is "yes" then all these social networks have just turned themselves into commodity web-hosting. In fact, it's worse than that. They'll neither be able to compete with each other on applications - everyone will have the same - nor on what I call "link-management" (ie. relationship-management) - because that's exactly what a common query language will standardize. So the only thing they have left to differentiate themselves is ownership of your social-network data.

Listen up : if the "common API" includes a common query language and set of relation-types and query permissions, then this is a big incentive for the YASNS to more jealously try to defend their "ownership" of your social network and will disincentivate them from sharing it or allowing "cross-network queries".

However, I don't expect that that's what's going to happen. YASNS-as-platforms have got to realize that they are offering a platform for relationship-management and they'll try to compete by offering different link-management features. So on LinkedIn you'll be able to filter and segment and query your social-network by different criteria from those available on Orkut. And the kind of things you can do with relationships will be the reason you choose LinkedIn rather than Orkut (or vice-versa).

And, if I'm right, and YASNS do see that their strategy is competing on link-management services, then any common query language defined within the consortium is necessarily a lowest-common denominator. And developers will be focused on taking advantage of the more comprehensive and sophisticated relationship management facilities which are only available on a particular YASN. So in practice the number of really interesting widgets and applications which can run across the different YASNS is going to be trivial.

ps : shame I didn't see Tribe on the list of consortium members. That could at least keep them in the game if these applications run on it.

3 comments:

Unknown said...

I am still not convinced that having a Social graph is a business model, I still think social graphs are features of a bigger service.

Thus I see this development as excellent, it will help business see beyond the social graph and actually create useful services/products.

regards
Al

Composing said...

Agreed ... having a social graph isn't a business model. Or if it is, it's a pretty evil one.

But I think giving people the *tools* to build and manipulate their own social graphs *is* a very big and significant model. I'd say that ultimately these tools have to become part of the infrastructure. So if you say social graphs are only part of a bigger service, I think I'd agree with you. But they're not features, more like the sockets layer or the file-system.

However that doesn't mean that they necessarily have to become a commodity yet. I think that we're still in a phase where different platform owners can provide differentiated social network infrastructures.

Composing said...

(Although re-reading what I just wrote, perhaps differentiation *does* make them a "feature")