OpenID vs. Facebook Connect? Wrong Question!

January 8, 2009 in Open Web, OpenID by Carsten Pötter | View Comments

The blogosphere has not been nice to OpenID over the last couple of weeks. Looking at some of the articles it seems like it has become a trend to compare OpenID to Facebook Connect. And each time OpenID is losing. But is this comparison really fair? Or do some people compare apples and oranges?

Well, it seems it is the latter because Facebook Connect is much more than just authenticating users which would be the OpenID part. Users can interact with their Facebook friends on other websites, they can stream their activity there back into the Facebook news feed,… Facebook Connect offers some of the features that have been summarized as data portability in the past. However it is all done with proprietary code. So if people really want to compare Facebook Connect then it has to be compared to the entire so-called Open Stack (OpenID, OAuth, PortableContacts, OpenSocial, and XRDS-Simple). I am not a developer but basically much of Facebook Connect can be build with the Open Stack or to quote Facebook’s Luke Shepard:

There are elements of the “open stack” that can layer on top of OpenID and provide not only a way to contact the user, but also get their profile info, friend data, and distribution among their friends. These are all available via Facebook Connect, and they offer real value.

Open Stack

Facebook Connect Is a Product

So why aren’t bloggers compare Facebook Connect to the Open Stack? I think it is quite simple: Facebook Connect is a product – a really good one, by the way – and probably easier to understand than to explain all parts of the Open Stack to their readers. The Open Stack is not a product but a bunch of protocols, mechanisms, APIs, and what have you that have to be connected by other developers if they want to make use of them on their own websites and platforms. They can make a product themselves if they really want to, though.

Why didn’t Facebook build Facebook Connect with the Open Stack, some might ask? Well, I can’t really say but I assume:

  1. Not all parts of the Open Stack were available or finished when Facebook started developing it.
  2. Facebook Connect fits the needs of exactly one company: Facebook.

Maybe it has some code which is solving problems and demands more efficiently or is more elegant than the Open Stack. Maybe there are even some parts of Facebook Connect that can’t be build with the Open Stack. I don’t know. Actually, I don’t have to know and I don’t care. Facebook Connect is a product for Facebook.

Update: See also the great article by Ben Ward on OpenID, OAuth, and Facebook Connect.

Rebuild Facebook Connect with the Open Stack?

So made it sense to rebuild Facebook Connect with the Open Stack? Probably not. Unless another company really needs exactly the same functionality and features Facebook needs. But companies can’t really know because Facebook Connect is proprietary code, a black box. The beauty and purpose of the Open Stack is to provide tools that are open and that everyone can build what they want and need with it.

Comparing OpenID to Facebook Connect is misleading. It is only proving that some authors either don’t know Facebook Connect, OpenID, or both. Or they know but decided to ignore it in favor of some easy headlines, eyeballs and taking their readers for fools.

Tags: Ben Ward, build Facebook Connect, Facebook, Facebook Connect, Luke Shepard, Open Stack, OpenID

  • The Passport analogy is indeed quite obvious. I wanted to refer to it in the article but somehow forgot. So, it's good you mentioned it here in the comments.
  • William
    Hail to the Thieves

    So interesting that a short time ago Microsoft (A closed source company) wanted to push forward a standard (Passport) that would have given users the ability to have one log in that worked for many sites. At the time many in the tech and development community saw this as just another Microsoft Land Grab for our Identity and our Content. Many people saw Passport as a Microsoft effort to finally gain control of the internet by becoming the standard for digital identity.

    Today we have no less than 3 closed source companies in a race to become the "Standard" for holding our Identity and therefore having access to the content that we read and the content that we creates.

    All of this at a time when there are many Open Source standards that could be used (Openid is just one that comes to mind) that if properly deployed would do the right thing by putting the user/member in charge of their log in as well as their relationships across many sites.

    Have we forgotten the lesson of the not so distance past ?

    Why do we not see a problem with the big 3 trying to become the proprietary standard in this very important area ?

    Why do developers especially Open Source developers continue to build and extend applications for closed source companies that under mind open source standards and ideals ?

    Why do users continue to view giving control of their identity and content to these companies as a win, when in fact the win is clearly on the side of the company that you have allowed to take control of your identity and to generate value and revenue from your content. In return for our compliance we do not even have a right to take our identity and our content where we want.

    At adelph.us we believe in members freedom to control their accounts, and their content. Unlike Facebook we also believe that any revenue model should always put the members in the equation first. We believe in the Open Source community and ideals. We know we are not the smartest guys in the room and trust our community of members and developers.

    Break the chains of the old web 2.0 share cropping model. Do not give your content or your software development work to closed source old world companies they only seek to profit from your identity,relationships, content,or code
  • Chris, that's a really good illustration of what's happening right now. :)
  • Chris Saad
    As you rightly point out - OpenID is a technology not a product. There are many other pieces to the Data Portability landscape. I have illustrated them here: http://blog.dataportability.org/index.php/2008/...
blog comments powered by Disqus