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.

Note criticism of Facebook's failure to protect privacy. This is far more damaging to Facebook's platform aspirations than criticisms of its lack of openness.

FriendFeed is presumably the "open" version of the Facebook news-feed.

It is not a substitute for the things I was talking about.

Gulp! Faceforce!!!

Interview with Clara Shih.

Five years from now, no enterprise app — CRM, HR, ERP — won’t be integrated with the social graph.

To-ing and fro-ing about whether Facebook / Microsoft are a threat to Google.

Some good comments, especially this one : everyone thinks the MS deal is about getting Facebook customers to use MS search technology.

But what if it's the other way round? Bringing FB technology to MS customers? For example, what about a deeper integration of Facebook into Internet Explorer? Or Windows? That point about Facebook needing no UI "metaphor" is telling. Why shouldn't a computer desktop be organized by a Facebook (or similar) social-network metaphor?

Nick Carr makes me curious about Twine.

Quick Note : Read Danah Boyd!

I'm keeping an open mind on the new round of hoopla over "semantic" applications.

I'm a known SemWeb sceptic and I still don't believe in the premise - which I take to be that we should define ontologies (or the semantics of URIs) up-front, independent of applications, and then applications will magically communicate together later because they'll all understand what each other are talking about.

But it may be that the "SemWeb" people have changed their tune and these new players are really only talking about a SynWeb with more meta-data and more smart programs guessing what it means.

Of course, I'm a bit of a pedant and I understand subtle distinctions that maybe the average tech. journalist doesn't. And personally I'm going to find it fucking annoying if we do get a SynWeb and then all the SemWeb people go round claiming that they were right, and this is what they meant all along. But I rather fear that that's exactly what is going to happen, and I'll just have to suck it up and adopt their mendatious terminology in order to be able to communicate at all.

Wittgenstein, bah! :-(

GoogleNews becomes a Facebook widget.

Remember that

a) Google have a lot of smart autonomous people inside. Even if some of them get up and say "there is no platform war" no reason others can't be out there fighting it. And nothing to say platform vendor can't also be application vendor. See Microsoft on Mac etc.

b) Maybe Google has too many good ideas and allowing them to be FB widgets is the solution. :-)

Apple / Google ... together ...

In fact, this is a very interesting and plausible idea in a lot of ways. Apple are now great at producing attractive, user-side appliances. Google make some great server-side hosted software (eg. Gmail) and are trying hard in other areas (eg. Google spread-sheet) And obviously their core search / advertising platform is very impressive.

But let's run this through my yasns-and-widgets / Hagel-unbundling framework as a filter. The question it raises : who is doing what in customer-relationships / product innovation / infrastructure?

At first glance it looks like Apple are the customer-facers, while Google do the back-end infrastructure. In which case, who's doing product innovation?

And that surely isn't quite right - are Apple really customer relations people? In some ways, their creative / design-oriented approach is more product innovation. While some of their treatment of customers betrays a less than customer-focussed attitude.

But it sure isn't Google who are doing the CRM ... unless we see it in their planned revamp of Orkut + Gadgets. And, in fact, it looks like Google are also doing product innovation in software.

Or is the whole Hegel model wrong? And Apple and Google can happily work out a partnership while sliding easily backwards and forwards from one role to another?

Update : Cringely comments and suggests personalities are going to play a much bigger role; Jobs wants it all.

Platform wars are over

Yeah, right. ;-)

Sun playing catch up with Adobe?

They gotta be scared now that AIR is getting lots of love ... ;-)

I wonder why EBay is in such trouble?

Then again, I wonder why we never hear anything interesting at all from them in terms of new technology ideas?

Very Important statement (actually essay / braindump) on my thoughts on widgets and YASNS over on my personal blog.

Tim O'Reilly on the social network operating system. Some good points on the importance of identity and interop of addresses to people.

However, all this talk of YASN-as-address-book is missing the rest of the picture. YASN-as-platforms are not just a convenient way to manage your contact information. They are *also* a way for you to manage social-networks ... which means controlling access.

Not just, as O'Reilly says, allowing your YASN to see into your company directory and see that a potential contact works for you, but to create a company by inviting someone to be your employee in the YASN - with the social-network-operating-system handling all the financial, HR and legal issues that that entails.

SkyPal / MySpace deal

10 Challenges of Enterprise Mashups

Interesting note on Microsoft's Open web-platform

