To most people, networks like LinkedIn.com, Orkut, and Plaxo are simply contact managers on steroids. In addition to being Internet-based repositories of your contact database that are accessible anytime, anywhere, and from just about any device (as long as its Web-enabled), their hub and spoke designs where just about everybody is a hub means you don't have to do a lot of work to keep your contact records up to date. Your contacts do that for you because at the end of the day, your contact records are really nothing more than pointers to your contacts' online profiles that are maintained by them.
As is the case with LinkedIn, these networks also grease the wheels of introduction on the basis of degrees of separation. LinkedIn doesn't go as far as the Kevin Bacon game which works off the assumption that no two people are separated by more than six degrees (in other words, through a chain of a maximum of length of five people, you should be able to make contact with anybody in the world). It caps the chain length at three and then it automates the introduction process should you wish to get introduced to someone that you don't know first hand, but who knows someone you know.
Today, LinkedIn has more than 5 million users, most of whom are using the free version of the service but enough of whom are paying for advanced services to make the company profitable. There is a range of advanced services including things like a specific number of introductions per month (cost varies by number of introductions) or $95 job listings. But, from an outsider's views looking in, it can be more and, in my interview of LinkedIn co-founder Konstantin Guericke we discussed the possibilities. The interview is available for download, or if you're subscribed to ZDNet's IT Matters series of podcasts, it will be automatically downloaded to your MP3 player. See ZDNet's Podcasts: How to tune in.
One of those possibilities for example, would be to leverage OPML as a means of managing your blogroll (the list of blogs you pay attention to that's normally posted off to the side of your blog). Assuming the contacts you are keeping track of in LinkedIn write blogs and there's a LinkedIn field for storing the link to those blogs, you could check-off which of your contacts you wanted to be included in your blogroll. And then, via OPML, your blogroll (on your blog site) would literally be driven by the contacts in your LinkedIn database that you selected in for blogroll inclusion. One advantage of such an architecture is that you could stop worrying about whether your blogroll links are being kept up to date. Any time one of your contacts edits their blog address on their LinkedIn record, that information would automatically cascade to your blogroll the next time someone hits your blog site.
The concept of such link sharing is now demonstrated (and easily proven) with Dave Winer's recently launched Share Your OPML. Just yesterday, Dan Farber did a podcast interview with Winer about the launch.
Similarly, during the interview, Guericke agrees that LinkedIn could do more to describe the nature of the relationship. Are they a friend? A business colleague? An acquaintance? Or someone you've never met in person? The sorts of information that the XFN specification tracks (see Will social databases give way to social protocols). Today, LinkedIn is not XFN-aware. Guericke hasn't looked at it but he won't rule it out either.
Another subject we talked about is synchronization of profile data and where such profiles should live. For example, if you talk to proponents of the Higgins Trust Framework, users should be able to maintain personal profiles and make all or parts of them contextually available to other domains on the basis of their relationship to those domains. For example, from your profile, you could make the fields containing your favorite color to a Higgins-compliant car buying site, but nothing else that's personally identifying. Then, when that car buying site begins to display search results as you begin to shop for a car, all the images come up in the various shades of your favorite color.
Currently, LinkedIn has no plans to support Higgins. Nor does LinkedIn have a developer program with APIs that can be accessed and manipulated by developers looking to integrate the site with other sites (in true mashup fashion). External applications like Outlook and salesforce.com have been tightly integrated to LinkedIn, but the integration has been private in nature and is not through commonly available APIs. Conceivably, with all the profile data LinkedIn keeps for each of its registered users, LinkedIn could be a profile serving-node into a Higgins-like network. To further explore that option, I alerted Guericke to the upcoming Identity Mashup Conference that's being organized by the Berkman Center for Internet and Society at Harvard University's Law School. John Clippinger, a senior fellow at the Berkman Center is one of the driving forces behind Higgins which has support from IBM, Novell, and Microsoft.
In response, Guericke raises some fair questions. For example, when a desitination domain needs to collect profile data -- perhaps to register for an event -- is the data propogated to that domain and left there? If so, is it kept in synch with the original source (maintained in user centric fashion by the user)? Or, is the profile data left their as a snapshot in time. Or, is no data propogated on a one-time or routine basis and is it served hub and spoke style on a more dynamic basis. All fair questions worth discussing at the Harvard event.
In the interview, Guericke sees LinkedIn becoming more and more of a platform and therefore agrees that the next logical step would be APIs so that developers could gain more programatic access to the service. Also in LinkedIn's future, says Guericke, are smarter features. For example, a fuzzy search where, instead of searching for people based on keywords, you will be able to search for people who are like someone else you know (and whose profile is stored on the LinkedIn site).