The html times

Elegantly Powered by Google

Chris Messina and Identity in the Newtork by Boaz Sender February 9th, 2008 Delicious



Listen to this Interview

This text will be replaced


Download This Interview

mp3, or Embed interview:

<br /><a href="http://www.htmltimes.com/chris-messina.php">Chris Messina and Identity in the Newtork</a>
<embed src="http://www.htmltimes.com/assets/jwplayer/player.swf" width="400" height="300" allowscriptaccess="always" allowfullscreen="true" flashvars="author=HTML Times&description=Video from the HTML Times&captions=this is where a caption will be&duration=10 minutes&file=http://www.htmltimes.com/chris-messina/chris-messina.mp3&image=&link=http://htmltimes.com/chris-messina.php&start=0&title=HTML Times Audio Player&type=MP3 Audio&backcolor=333333&frontcolor=FFFFFF&lightcolor=000000&screencolor=000000&logo=&linktarget=www.htmltimes.com&controlbar=bottom&stretching=fill"/> <br />


Relevant Links

Chris's Blog
Diso Project
David Recordon
Joseph Smarr
Portable Contacts
Eran Hammer
Britt
Alex Payne
DeWitt Clinton
hCards
micro formats
vCards
Data Capital

Chris Messina and Identity in the Network

Chris Messina has a lot to say about our collective identity crisis in the network and open source projects in the corporate internet. He was generous enough to get on the phone with us for bit to discuss some of the exciting things he has dedicated his life to, and provide a window into how open identity is going to work. We decided to publish a transcript of the interview in full, and have divided it up into seven sections.

On the Open Stack

Boaz Sender: So maybe first you could talk a little bit about the Open Stack. What is the Open Stack?

Chris Messina: Sure, I think the easiest way maybe to understand the Open Stack is to understand the problem domain that we're operating in. And a lot of these technologies are being developed around a pretty simple idea — well, I wouldn’t say it—s necessarily simple — but where it goes hopefully will result in something a little more simple and straightforward — but the idea really comes down to figuring out how to enable a lot of social networking functionality that we kind of take for granted in what you might consider sort of walled gardens — closed silos — the best representations of which are sites like Facebook and MySpace where they have these very active, very popular groups of people coming together and connecting and being social and what not and is certainly a tremendous trend that has made people be a lot more realistic about how useable software needs to be. … But the problem with that is that when you essentially you restrict yourself to one or two or three main players, you radically diminish competition in the marketplace and therefore choice. And when you diminish those two elements of the system, you actually — I think — hurt the opportunity to innovate and do interesting things.

So the Open Stack, in a roundabout way, I believe is trying to ensure the longevity of social networking through the production of technology to allow people to social network between different websites. So if I have Facebook account and you have a MySpace account, there should be no reason why we shouldn’t be able to swap messages and share photos and things of that nature because we already have accounts.

We know who each other are even if we aren’t on the same service. This is the way email works. We don’t have to be on the same services to send them a message, so why would that be case where if you want to share an application with someone — you want to play scrabble or scrabulous with someone else — you basically have to sign up for an account over there, which of course also means getting another password and so on and so forth. So the Open Stack technology will simplify doing this sort of cross domain, cross–site social interactivity, making it easier for people but also making it powerful for developers to do interesting things without necessarily forcing them into one proprietary system that disables them from being able to move from one site to another. That’s kind of a long answer to the question but I guess that is the kind of the context in which these things are being developed.

On OAuth and Intellectual Property

Boaz Sender: Yah, it is a lot of stuff to think about. So maybe we can talk to the developers and the people who are dealing with the different domains and different servers first. Maybe we might talk about OAuth. One thing I’ve read a little bit about that I thought was really interesting was the Intellectual Property Rights resolution that was recently reached a couple months ago. Can you talk about that conversation, what the problem was, and how it was resolved?

Chris Messina: Yah, you know, I’ve had a very interesting trajectory myself, personally, in open source software. Four or five ears ago, I didn’t really know what open source was all about. My first sort of foray was working on Drupal and Civic Space, and then working on the Spread Firefox project and then seeing Firefox, and understanding what open source was all about through open source software that was starting to bridge the gap from geekdom into consumer software.

