techno.blog("Dion")

Would you like to be able to make a quick call to get a JSON response that ties together a social graph made up of resources available on the Web?

Brad Fitzpatrick, Kevin Marks, and others at Google have released a new Social Graph API that does just that:

The new Social Graph API makes information about the public connections between people on the Web easily available and useful. You can make it easy for users to bring their existing social connections into a new website and as a result, users will spend less time rebuilding their social networks and more time giving your app the love it deserves.

Here’s how it works: we crawl the Web to find publicly declared relationships between people’s accounts, just like Google crawls the Web for links between pages. But instead of returning links to HTML documents, the API returns JSON data structures representing the social relationships we discovered from all the XFN and FOAF. When a user signs up for your app, you can use the API to remind them who they’ve said they’re friends with on other sites and ask them if they want to be friends on your new site.

This is exciting to me as:

• It actually uses the microformat standards such as XFN
• The API is a simple URL, like the Chart Server API. E.g. http://socialgraph.apis.google.com/lookup?q=bradfitz.com&edo=1&pretty=1&callback=onDataLoaded
• Brad uses a resource that others do not have access too…. he uses the Google crawler. Genius!

I gave it a quick test drive, and when I say quick, I mean 5 minutes :)

I built a tiny JavaScript library that takes a base URL, and it graphs out the relationships using Canvas.

You get to call loadGraph(URL, { width: w, height: h }) and the graph will be injected away.

It needs to be nicely abstracted and isolated so you can call it willy-nilly, but it works.

Watch the introduction video:

Steve Yegge just talked about X programmers in his latest rant:

But you should take anything a “Java programmer” tells you with a hefty grain of salt, because an “X programmer”, for any value of X, is a weak player. You have to cross-train to be a decent athlete these days. Programmers need to be fluent in multiple languages with fundamentally different “character” before they can make truly informed design decisions.

When I think about the opposite of the weak player, I think of Brian McCallister. He seems to thrive in many languages. He tinkers in Ruby. Builds a platform in Java. And, even plays a little with PHP. And then he is off playing with Scala, Erlang, LISP, Haskell, etc etc etc.

I always enjoy meeting up at a conference, and now that we live in the same hood, I feel like we should get together more. It is fun to run into each other at the Palo Alto farmers market after all :)

Anyway, when I saw that Brian had proposed Apache Shindig as an open source OpenSocial incubator, I knew that I should get together and have a chat with him.

This interview is the result of that conversation:

To say it has been amazing to watch OpenSocial come together in recent months is an understatement. OpenSocial isn’t a product that Google came up with, it is a standard. At first you have to get a large number of groups at Google to agree to the core ideas, and then came the partners. Working with the partners has been a real trip too, and the speed of development as well as decision making is truly astounding to me.

I knew that the press will jump on this as “a Facebook killer” or “Facebook vs. Google”, but that is b.s. Applications that are social can be better and we have only seen the beginning. F8 has opened up a lot of eyes, and many companies are going to innovate in this space.

Take a look at what OpenSocial really is. Check out the APIs. Understand that this is the beginning of something. The first set of APIs mesh closely with Gears, as I talk about on the podcast with Patrick Chanazon. There are a few core services (people, storage, activity stream) that have GData endpoints that you can access, including the core JavaScript library which is how development is generally done at the moment. The libraries will look especially familiar to Google Gadget developers, as they are similar in philosophy. To me, this isn’t about some huge new platform, but rather a set of components that people can use. Gears is the same way. You have three key components (as of now): WorkerPool, Database, and LocalServer.

As a Java guy Patrick and I even joked about how it felt a little like some of the Java standards in that this isn’t about “write once run everywhere” but is rather “learn once use everywhere”. OpenSocial has the concept of “containers” where these APIs run. This is where container partners such as Bebo, Ning, Hi5, a ton of others, and, oh MySpace come in. opensocial.newDataRequest() everywhere.

The API is at a point where there is value to using it, and having one API that containers implement allows a developer to develop against it, knowing that they can move their app around. On the other hand, containers can add to the API to give specific information that you may want. For example, if your container has a lot of music information you can share that, and if you are building a music app, that could be a good thing. There is a core set of APIs, and containers will add their value on top, just as WebLogic did through deployment descriptors :)

Back to Facebook. I actually don’t think this is a bad thing for Facebook. It validates the market, and will grow the entire pie. Now even more developers will think about developing social applications. Facebook has a lot of users hanging out on that network, and they are the kind of users that are used to installing applications at this point, so I think that a lot of developers will write applications than run across FB and OpenSocial and beyond. Having MySpace along for the ride is big, and maybe Facebook could join in too and we could create a true standard that the community pushes forward.

It has probably stirred up the FB folk too. They have known that this is coming. Competition is obvious, and I hope that OpenSocial can help push Facebook into getting increasingly open too. They sometimes get a bad rap there, and we keep forgetting that they opened up F8 only *months* ago, and are still working out what it means to open up a platform like this. It will take time and there are a lot of hard problems. As great as collaboration is, there is also a PC vs. Mac debate here. Facebook can run like the wind in their own direction. This could end up being a fantastic product. On the other hand the group could also run quickly as they have been doing, and instead of being stuck in standards hell, they could produce something just a great, across many containers.

Should Facebook implement OpenSocial? I personally think so. Why?

• It will be a lot easier to grow the developer pool on OpenSocial as you can just get new partners and hitwise grows
• If people developer cool apps on top of OpenSocial, why wouldn’t you want them to run as applications in Facebook? It could also allow developers who aren’t fans of FBML to use different methods of building their applications.
• Facebook can still innovate as a top notch container that has a huge amount of users
• It would negate “us” versus “them” talk.

It is going to be an interesting ride, and I hope that people don’t get sucked into the press too much and really check things out. With everyone jumping on board, I wonder what is next. Can we get to the world that Brad talked about? Will we get a federated world? There are some hard problems to solve.

Resources

• OpenSocial APIs
• Campfire One
• Marc Andreessen on Open Social, showing it, and reporting from the trenches
• TechMeme linking to all of the crud out there ;)
• The initial press release