Sweet! LinkedIn just offered me a widget to embed my Behance portfolio.

I like this for two reasons :

1) I'm about to start taking my Behance / artistic portfolio more seriously. (More on that soon, over on Composing.) So it's handy for me personally.

2) LinkedIn and Behance are a good complement. LinkedIn still fascinates as an example of a successful YASN which isn't competing directly with Facebook. And Behance is another example of a purposive social utility which seeks to tie its portfolio hosting to more specific products and services for creative people.

I wonder if this signifies any deeper connection between the two companies, or whether it's just that the OpenSocial Behance widget became available for OpenSocial containers such as LinkedIn.

Google launches Orkut Apps. in India.

This, I guess, is OpenSocial.

Update : previews.

Bebo (which is already aligned with OpenSocial) decide to clone the Facebook API too so Facebook apps will run on it.

Dave Winer says that FB supporting this effort is the "end" of OpenSocial.

He may be right, and that's a bad thing.

You can see an allegorical image of Facebook with a devil on one shoulder and and angel on the other, whispering advice in its ear. Facebook could choose to be "good" or choose to be "evil". Opening its API was good, Beacon is evil.

"Good Facebook" would be competing as infrastructure for social applications, providing more ways to let applications writers help you benefit from your social network. "Evil Facebook" thinks applications are merely a complement. It competes on "owning your social network" and reselling it for its own benefit.

While it's not actually evil to allow Bebo to clone the API. Being too blasé may demonstrates that FB are only really thinking about the dark-side strategy. Same problem is true of OpenSocial. If social-application hosting is seen as a commodity, YASNS have to compete on exploitation of your social data.

Ahem ... like I've been saying. There's nothing really wrong with the OpenSocial or openness or even common APIs for social applications. It's just that in practice it's pretty much impossible to square the conflicting privacy concerns, and requirements for user's control over their own data, with widgets except in a walled garden owned by one trusted platform owner.

You'd need an entirely new security model.

Currently ...

Security issues are the main problem. “At the moment security is up to the container,” Marks said. “It’s clearly something we need to work better on, authenticating between sites.”

OpenSocial could potentially have functions, such as add friend, and bridge between social networks, but security gaps get in the way. “It comes down to the permission model from Unix. It treats applications as agents of users. The model needs a bit of refinement–you don’t want to delegate read/write access permission to others.”

How much flexibility to build into the APIs is a concern. “If you delegate back to the container, a gadget can send mail. It’s different than a gadget asking to send mail itself. It’s a fine line to walk. If you protect it too much, you are making it unusable and people will walk around it,” Marks said.

OpenSocial could hook into an instant messaging buddy list, but it could allow invasive scenarios such as clicking on a friend and seeing the friends full buddy list.

So Facebook doesn't need to start worrying yet ...

OpenSocial People does not support queries.

If I read it right (after 5 mins, I admit) the API supports getting one friend by id or all friends. But no query that filters friends by link-type. Which, if you think about it, means that there really aren't any social applications that you can build which don't need to go beyond the scope of the API ... which means that all the interesting social applications are still gonna have to be platform specific or modified on a YASN by YASN basis.

Damn! Haven't even had a chance to look at OpenSocial yet ... IRL getting in the way.

Dare Obasanjo fun

Although I don't think this (has to be) true yet

Here we go ...

TechCrunch both right and wrong .... OpenSocial can't claim victory until the users turn up.

But wrong ... because they still think it's all about squirting one chunk of HTML / Flash / Javascript into another.

And if their OpenSocial apps start to gain more traction because they have more functionality, they may just start to put those Facebook projects on the back burner. (With OpenSocial, for instance, full applications can run on members’ profile pages, whereas on Facebook there are substantial restrictions on what developers can do on those profile pages).

OpenSocial apps aren't going to have "more functionality" in any meaningful way. Because social applications are not like desktop or browser applications. The only functionality which is important to social widgets is "social functionality" and that is dependent on the richness of access to, and the sophistication of manipulating, the social graph itself.

OpenSocial is extremely unlikely to be able to offer as rich a functionality in this sense as Facebook (or, indeed, any particular YASN) can, because it's got to be a least-common denominator between a number of very different philosophies of what a YASN is and is for.

Having said that, this is a very cute thought :

Joining OpenSocial could actually be a brilliant move for Facebook, especially if it can become the advertising network of choice for social apps. If Facebook can make it easy for Facebook developers to port their apps elsewhere and power those apps with Facebook ads, why wouldn’t it do so? Checkmate, indeed.

More rolling thoughts ...

will the OpenSocial API trickle down to all the community management type programs and service eg. Wild Apricot etc?

Bebo now join OpenSocial ...

so big question ... what about Microsoft?

There's also a funny question : what about Facebook?

What, in practice, would it mean for Facebook to join OpenSocial? If your app. takes advantage of FB specific features that don't exist in the OpenSocial API you aren't likely to downgrade it. If it doesn't ... well ...

actually, hold that thought ...

Is OpenSocial going to provide a common catalogue of applications, so as long as you register your app. it automatically appears in the directory of all participating YASNS? Or do you have to register each separately?

What if you widget actually has code to take advantage of features specific to Orkut or LinkedIn? Will it be visible in their catalogues but not Ning's and Bebo's?

C'mon Google let's see ...

YASN-world rapidly self-organizing itself into major power-blocks :

MySpace joins OpenSocial ...

Two thoughts :

- if OpenSocial takes off, will MS just have to buy Facebook?

- where the hell are AOL in all this? How hard would it be for them to buy a little YASN, make sure it fits the OpenSocial spec, and give all their users accounts? Have they just totally given up?

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 ...

Mark Andreesen weighs in with his explanation of OpenSocial.

Basically sounds like you can register a callback with the YASNS which pulls HTML / javascript from your server. Sounds very good and simple as a way of embedding your application into their pages. Great! But not much of a clue what it means for whether your application can get access to the social network itself. Or to what extent.

What he does say is that apps. can (are likely to) test which YASN they're in and run differently in each. So, er, yeah ... OpenSocial doesn't prevent apps. taking advantage of YASN-specific stuff.

So it's kind of what I expected ... but let's see ...

(Drumming his fingers impatiently ...)

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.