That was a very interesting time, because you essentially have an environment and a group of people that are used to producing software in the open. Collaborating, sharing, enabling others to sort of innovate on top of their ideas, and moving into a more consumer or commercial realm where things like patents, intellectual property, and trademarks and so on are enforced as a way of making residual profit on ideas that, say, someone had a long time ago. Or the research that someone did to produce the way of executing the idea.

In the software world, we find that those type of intellectual hindrances can actually cause great damage to an ecosystem by forbidding people to be able to look inside the way things work, or be able to, let’s say, take some legacy system and reverse engineer it and create a solution that enables data to flow more freely in a modern situation.

So with OAuth, it was an interesting situation because it developed out of a need that was discovered, as far as I'm concerned, in my advocacy of OpenID with Twitter and Magnolia. Both of those providers have APIs and Magnolia in particular had an API that allows you to create a bookmark using a dashboard widget.

Meanwhile, Twitter of course had a number of applications being developed that made use of its API. And both of those systems required a username/password for essentially creating content.

So when you want to use OpenID — where there is no password — and you’re in a situation with a desktop application or a web service — all of a sudden you no longer had one of those critical components to identify and validate whether or not someone was actually who they said they were.

So lo and behold, there was a need for OAuth, and it turned out that a number of large service providers (Google, Yahoo, AOL, Flickr and so on) had already solved this problem but had done so in ways that were incompatible. They essentially solved the same problem four or five times. And they weren’t about to use each others’' work for any number of reasons, some which may have been legal reasons, or may have been ego issues or some which may have been like, "Well, we have our API, they have theirs, what difference does it make?"

In any case, we set about creating our own best of the breed protocol, and took about nine or ten months to do this, and just over a year ago, I think it was December 4, 2007, OAuth 1.0 was released alongside OpenID 2.0. And we were patting ourselves on he back, thinking we had accomplished this great feat, we had this technology that people at least seemed to like, that dealt with some of the other protocols before.

And then, it turned out, the real work started. We had to go through a process essentially where everybody who had contributed to the spec signed an agreement that stated that they would not invoke any patent or intellectual property protections that they or their company might have had in the area of delegated authentication protocols.

And this was done primarily because we needed to clean the IP of this technology so that the large providers could get it past their legal teams in order to implement it. This was not something you typically think of in the open source ecosystem because people there typically are smaller providers, smaller vendors. It’s unlikely that you are actually going to sue a competitor.

But when you get to a larger scale, all of a sudden, you know, some individual, or let’s say; patents troll, is sitting way back in the wings, kind of biding their time, waiting for somebody to implement something that actually infringes on their patent so they can sue one of these large companies. And these large companies, of course instead of going through some lengthy lawsuit, just decide to settle and license that technology so they can use it.

So in this case, we had to deal with that reality, a reality we were not familiar with, and primarily Eran Hammer — who is also one of the authors of the protocol and DeWitt Clinton from Google and a number of other people — sort of pushed through an agreement, going back and forth with the various legal departments and reps from these large companies to come up with something that they all could live with that essentially asserted to each other that they would not sue anybody who also signed the agreement.

So it’s sort of like this weird arms race situation. And several months ago, we finally got to an agreement everyone was okay with. We finally got it signed off by the big companies, and that’s about as good as we're going to get with a protocol like OAuth without going to a standards body like the IETF or the W3C and groups like that who forbid intellectual property from entering into the process of developing the standards whatsoever.

So the difference — and it might be interesting to note that this is where the Open Web Foundation came from, this is where the genesis was — was that here we had a great process for developing technology. The grassroots community got together, they pinpointed a problem, they looked at prior art, they saw how people had solved this problem before, and they picked among the best and came up with a solution that would work for a lot of people.

And the desire of course was to create a solution that was widespread, widely adopted, and would lower the cost of doing the right thing for users.

But the way these situations work, it tends not to be conducive to collaboration to have to essentially put all your cards on the table in the beginning before you even know initially what you are going to work on. And that’s the way that these other standards bodies tend to work.

They essentially require everybody to come up with a scope of work in advance of doing anything and keeping people within that scope because there had been agreements around the intellectual property and the sort of work that would be produced.

