The most worthwhile class I ever took was my Economics of Technology course back in the fall of 2003. The whole course involved reading papers about technology strategy and discussing them with smart, engaging people– it was everything a course is supposed to be.
One of the major themes of the course was technology standards– why certain things (e.g., QWERTY keyboards, x86 microprocessors, Microsoft Windows) become standards and other things don’t. In light of Google’s announcement of the Open Social API for connecting social networks with social application developers, and the widely held belief that this heralds a standards war with Facebook for the hearts and minds of social app developers and (by proxy) social network users.
Seriously. Check out Techmeme. People are freaking out. As for me, I feel like I’m looking over at the dudes from uncov, waiting for them to say ‘FAIL‘. (I love that picture. Best fail ever.) But no fail is forthcoming, so I’m going to step in and take a crack at it.
First of all, let me say that open standards (as Open Social purports to be) are generally a good thing. The idea of Open Social is pretty nice– you write your application once against this common API, and then it works with any one of these different social networks. The Open Social API abstracts away the underlying social network, just like HTML and the browser abstract away the operating system, or the Windows API abstracts away the underlying hardware.
The more technically-minded amongst you will have already detected the bullshit lurking in the previous paragraph, since the abstractions I just talked about are, shall we say, leaky. They’re not perfect by any stretch, so developers devote alot of time to handling the different special cases and quirks that arise from slightly different implementations of the same standard interfaces.
Josh’s Corollary To the Law of Leaky Abstractions: The number of leaks in an abstraction is proportional to the implementer’s incentives to go beyond the standard. When the incentives are high enough, the abstraction gets forked.
Simple example of a relatively leak-free abstraction: you sell disk drives for PCs. Microsoft specifies a set of functions your drive needs to perform in order for it to be usable by Windows. You have no incentive to develop any functionality for your disk drives that isn’t completely covered by that standard, since Windows (and by extension, everyone else) won’t be able to use it. It’s a pretty awesome situation for Microsoft, and a pretty crappy situation for you, the disk drive manufacturer.
The opposite case (and a textbook example of the oft-cited Josh’s Corollary to the Law of Leaky Abstractions) is the forking of Unix. Once upon a time, there was this operating system called Unix that was developed at AT&T, and it was good. But then AT&T did something bad to someone or something, and it had to sign an agreement not to sell Unix, and to license the Unix source code to all sorts of acronyms– SGI, IBM, DEC, SCO. Each of these licensees took Unix and made it their own– creating their own version that implemented the original Unix plus some other stuff, which had the net effect of making all of the Unices incompatible with each other. You see, they were all competing against each other for the same customers, and so they had very strong incentives to take the “open” Unix standard and make it very much their own. And while they were fighting with each other and driving Unix application developers nuts (arrgh!), Microsoft swept in with their fixed API that ran on cheap hardware and took all of the developers and (by proxy) all of the users.
I don’t think it’s difficult to tell which of these two scenarios more closely resembles the dynamics in Open Social API vs. Facebook. In my humble and undeniably correct opinion, the amount of time it will take for one of the original implementers to fork the Open Social API can be clocked with an egg timer.
This has been a longish post, so I’m going to wrap it up now. In Part Two, I’m going to talk about how Open Social is more about Google trying to get companies to sign up to implement the API than it is about getting developers to create applications for it– in my mind, Google is even more interested in consuming this data than they are in providing it.
Labels: social networks, facebook, withdrawl
[ 0 comments ]
Leave a Reply