IT history is repeating itself - but it is not a shame

Following a twitter discussion with Tom Wentworth , Kevin Cochrane and Stephane Croisier on the impact of Facebook Connect on Web Content Management, Stephane made following comment, which needs an answer in more than 140 characters.

Facebook Connect is a technology that allows third party web applications to connect and share data with the Facebook social network. It supports authentication, access to user properties like name and birthday, and it allows sharing of application data on Facebook, for example a website could post custom status notices that would appear in my Facebook activity stream as "Lars did xyz on site abc". Jeremiah Owyang called Facebook Connect an example of Social Colonization earlier this year. And while in Jeremiah's description the colonization turns out to the mutual benefit of Facebook and the connecting site, there is still a negative connotation with the term "Colonization", which is shared by many people in the industry, most of them outside Facebook.

The cornerstone of our discussion is that while Facebook Connect is the most popular example for social network interoperability technology, there are numerous other emerging standards and technologies that can be used to create a distributed social network. The most important examples are:

RSS /ATOM - a way to exchange data in feeds between applications on the web
OpenID - a way to identify yourself to a website using the credentials of another website
OAuth - a way to grant an application access to a certain part of your data on a website
OpenSocial - a way to exchange data about users between social networks
OpenSocial Gadgets - a way to embed small web applications, gadgets into other websites
ActivityStreams - a way to share the activity of an user on a social network with other websites
DISO - a collection of technologies to create a distributed social network

This open ecosystem allows developers to create distributed social networks without relying on a single centralized "Conquistador" like Facebook who controls data and access to the system. Yet, for now I would recommend website owners to invest resources first into implementing Facebook Connect. The main reasons are: you get access to the largest possible user base, the integration model is well tested and needs no fiddling with multiple, developing technologies and users already know what to expect from a Facebook Connect integration. Once the limitations of the centralized model become obvious, for example because the central hub is unable to scale, loses the trust of users, or benevolence turns into malevolence - then it is time to federate and to invest into open standards and open source.

This pattern can be observed numerous times in technology: a proprietary leader defines the market, fails in an attempt to fully dominate the market and is attacked by other players in the industry striving for standardization and openness. "If you have a problem for a long time, maybe it's not a problem, but a fact". It think this pattern is not a sign of our industries inability to learn, but a result of the basic economies of innovation.

Innovation is hard and costly, so you try to keep it for yourself (proprietary)
In technology, network effects make successful innovations wildly successful
In order to fully monetize the hit innovation you had, you have to keep a close grip to it

This explains why hit innovators are favoring closed solutions: it is the easiest way of getting their investment back. What worked for IBM, worked for Microsoft, worked for Oracle, worked for Apple, worked for Facebook, so why shouldn't it work for your next innovation? In fact, it will work for the innovator, it just won't work for users. Companies do not do the right things all the time, but if you are locked in into a technology, you are betting on your vendor hitting one home run after the other. And this is why users and visionary followers are pushing for openness, standardization and decentralization - another significant effort, but one that requires an existing, proven market to justify the investment in standardization.

The reason why history is repeating itself is simple: we cannot start out with a standardized solution, because we neither know what to standardize nor if it is worth the effort. Once we know, there is an established, proprietary player that is holding to his closed technology.

Posted by Lars Trieloff

Oct 07, 2009

Stéphane Croisier said...

Hi Lars,

I share most of your points:
- Facebook is today the leader. No doubt about it. Then, from an operational point of view, at this very moment of the History, we could only strongly recommend to any website owners to first support FaceBook Connect and then if they have more time and money other standards.
- Innovation is costly and innovators need of course a way to find some financial leverages else there wouldn’t be any innovation at all. I am not an Open Source fanatic guru and I think OSS tends more to copy and commoditize than to be a source of true innovation (even if reality is never white and black).

The only thing I was (briefly – courtesy of Twitter ;-) ) mentioning was the timeframe when a de-facto standard needs to embrace more openness and standardization. The IT industry could of course replay the Internet Explorer browser story. But when the impact on consumers is becoming too large, one should question the right timeline where some lobbies should push in.