And so it creates a sort of encumbered, very slow–moving, very arduous, very painful process, and ultimately standards that are produced, I think, tend to be somewhat convoluted and somewhat dense. Whereas the approach we took, because we had a lot of parties involved and a lot of different needs, we boiled it down to the bare essence of the problem. And even though this first version we came up with might not have been as expressive as everybody would have wanted, it at least let people do things in a low cost, convenient, and consistent way and solved the headache that otherwise would have persisted for some time.

Boaz Sender: I see. So the standards bodies enter into development of a set of standards with intellectual property concerns already settled, whereas this was an effort that sort of coalesced and that’s why those concerns had to be settled after the fact.

Chris Messina: Yeah, that’s right. I’m throwing this metaphor, you know, out of my brain, but you can imagine in the Kings Court, you might say “Well in this battle you can bring you swords and your shields and nothing else”, whereas in our situation it was like anything goes: whatever makes the most sense in the context of this situation is up for grabs, make use of it, and then we'll figure out later on what comes out of it. What are the results? And so on. Like I said, I guess that’s a terrible metaphor (laugh).

Boaz Sender: No I see what you're saying, and that’s what I’m used to myself when I’m developing for fun, you know, passionately with my peers.

Chris Messina: Whether or not, basically, you take all the fun out of it by seeing into the future so much that you limit yourself to this pathway — which may not be the best pathway — but is the one everyone has agreed is the least controversial, and then you end up with these convoluted technologies that really solve nobody’s purpose, but they’re nonpolitical and therefore not so interesting.

Now that doesn’t always happen — the standards bodies do produce good work sometimes — but I think that because there is so much — what you might call premature optimization upfront — there is a desire for this process to be extremely lucrative and extremely productive, such that every problem is solved by the time the standards body is finished with its work, and I think that’s where some of this tension comes from.

When we started out, there was no sense anyone would actually adopt the work that we had created. If they did, we would be really lucky. In fact, we were joking "Ha-ha, wouldn’t it be funny if Google actually adopted this? Man, that would be the day." And sure enough, they did. And if we had gone through that other process where we had set the scope of everything and designed everything up front, we probably would have ended up with more complicated technology.

As it is, getting people to adopt OAuth is still a challenge. You can imagine any extra bit of complication would have greatly impinged upon our ability to spread this technology even more so. When you're dealing with community spreading vectors, to spread this stuff, they've got to be as simple as possible.

Getting OAuth adopted

Boaz Sender: Maybe you can talk a little about that, with the bigger service providers like Google. Did you approach them, were you the evangelist, or did they approach you? And what was it like, back on the subject of pushing it through their legal departments. What were the steps?

Chris Messina: Well, it was interesting the way it happened. We started this project with a small number of say, 10 to 15 people from Twitter, Pownce, Magnolia, Flickr, Digg, you know, all sort of part of this conversation that went on for several months.

My role, since I’m actually not a developer (I can talk like I am, but I’m not one!), was to bring people together and talk these issues through and make sure that people make the time for this to happen. And I played more the role of facilitator.

It turned out that at the Google Developer Day last summer, Britt from Twitter had actually been talking to, I think it was Britt, or maybe it was Alex Payne— one of those guys was talking to — I think — DeWitt Clinton about what we were working on — OAuth. And he mentioned it to John Panzer, who had recently come to Google from AOL, and they became interested in this project.

At the time, I was trying to run the mailing list as a bit of a benevolent dictator of sorts, keeping it closed and making sure we had some specification that represented the best of our ideas before we put it out for the rest of the world, but by the time DeWitt and John Panzer heard about it, the cat was out of the bag and we very quickly I had to start opening up the list and getting more people involved.

Once they heard about it, we started to moving in that direction, opening things up, getting people more involved with what we had been working on.

I’m not sure about the exact amount of time, but shortly thereafter we got to this fork in the road where we'd been developing this idea of having three separate flows: one for mobile, one for desktop, and one for web. And these were three different protocols all wrapped up in one and Eran Hammer came along— he actually had his own startup he was working on out in New Jersey and he joined the list and said: “)h wow, this is great, I’m actually trying to solve the very same problem, I have a very similar solution, looks like you guys could use a little help here, let me come in and crack some heads and rewrite this thing”

So he sort of became the catalyst, working with other people in the project, to rewrite the spec as a unified flow. It wasn't quite as elegant, but at least it was a more straightforward solution and produced what ended up more or less becoming the final version of OAuth and led a lot of the draft and revision process after that point.

