Dataportability needs to bring something to the table

Published on: 29 Mar 2008 by Anders Conbere

I feel like this will probably get lost in the huge torrent of comments here. But I think the sentiment of this is important. I've been talking a lot about "how to make creating social networks easier" for the last year. Part of this discussion has involved the people associated with Social Network Portability and some of it has Involved the people associated with Data Portability.

For the last couple of years a number of people have been fighting a battle waged in the world of publishing. "How do we get closed networks to open more of their data". During that time I've been working on problems like "How can we use xmpp's roster as a distributed social network". I feel like the problem of publishing data has largely been solved, this was a marketing problem and the space is now familiar with many of the contemporary companies and the idea has reached a tipping point. What remains is a problem of digestion and one that has gone relatively unheralded. That is, how do we make this data that is now being exposed useful and relevant.

One of the interesting things that I find happens when you reframe the problem like this, is that "importing" users data becomes minimally interesting. As a social network built around providing a set of features being able to import a starting set of social data is only minimally helpful. My big problems still exist. I need to build tools to help me manage those relationships and I have to market my product such that the user base is large enough to make my application useful. If we extend that into other types of data the same kinds of problems emerge.

Basically, we've tackled a problem that exists for consumers, "I want my data back", and done a pretty good job. But forgotten that these tools we're providing need users themselves, and that the users of these tools are not consumers of social applications, but rather the creators of new social networks.

New social networks need a user base, but the creators also want to reduce the complexity of creating their applications. This means that tools that we provide these creators need to offer something. They need to not only help the creator build a user base quickly, but also provide tools for managing complexity. In the case of importing relationship data, the tools should include abstractions for adding and removing friends, and storing the state of that data off site. The tools might want to bring with them features that are painful to create in and of themselves, like messaging, and presence. The should make the life of the creators of social networks easier, and the fact of the matter is, is that right now getting social data doesn't appear to be the problem that social networks creators are facing.

So how do we approach this? I think the first thing to do is to start using the tools available and imaging ways to bring things to the table. If we look at OpenID and oAuth, and open social, those technologies have seen fairly serious attention from large sites. And if you look all of those technologies help reduce the complexity for the people making social networks. They either help reduce the overhead of exposing api's, logging in users, or creating applications on top of your tools. When we look at the other technologies (XFN, FOAF, Microformats, etc.) that Data portability is championing I think we see a very different pattern. I know I've suggested that xfn offers almost nothing back to creators, but there are solutions I've found for FOAF (pinback + oauth + sparql), and certainly XMPP brings a lot to the table. That being said, these tools don't exist yet, and they'll take time to build. But until our tools are tailored for the creators, I don't think we'll see significant adoption.