TechCrunch : Facebook Has LinkedIn In Their Crosshairs

Interview with LinkedIn chief

Yep Facebook, LinkedIn have it right ... the opportunity for these YASNS is relationship-management platforms not open-access communication platforms. That's why openness is less of a virtue than discretion and control.

Must check out Coghead.

Scoble on Google, Jaiku and Orkut ...

I wonder whether Blogger is gonna be in the mix too?

Of course, I like the idea of Guerrilla SOA.

Dave enumerates the ecosystem.

Urgent advice to Microsoft. Buy Humanized and fold Enso into the next Service Pack for Vista.

Here's a left-field thought. I wonder if Enso has the capability to wrap the GUI, the browser (and therefore web-based services), the way Windows originally wrapped DOS?

It is, after all, closer to the user than all these things.

Kind of an old-skool platform strategy ... but may yet work. Especially if you can write "widgets" for it (or at least Python scripts)

Further clarification : here's a comment I tried to leave on Joshua's post (mentioned below)

Strange that you say that UI standardization isn't an issue on the web. What about the Jakob Nielsen "users spend more time on other people's sites than yours" school of usability design?

Actually, the world of Facebook apps. and widgets is the first time I've started to see that an old-style platform strategy may be possible. Here the basis is something which which is a hybrid of technology, namespace and social convention. Of which Facebook's "news-feed" is the archetypal example. Facebook's news-feed is not merely technological : which is why other generic data-sharing feeds like RSS or Twitter aren't equivalent. It's also a social convention within a particular namespace and community: I'm willing to look at data that an application writes on my friend's feed, even though I haven't installed the application or explicitly subscribed to it. This is different from the open web - I wouldn't welcome an ordinary web-application that my friend used, randomly spamming my email. (Similarly, if too many bots started writing to Twitter, that would kill that particular community pretty damned quickly, it's not part of its culture either.)

Facebook's platform power ultimately rests on their ownership of this complex but delicate socio-technical hybrid. If they can nurture and grow it, such as giving both users and applications, more and subtler ways to manage it, more nuanced types of relationships between people, with more fine grained privacy control and applications that access these both through the APIs and patterns of software behaviour, then I think they have something that's very hard to escape from or reproduce elsewhere.

This is no longer about just data, or arguments about open access to it. It's data + social data + social conventions.

Joshua Allen responds to Marc Andreesen's types of platform.

He says the new platforms are about "data". That's rather like Tim OReilly's "Data Inside" aspect of his web 2.0 definition.

But a) it's not the whole story. And b) it leads to demands for "opening" the platform by making the data migratable.

It's not the whole story because, in addition to data the's user, her social connections and social conventions are the platform. When you think about it, this is true even with Windows, which is why UI consistency is such an important part of a platform.

On social platforms, the lock-in comes not from just having the data walled up in your silo. It also comes from your network being the place where people tend to do X. And if, on somebody else's platform, people don't tend to do X, then they won't shift the X-related applications over.

Because of his "open-data" perspective, Allen, I think, under-estimates the importance of the hosting issue, although he understands it perfectly well.

It's obvious what benefit a Ning or Salesforce.com would get from keeping your data and code on their servers; it's less obvious what the benefit to you is. There are only two real reasons such an arrangement would be a benefit for you :

If your data, aggregated with data from lots of other customers of the provider, can provide some additional intelligence.

If the provider gets dramatic economies of scale beyond what you could get on your own. In the case of a Ning or a Salesforce.com, this one is dubious. There are only a handful of companies who buy electricity and bandwidth in enough volume to offer hosting cheaper than Amazon. Companies like Yahoo!, Google, and Microsoft.

This is the same debate that's had around Software-as-a-service. It's that "additional intelligence" which is the killer thing that social platforms can offer : doing stuff with social data that cuts across users and across applications. That's why Amazon's database is so much more valuable than everyone hosting their own "I bought and like this book". It can figure out the most popular or "readers who bought X also bought Y".

Yes, theoretically, "scutter" applications can run around a widely distributed microformats, but my bet is that the difference in efficiency and difference in privacy control is actually so great, quantitatively, that it can lead to qualitative differences of application.

Me commenting on Umair's criticism of Facebook.

This is an important step in my thinking about widgets, SaaS and YASNs-as-platforms that I'm trying to write something more comprehensive and coherent about. Meanwhile, there's a lot of the ideas in that comment.