So he kind of took over when we hit the middle point where I was sort of at the end of my realm of experience and he was able to drive it through with these two-week long draft review periods where he would put out a draft and say okay, this is draft one. In two weeks, I need to know your feedback and I'm going to put out draft two. And two weeks would come up, same thing, did this for about three or four drafts. And it wasn’t really until, as you might expect, when he was saying, “this is going to the final draft, this is it, if anybody has any feedback, you better tell me now, because it—s coming out” — when all the feedback rolled in.

And all the while we had folks from Google, Yahoo, AOL, and so on actually contributing very productively, very positively, very openly, without any lawyers being involved and I think it was a very positive experience that resulted in a great deal of collaboration and good faith on the part of all the actors.

So that’s how that all came through, and in the end a lot of the legal stuff ended up being done behind closed doors because Eran eventually ended up getting hired by Yahoo as their chief open standards, open spec evangelist cat herder and went to work for them, and then started doing the liasoning between Google and Yahoo legal and trying to come up with legal statement that they all would come to agree to.

Now the legal stuff that we used actually originated from the OpenID Foundation and the OpenID non–assert agreements that had already been approved.

What turned out to be the case was the wording that Sun had originally proposed for OpenID — or was finalized for OpenID — ended up actually not being that great. There are a couple reasons, one of which was that the OpenID non–assert statements didn’t really protect the individual developer.

There are also a number of legal concepts in this stuff that I’m not all that familiar with because of course, I am not a lawyer, but that essentially said whether or not somebody could sue somebody else. Basically it—s the arms race idea, but it—s whether somebody from the outside could sue somebody from the inside, and whether or not the other parties are enjoined to sue that third party that is suing or whether it is every party for themselves.

I forget what ended up coming of that, but in any case we ended up rewriting much of our non–assert statement and that is essentially what we have today. Again, what we are trying to do is take that agreement, apply it to a number of other protocols and specifications we're working on like Portable Contacts and so on, and create a series of documents that the Open Web Foundation will provide for any other community organization or group that feels the need to make their formats and technologies more available to a wider audience including large companies and large providers.

Boaz Sender: So open source the document that helps you open source the technology.

Chris Messina: Yah, I mean, what open source I think is typically related to is code and copyrights and the copyright of code. Well what we're talking about are patents, business logic, rules, protocols, and things of that nature. And that is not a realm that open source projects in the wild tend to operate in.

Now the reason is because we are dealing with a world of web services. So it is no longer about local APIs and access on the desktop where it doesn’t matter what someone else’s protocol looks like. Now we are talking about moving to the web where you are completely reliant on someone else’s web services in a very different distributed, decentralized way. And that requires a great deal of political intercourse between all the different parties in order to get people to come to the table to agree to a set of solutions that they will adopt and also not invoke any intellectual property they may have around it.

Portable Contacts & not reinventing wheels

Boaz Sender: So I want to hear more about data moving around between different services and around the Internet, but just so I understand, is this a typical process for these larger companies before they engage with any open source projects or was this particularly troubled because people from so many different Internet companies contributed?

Chris Messina: I think the bigger problem is simply that when you're dealing with a technology that a large number of competitors are going to implement, they want some kind of assurance that if the implement it, they are not going to incur the wrath of somebody or something or some legal department. And I think this is par for the course when it comes to large companies dealing with each other. In other words, these legal agreements are a form of communication between big brainless, soulless corporations. It’s how they understand each other. If that makes sense.

Boaz Sender: This is an interesting insight. So what kinds of personal data or information about a person’s identity are these standards letting people take with them, and what kind of things do you see these standards expanding to? What other kinds of data?

Chris Messina: I think the most promising one in this regard at this moment that is farthest along given its short life span is Portable Contacts. Portable Contacts is being headed up by Joseph Smar from Plaxo — which obviously has a vested interested in user data — but nonetheless it is providing a protocol and technology that will hopefully accelerate your ability to move your social graph from one place to another in much the way we're seeing now with Facebook Connect giving people a salient example of what decentralized, distributed social networking is like.

Portable Contacts is the format — the wider format — through which you'll be able to access your contacts. Now it’s interesting because Portable Contacts itself leverages a number of other building block technologies and formats in order to do what it does.