In this precise case (FaceBook) the debate is now quite similar to what is happening to Google Books. After having done their innovation, leaders have no interests at all to become more open. They will rather try to slow down any alternatives or other obstacles such as some new legal frameworks. This is normal. This is their job to protect their shareholders interests. In the case of Facebook (and all other social networks) we are now really facing some problems of privacy, identity management and data portability (http://dataportability.org/). For instance Swiss citizens just approved at 50.14% the new Swiss Biometric Passports last Spring (http://www.edri.org/edri-gram/number7.20/swiss-biometric-passports). And most of the criticisms and fears were about the fact that some citizens’ properties will be stored on the chip and could be perhaps stolen by unauthorized persons. On the other hand, in the same time, FaceBook is just exchanging user properties for 300+ million end-users (Switzerland only has 7 million inhabitants) without nearly any legal frameworks. And we all know that laws are ways behind the current pace of innovation of the IT industry. Meanwhile this gives room to a lot of possible abuses.

So I am not saying that FaceBook is currently raping any laws. But let’s say that similar to the GMO use case (http://en.wikipedia.org/wiki/Genetically_modified_organism), private innovations need sometime some public debates especially when they bring some disruptive revolutions in our life rather than some smooth evolutions. And the current impacts of Social Networks have something of revolutionary (at least by their size). And the basic precautionary principles are not always correctly applied. But I agree. This is another debate about how Laws could more rapidly adapt themselves to innovation and add more possible constraints to innovators. As a PM which needs to better recommend customers, FaceBook Connect is the way to go right now. Let’s still hope this whole thing will not turn into a next Big Brother.

Lars Trieloff said...

I think the Internet Explorer story was unique in a number of ways: Microsoft conquered a market in its infancy and rendered a non-market at the same time by giving the browser away. Microsoft acknowledged this by dissolving the MSIE team. Incentives to invest into browsers (and to re-establish the market) rose when the web as a platform became more visible.

Facebook is in an entirely different position - it is under constant attack, because everyone recognizes the value of the social networking market. This means history will repeat itself, but much faster - for a CMS vendor it takes perhaps three release cycles to realize there is a new browser, whereas Facebook connect will stay the only option for less than two release cycles, then the distributed social web will have enough staying power for us to integrate it.

Kroc Camen said...

You have three buttons here to login for comments--
Posterous, which I have never heard of; facebook, which doesn't actually say facebook, just an 'f', and twitter.

What has any of these sites got to do with leaving a comment on your blog? Why should I be forced to have an account with any of these brands? Would you be annoyed if an important but totally unrelated site (like your bank) required you to sign up with Facebook just to login? And what if facebook was blocked at work so you couldn't sign in.

This brand-centric identity parade just complicates sites with endless buttons, confuses users with brands they don't know and gives power to corporations we *really* shouldn't be trusting to hold the keys to the web.

Addendum:
"Post comment to Facebook". I think I'm going to explode; stop the Earth I want to get off. Why the crap is that there? Why would I even care. Do you even care about the experience people have on your site? What junk, I can't believe it.

Adriaan Bloem said...

Lars, with your last comment about release cycles I think you're on to the bigger problem here (if we look at this from the perspective of an enterprise trying to manage content, i.e. in a CMS.) These developments are moving so fast that if you want to hop on, you'll need to have support in your system that quickly adapts to new networks, standards, and semi-standard APIs. The Next Big Thing is already happening without us realizing it yet, what's more... the Next Next Big Thing is probably already starting to happen, too. If you spend six months debating whether to integrate with FB Connect, then six months developing the modules for it, then another six months for the first implementation to go live... the whole issue of this one proprietary standard, or FB lock-in, will already be moot.

As the "single source push" model of publishing is becoming less relevant, enterprises will need to decide whether they want to continue push out their content via their own site, whether to embrace multiple channels, and whether to go bi-directional and engage in conversation or monitor (via analytics, or sentiment analysis). Probably, all of those, which means a lot of enterprises will have to deal with spinning out of control of governance, retention, compliance, or worse -- loss of influence -- if they don't think through how they're going to deal with this brave new world.

This also means enterprises will need to keep themselves educated (knowledge is increasingly rapidly aging in this field, as well) and pro-active. The old days of pushing out a static website as if you were sending a book to the printers are long gone. Enterprises will have to be agile in their strategies, which means their tools will need to be able to cope with this, as well.

So rather than the question whether or not to integrate Facebook Connect, the question is: how do you deal with new channels that aren't just unilateral, but also bidirectional or even omnidirectional, *in general*? Because you can't really predict what you'd want to integrate with next year. (I appreciate Owyang's attempts to predict, but he isn't Hari Seldon enough to give advance warning for something that takes a year to develop.) The final API to API connecting interface should be easy enough to build to be agile.

Social networks realize this, and having an API that allows third parties to quickly whip up tools to connect to them is starting to become a requirement for them to have any success. (Google knows this all too well, as they show with Wave.) A CMS needs a similarly agile API, but it also needs core support for the changing publishing models to make this manageable (if only in the UI.)

So sorry for rambling on like this (maybe I'll try to structure this into a more coherent blog post myself some time), but I suppose the gist is... the problem isn't one specific (Facebook) API. It's API-to-API, and more importantly: what are you going to communicate through those APIs, and how are you going to manage that?

API-to-API is a good term. I have a slide deck on my disk that discusses Multi-Domain-Publishing, which I see as an important part of the future of web content management: instead of dealing with more or less homogenous systems where an authoring instance is replicating content to a publishing instance we will replicate content to multiple, heterogenous endpoints, some of them at Google and Facebook, but the majority will be in the long tail - and this is what will make the pendulum swing back to open APIs and transparency: people see the world outside the walled garden and neither vendors, nor customers nor integrators can bear the cost of dealing with 100 Mini-Facebooks, each hedging a walled garden of its own.

As for the API-to-API meta interface, it looks like REST is the only possible way to scale to this scenario, with all the familiar implications: proxies, browser and crawlers will help people getting their content out and getting feedback and comments back.

I really like this vision of P2P applied to content. Already rapidly drafted some comments about it in a blog post recently (http://stephanecroisier.jahia.com/could-the-jcr-be-used-as-a-data-redundancy-me). Similar to you, no time to write more. But this idea of content federation is becoming hot. Especially from the introduction of Google Wave and the rise of Cloud Computing. But compared to Wave, the CMS industry would need something more generic (ability to manage various domain models) and something more replicated (I should really take the time to digg into the wave federation protocol butI think there is no notion of content replication at this stage).

+1 for this vision. But it risks to take some time before wide adoption ;-)

I’m getting software