Don't get me wrong. I think OpenSocial is a great idea, I want to play with it and support it.

But I want to sell a vision of what I think the real potential of a yasn-as-platform is. Which is giving people and third party developers the ability to build and manipulate their own social graphs.

Until the specs come out, I don't know if OpenSocial will encompass that vision. I think the paradox is that if it fully does, it relegates actual YASN companies to mere implementors of the spec. - effectively commodity hosting providers. (Something similar used to happen when Microsoft defined hardware standards - lots of cheap commodity hardware appeared, which was good for users but not for people trying to innovate new hardware devices.)

Of course, Google may be trying to play the same game with the YASNS.

OTOH, I'd guess the standard won't encompass what I'm thinking of - so in that sense it still leaves plenty of opportunity to individual YASNS to innovate and distinguish themselves. It's just that the application makers will have to handle each differently.

Like Folknology and some others, I'm reminded of Java. I always thought that Sun's "write once, run anywhere" was pretty bogus. Most of what's interesting with software is how it touches the things outside itself. Screens, keyboards, mice, network sockets, sound-cards etc. Operating systems can make managing those more civilized but a programming language can't hide their existence or lack-thereof. (And if you write a program that doesn't need much in the way of peripherals then C is pretty much write once, (compile and) run anywhere too.)

Anyway, what determines the awesomeness of your game's graphics (apart from your talent) is the video-card, screen-size and resolution - not the difficulty of abstracting away the difference between Mac and Windows low-level graphics APIs. That's why Sun kept trying to produce a decent abstraction layer over the Mac / Windows / Gnome GUIs and no-one ever really cared. (The web-browser OTOH provided a genuinely better, as in easier, way to build GUIs and people flocked to it.)

There's something analogous here. What's interesting with social widgets is how they touch the resources of the social network, not how they inject themselves into the user's home-page. But, just as factors such as screen-resolution or number of mouse-buttons was outside the control of the JVM, so the resources of the YASNS, factors such as "community tolerance of hot-potatoes", "willingness to accept strangers as 'friends'" or "ability to distinguish ex-girlfriends from ex-bosses" are likely to be outside the scope of the OpenSocial APIs.

Applications that want to take advantage of the special resources of particular social networks are going to have to get down and deal with the specifics of each. LinkedIn's recommendations from colleagues, or statistics about how many questions have been answered don't necessarily have a counter-part on Ning. But Ning's photo-gallery doesn't exist on LinkedIn. So will OpenSocial try to fake them with library code of its own? Will it demand that everyone who signs up to the spec. guarantees these features as a minimum? Or will it, basically ignore all this for now.

Hence I can imagine the OpenSocial API always running behind the wavefront of real innovations on the yasn-as-platforms. Just as Java has never managed to keep up with Windows and the Mac. Really interesting widgets will be written for a particular platform, to take advantage of its strengths, and only copied over to others as and when the advanced features become available there too. And then, again, long before those advanced features have made it into the common API itself.

Not saying it's bad or not useful. But ...