So, for one thing, it was very important to me that Portable Contacts, because I had been involved with that project from the beginning, learn from and inherit much from what we've learned with hCards and micro formats in that micro formats inherited from vCards, the standard that has been around forever.

So there's already all this data out there that is already marked up with hCard in–so–much that vCard is a known quantity and works with people’s address books today. And in so much that OpenSocial is gaining a lot of traction — but also did invent a whole new contact schema out of the blue — which I still cant understand why people do this all the time, but they did it — we decided lets come up with something that can leverage all this existing work and all the familiarity that people already have with vCard.

And that’s essentially what we did. We modernized it and in fact it requires the use of OAuth in order to get access to someone’s contacts.

Now that is in contrast to what we see a lot of the web today where you go to import your address book from somewhere else and these sites that you don’t trust are asking for your username and password. We specifically wanted to provide a solution that was easier for developers, better for end–users, and more secure because you were no longer passing around your credentials to untrusted third parties just so you could interact with your friends that you had already defined elsewhere. So Portable Contacts is the technology that is going to enable both identity graph portability and social graph portability.

Boaz Sender: I signed up for a couple of different OpenID services and signed into a couple different social graph services with different OpenIDs and I know that you have mentioned the user experience problems that exist because not everyone is a relying party, just an identity provider and other reasons, but it’s still kind of problematic. What is the ideal situation that you see for these different social services? And I think one of the big problems is merging and reconciling your different social graphs.

Chris Messina: Yeah, it’s very good question, and I think there are a couple pieces to the puzzle. The first is that this stuff takes time, especially when you're dealing with the open web. Facebook has a circumstance which we of the open web don’t have, which is complete top to bottom control over the entire ecosystem. So what Facebook says goes. And as long as you conform to their spec, you're fine.

That has not quite been the case when trying to work with these large providers and developing protocols that work for them but also work for independent providers. For example, if you want to put this on the htmltimes.com — your needs are going to be somewhat different than Google’s — but the same protocols should work for you as for the large providers.

So that is one of the issues. I think the other aspect of this is that we're still at the point where— okay, there are two things.

One, we are developing these building blocks today and so the DiSo Project — which is a project I founded about a year ago — is attempting to articulate the needs for different types of building blocks and to go about creating the ways in which those building blocks are conceived and then leveraged in different social networks. So friending would be one of them.

OAuth is another building block of the Diso stack. OpenID is another one and I’m currently working a lot on developing a format or a means for doing richer activity streams between websites, primarily over Atom — but with a few conventions that make it easier to, for example, create a Friend Feed without ever having heard of any of the services that might populate the content of FriendFeed. So there is that aspect of it.

The second aspect is that only now with Facebook Connect are we finally able to have an example of what the hell we've been talking about. Open source tends to be very good at seeing something that is done in a propriety way or a closed source way and commoditizing it with a solution that usually has a couple of optimizations and works for people in a slightly different way than the proprietary solution.

I’m not actually all that worried about not coming up with a solution that works. I am a little worried about some of these solutions that are being half-baked right now or being proposed as answers to the Facebook problem like OpenSocial in a way that shortchanges what is possible long term.

For a specific example, I think it’s really problematic right now that Google Friend Connect has launched. There is very little differentiation between Google Friend Connect and OpenSocial and to date Google Friend Connect does not afford me a way of hosting my own social graph on let’s say my own blog or a third party provider that I trust. Basically, it’s like, if you have friends stored in your Google account, then you can bring them into a Google Friend Connect website. And that is not the way the distributed, decentralized web is supposed to work.

Boaz Sender: So Google Friend Connect is sort of a little form that you fill out that says what kind of social interaction you want to have and gives you bits of code…

Chris Messina: Not exactly. Google Friend Connect and Facebook Connect are quite similar. They are somewhat different in the mechanisms in which they are implemented, but that’s largely because Facebook has a very different approach to this kind of stuff.

They also have a very different type of spec and store of user information. Clearly people are motivated to provide a great deal of information about themselves (as Facebook says all the time) because they felt that they were interacting with their peers and interacting on a social level.

In contrast, Google has been much more of a productivity company, a search company, an apps company, an open source company — what have you — but it—s only within the last year or two years that Google has become at all social. It—s shedding some of it—s autism but nonetheless it still has that built into it—s psyche where it is an engineering firm at heart, whereas Facebook came out of a college dorm and represents that level of social sophistication to some degree. Which is perfect for where it is today.

So the situation again is that there isn’t enough value and enough data behind an OpenID that comes to your website to necessarily implement support for it. On the other hand, there is a lot of value in implementing support for Facebook Connect because you have access to all this data which you otherwise have to come up with some way of convincing your users to provide you that information. Well that’s probably not going to happen, especially if they have entered it in elsewhere.

So what this means is that smart OpenID providers for those sites like MySpace and what have you that already have lots of good information about their users will enable people to reuse those identities in other contexts and other sites and they will also hook up access to a number of other third party services through that profile.

And that’s when it becomes interesting. So rather than saying I store my photos at Facebook, my videos at Facebook, my friends at Facebook: Facebook, Facebook, Facebook… I want to be able to say, well, I prefer to use [insert OpenID provider here]: MySpace, what have you, Yahoo, but I choose to use Flickr for my photos, YouTube for my videos, Plaxo for my friends, and Twitter for my status updates. And I want to be able to pull all those together all at once at the moment of verifying my identity at some remote site using OpenID. And that’s when it starts to have real value. When it starts to enable user choice, but also user convenience. And we're quite a ways off from that today.

Boaz Sender: Yah, from my experience, you don’t have much access to information through Facebook Connect as a developer. The social graph has a lot of information, but all you get as developer out of Facebook Connect is the user’s birthday and profile picture, after that a lot of the sort of rich data is not available for, I guess, security reasons.

Chris Messina: Yah, it—s a little bit of BS around the security stuff, it—s a little bit of Mommy Facebook knows best as well.

Boaz Sender: Exactly.

Chris Messina: But as well, in some ways, given their audience, unfortunately or fortunately, they have created the situation where they essentially are saying, “well trust us with your data and we will not give it away to anybody who asks for it whether or not you want us to because we do know what’s better for you. We do know there are a lot of sleazy apps out there are that are just going to try to spam you or spam your friends and make you look bad and all this stuff. And for us, well, if we want you to continue using our services, we are going to make sure we wont give your stuff away.” So in some ways, I am sympathetic to where Facebook is, but on the other hand, long-term I don’t think it’s the model that should be the dominant one on the web.

Facebook Connect and OpenID

Boaz Sender: So there is this comparison out there, I saw it a lot when Facebook Connect went into public beta and more now that it—s launched, comparing OpenID to Facebook Connect as a sort of versus. Is that a valid comparison?

Chris Messina: It’s not a valid comparison today. It is the comparison that I want to be made in the future. I believe that the OpenID brand needs to be made stronger, needs to mean something, it needs to have some teeth just like Facebook does where if you implement OpenID in such a way that it screws up the user experience and makes everyone else that’s supporting OpenID look bad, then you should be penalized in some way for doing that.

Now hopefully we can shame people into doing the right thing by providing them with good guidance that says, “Okay, you made a terrible user experience here, but that’s okay, you're not an idiot, here is what you should actually be doing and here is the documentation to do so.”

We don’t have any of that documentation. We haven't done enough studies, we haven’t done enough user experience testing, we haven’t gotten the right people involved and diversified the community of OpenID and of the identity ecosystem to reach out to designers, marketers — people who understand and interact with regular people — who are not mired in this technology gobbledygook all the time.

I think this is a serious challenge we have for us, but it—s one that I think we will be able to meet. So the comparison between Facebook Connect and OpenID is a very specious one, frankly, because the gulf between Facebook Connect and OpenID today is monumental.

I mean, OpenID sucks in comparison to Facebook Connect, so that means we can only get better. But for Facebook Connect, over time, who knows, we can wage a war of attrition for all I care. If we can get into console systems, if your Wii gamer tag could be an OpenID, if you can get into mobile devices and that experience becomes excellent where you boot up your G1, you type in your OpenID, and voila, you have all your services ready to go and you could do this phone after phone after phone, year after year after year.

If your OpenID becomes your reference to your identity online and you give it out at parties because it—s easier to remember than your phone number or it—s more secure than giving away your Facebook account, then that, to me, becomes interesting.

If my mom has some value in remembering my OpenID because all my activities are brought together and I can provide a customized view of the things that I’m doing on the web to her, because I also recognize her OpenID on the web, and I can say, “show theses photos to my mom, but not these because these are work related and they are not going to be interesting to her”, that's also adding value and that’s improving the situation where she can choose to use whatever social tools or social networks she wants to use — I can use the ones that make sense for me — and we have a nice diverse ecosystem where what I call the middle class of applications will rise up to fill that middle as opposed to having these tall, gargantuan ones that say, “well it—s going to be our way and this is how it—s going to be.”

The business of the open social web

Boaz Sender: So forgetting the confusion that arises for users of “who to share what with” in the transition period away from these closed networks — because maybe one day when we're all used to managing this from the outset we won't be worried about our drunken Facebook pictures on LinkedIn — but forgetting that, as all these different services become portable and we can carry stuff around with us and maybe even carry our search data around — what is the business model for these big companies that are implementing these standards? I’m asking this because I saw an advertising company's deck that you sent over to ReadWriteWeb recently that posed a lot of what–ifs for Amazon.com implementing Facebook Connect.

Chris Messina: Right, the Razorfish one.

Boaz Sender: Right. Well, first it strikes me as a lot of hot air because a lot of the stuff isn't possible yet, but maybe one day it will be. I mean, Facebook hasn't realized a business model yet, they don't make money. Amazon.com makes a lot of money but what is the opportunity cost of sifting through all this social activity and figuring our how to really create value from it?

Chris Messina: I think starting in 2004-2005, all the way up to 2010-2015, we're going to be in a period of transition. Whatever came after the Industrial Revolution started in the 80s and had a very myopic perspective on how work is done till 2004 into the future where we are having this great social upheaval where instantly we are connected to everybody and yet along with that we have democratized the tools for publishing, making the technology a lot cheaper. I mean, I never would have thought that every Mac product I would buy would have a built–in camera pointing at me. But that means in every device, I have a publishing platform right in front me of me.

And therefore, because we have lowered those costs and made everything much more accessible — and YouTube is a great example here — there is going to be a huge value proposition for those companies that can go through all the stuff you’re producing and all the stuff your friends are producing and help you to make sense of it. And I think, in terms of why companies are supporting a lot of these technologies, the little stuff we're trying to solve right now — the authorization stuff, the identity stuff, so on and so forth — have very little value in them necessarily.

You're not going to build a business on your authorization protocol. There really is no value there. However, once you are able to push and pull private data, well, then you can start to add real value behind the firewall on the desktop in the private realm that the open web does not necessarily see.

That’s sort of interesting, being able to be the host of what will be — from a service perspective — a data broker: “I will be the one that will secure your data, will be able to find copies of all the data you are publishing across the web, store copies of it for you, as well as see interactions people have with that data.”

So if you're publishing a photo on Facebook and then on Flickr and then on something else, and something else, and something else, because you're just doing what you do which is social networking and communicating through multimedia, you're going to want to know what other subsequent interactions took place against that media. And I think there will be an opportunity there for this stuff to be done automatically for you as opposed to it having to be done manually as it is done today.

And I think that will greatly enhance the social–ability of people on the web, but can also lead to very interesting business opportunities or commerce opportunities, where there is the ability to do recommendations or, as was shown in the Razorfish example, you show up on Amazon and you're about to buy some Blue–Ray player (like I did recently) and it says, “Oh, well your friends purchased this one over here. Perhaps you'd like to chat with them in real-time about their purchase and see if that—s useful for you.”

So you get to a point of real-time social search that’s vague and very hard to do because our social graph is inconveniently located right when we need it most. So I think there are those elements of it that are interesting and I also think there is an opportunity here to create the next Visa and MasterCard of the Internet generation where — and I wrote about this in a concept I call data capital — rather than being the source for your money online, it—s going to be very valuable to have access to all of your data and all the stuff you're produced, and all your social media and all these different pieces.

So you're going to want a company that you trust to manage these things for you, or do it yourself if that’s your desire. But there, I think, is a great opportunity. You imagine — I have 7 gigs of storage on Gmail or something ridiculous like that — well in 5, 10, 15 years, it—s going to seem like nothing at all. Now I have no idea what I’m going to with 15 years worth of email, but if Google or whoever I’ve chosen to host my data with after all this time is there charging me for that or figuring our some new advertising situation because they have all this data — I think long term it begins to make a lot of sense.

So I think there is an opportunity there, but the reason why this stuff needs to be portable — or needs to, again, ensure user choice — is that there needs to be competition in this space. Because we are not at the point where we have figured everything out and we can leave things as they are and let them stagnate.

We need to have the ability for you to take all your email and move it to another provider if someone is offering a better service — with less ads, more social integration, what have you, whatever it is, because there will be a moment when these providers can essentially take all the data — the raw data you are producing — and add value on top and produce a stream of your content that is actually more valuable on the other end.

The information economy

Boaz Sender: Well I have so many more questions for you, but something you just said might be a good place to wrap up our conversation. It is something you mention a lot when it comes to increasing competition and therefore innovation by making this stuff portable: What happened with intellectual property in this environment, in the network, and this might be a broader social question, but what happened with intellectual property and the way we treat ownership in the network that all of the sudden started quashing innovation in some environments?

Chris Messina: Hmm, well, that’s a challenging question.

Boaz Sender: Well, maybe not what happened specifically, but what is characteristic of closed and proprietary systems and solutions like Facebook Connect. What is characteristic of Facebook Connect that--

Chris Messina: Well I think I tend to fall back on biological examples and metaphors when thinking about these things, because nature has proven to be quite resilient much longer than our technology has been. And so when I see discrepancies between the way technology is deployed and the way natural systems evolve, it gives me pause to think maybe there is something amiss here.

One of the problems with intellectual property when it moves to the web, I think, is that impedes organic and emergent growth. So this is why I think that’s why Creative Commons is such a powerful and important idea. It enables ideas to grow at the speed in which they will naturally grow and emerge. And if you can imagine knowledge being an organic compound and reacting to an environment, certain environments and certain aspects of an environment will determine whether or not knowledge proliferates or whether it dies.

And when you put constraints on knowledge and information through patents and other types of artificial control, it seems to me that you compete at the degree to which you can lock things down and prevent other people from using things as opposed to developing new and innovative ideas that out execute your competition.

So in other words, there's an impotence that occurs — it seems to me, when you move to an information-based network economy with patents and things like that that don’t really apply in the offline world.

Patents and so on sort of made sense when you were dealing with the Industrial Revolution and you spent all this time developing this nut or bolt that required you to have some tolerance so things worked and came together — very similar to the reason that trademark was valuable for companies like Coca–Cola. If I could produce some brown sugary water and call it Coca–Cola and sell it, that diminished the value of the brand or the product that Coca–Cola was essentially trying to sell because I was using their social capital.

When it comes to the web, the challenge is not so much — it seems to me — so much locking things down but actually getting people to care. Again, because there is so much information out there and there are so many people doing so many different things and now we have access to all those different things, the challenge is not so much keeping other people from using it — because they will simply route around you — it—s getting people to actually use your stuff and to care about it, and to espouse it, and to improve upon it and to commit to you.

So that to me represents more of a neural network — a biological system — an emergent system that is very robust and stands the test of time and context and situation and culture than one that requires you to have a sort of top–down, police state that enforces controls, artificial controls, over the proliferation of essentially what is a free resource, that is information.

So that I think is what has happened and what the difference is where we dealt with intellectual property in the past where it dealt primarily with physical goods that were restricted because they were scarce and because they required physical labor and hard labor and such to create them versus today where the marginal cost of posting a new blog post or sending out a new tweet or whatever is so small, yet because so many people do it all the time, well, now the challenge is getting anybody to hear you in the first place.

Boaz Sender: I think that’s a great answer as it applies to what we've talked about here with the Open Stack and as it applies to content, it is something I end up talking to people about a lot because all the content on this magazine is free to be republished and sold. So I think that's a great answer.

Chris Messina: Good (laugh).

Boaz Sender: Well I appreciate you taking the time to talk to me and the readers. Thanks, and have a good night!


Comments

Comments are now closed

Related Articles:

Van Jones and the Green New Deal

By Jacob Perkins

Jacob Perkins Interview's Social Activist Van Jones about socioeconomic inequalities in the environmentalist movement, and his role consulting the new administration's transition team.
Read more …


Information Wants To Be Free

Elegantly Powered by Google