Citizen-centric Web, DiSo, Life online, Open source, Philosophy, The Web Arts, Web building

The battle for the future of the social web

When I was younger, I used to bring over my Super Nintendo games to my friends’ houses and we’d play for hours… that is, if they had an SNES console. If, for some reason, my friend had a Sega system, my games were useless and we had to play something like Sewer Shark. Inevitably less fun was had.

What us kids didn’t know at the time was that we were suffering from a platform war, that manifested, more or less, in the form of a standards war for the domination of the post-Atari video game market. We certainly didn’t get why Nintendo games didn’t work on Sega systems, they just didn’t, and so we coped, mostly by not going over to the kid’s house who had Sega. No doubt, friendships were made — and destroyed — on the basis of which console you had, and on how many games you had for the preferred platform. Indeed, the kids with the richest parents got a pass, since they simply had every known system and could play anyone’s games, making them by default, super popular (in other words, it was good to be able to afford to ignore the standards war altogether).

Fast-forward 10 years and we’re on the cusp of a new standards war, where the players and stakes have changed considerably but the nature of warfare has remained much the same as Hal R. Varian and Carl Shapiro described in Information Rules in 1999. But the casualties, as before, will likely be the consumers, customers and patrons of the technologies in question. So, while we can learn much from history about how to fight the war, I think that, for the sake of the web and for web citizens generally, this coming war can be avoided, and that, perhaps, it should be.

What I’m talking about, of course, is the seemingly inevitable duopoly between Google’s OpenSocial and Facebook’s F8 platforms. Patrick Chanezon, Google’s API evangelist, even went so far to claim that Google is following Chapter 8 and Facebook is following Chapter 9 of Information Rules, suggesting that Google is taking a “Cooperation and Compatibility” approach, while Facebook is seeking to incite a full-fledged standards war:

Twitter / chanezon: @factoryjoe @kevinmarks yes...

…having read these two chapters now, I’m not sure things are so cut and dry, and it’s worth taking the time to consider how the rhetoric on both sides maps to the various tactics and strategies outlined in the book (co-authored, mind you, by Google’s Chief Economist).

But look, I’m not going to bore you with all the details. I am, however, going try to put this current situation into some perspective, and suggest a way of moving forward.

Of the browser wars of 1996, Business Week wrote (talking about Bill Clinton):

That the contest caught even the President’s eye underscores just how seminal it is: This battle is for nothing less than the soul of the Internet.

Thus if the spoils of desktop browser wars was the soul of the Internet, then the coming war will be for the soft, pliant heart of the social web; it all comes down to distribution and sticky eyeballs synapsed to clicky-clicky fingers over which advertisers and their kin salivate and jerk off. No kidding.

Back in ’96 (when I was 15), you “provided” distribution by selling certain default real estate in your browser (how do you think Flock keeps managing to raise more money?). This is one reason why the Netscape vs. Internet Explorer war mattered so much — and why the Justice Department intervention decoupling IE from the operating system was so critical. It’s also why Mozilla has been able to amass a warchest (on the order of $50M) by keeping Google in the search “pole position” (and it’s also one compelling reason why Yahoo! might acquire an app like Inquisitor). Regardless, back in Web 1.0, browser distribution models were where it was at. But now that we’ve achieved cross-platform web standards support, generic feature parity (i.e. tabs, popup blocking), have reduced switching costs to nil, and, most importantly, brought about a generation of web surfers that connect to the web through all kinds of systems other than their own, the browser has been summarily reduced to a means to an end — an end which is commonly and increasingly some kind of social network.

Therefore, the endgame here is in setting the priorities that will be represented, through architecture and application design, and running code, in the social platform(s) of the [near] future, and in who can sell the most convincing version of the story that their platform will provide the greatest ROI for the least investment, given current sunk costs, and access to the widest number of [qualified] individuals, networks and relationships.

Look at how Kevin Marks (a good friend of mine) describes the opportunity for :

For OpenSocial application developers, this gives you a whole new audience for your apps, beyond the hundreds of millions of users on existing social networks that support OpenSocial.

Then consider what Patrick Chanezon (whom I recently met) said, when interviewed by none-other-than Inside Facebook (emphasis indicates interviewer question):

Patrick, what new trends stand out to you at this juncture for OpenSocial?

We’re still very early. Now that OpenSocial is reaching 200 million users, we’re starting to see a lot more people ask how they can be involved.

Meanwhile, Facebook promises much the same:

Mass Distribution

Yet, unlike Google, which has focused on an almost exclusively developer-centric message to buffer their lack of clarity around user privacy, Facebook has revealed its conflicts of intention between serving its advertisers while awkwardly protecting the interests of its users, regularly alternating press releases about advertiser benefits followed by improved privacy protections. Not that Facebook should have it all figured out, but this waffling only reveals what’s at stake here, and what’s driving the priorities of both platforms — Google has merely drowned out their plans to monetize the OpenSocial platform with developer-friendly messages.

Taking pages literally from Information Rules, both parties are employing preemption and expectation management strategies:

The logic of preemption is straightforward: build an early lead, so positive feedback works for you and against your rival. The same principle applies in markets with strong learning-by-doing: the first firm to gain significant experience will have lower costs and can pull even farther ahead. Either way, the trick is to exploit positive feedback. …

One way to preempt is simply to be first to market. Product development and design skills can be critical to gaining a first-mover advantage. But watch out: early introduction can also entail compromises in quality and a greater risk of bugs, either of which can doom your product.

Remind you of the notoriously capricious (but first-to-market) Facebook platform?

Meanwhile, on expectations management:

…Vaporware is a classic tactic aimed at influencing expectations: announce an upcoming product so as to freeze your rival’s sales. …

The most direct way to manage expectations is by assembling allies and making grand claims about your product’s current or future popularity. Sun has been highly visible in gathering allies in support of Java, including taking out full-page advertisements listing the companies in the Java coalition, showing how important expectations management is in markets with strong network externalities…

Take a look at Google’s OpenSocial presentations: fraught with logos and partner names (see slide 1 and slides 1516 for recent examples of this kind of posturing). Classic expectations management.

And so we can see where this is going: companies, groups and individuals wanting to build social applications (and not invest in their own social graph) are essentially beholden to the platform decisions of Google and Facebook. If the two parties can’t figure out how to pick up the phone and talk, we’re going to have two competing platforms, both jockeying for developer attention, and forcing competition for the market, rather than competing within it. With everything that I know and have seen on the web (and while competition is typically good) this kind of fragmentation, generally, seems bad to me, primarily for the customers of these networks, who really don’t (and shouldnt have to) care which standard wins out in the end.

Unfortunately, it comes down to ego. In fact, Information Rules addresses with this kind of situation directly, advising against fragmentation in favor of increasing the size of the overall market:

Before you engage in a standards battle, try to negotiate a truce and form an alliance with your would-be rival. An agreed-upon standard may lead to a far bigger overall market, making for a larger pie that you can split with your partners. Don’t be proud; be prepared to cut a deal even with your most bitter enemy.

Can Google and Facebook come to grips on this? Well, I think they’d better, before Microsoft scoops up Yahoo (which already pledged to support OpenSocial) and makes moves on Facebook. Let’s face it, while it looks like Microsoft is just playing with itself with its Mesh platform, it needs a little soylent juju to get traction and marketshare to advance its ad system (which, by the way, is what powers Facebook ads). If Facebook and Yahoo both support OpenSocial, regardless of what the spec looks like, that’s bad news for lock-in bent Microsoft, and good news for the web.

So call me whacked, but here’s what I think should happen in my next-three-months pipe dream:

  1. Google should reach out to Facebook. And vice-versa. Preferably simultaneously to reduce any unseemly appearance of capitulation. Facebook should realize that fighting a standards war with Google isn’t really going to benefit them long term. Meanwhile, Google should recognize the value that Facebook’s interaction patterns would bring to OpenSocial, along with the value of reducing developer headaches in having to pick between one or other if resources aren’t available to build for both.
  2. Facebook should contribute a specification for handling “dynamic privacy” that promotes the interests of its members (and which should work for individual web citizens at large), beyond the flimsy, misleading and unclear privacy model currently being promoted under the aegis of Friend Connect. Presuming it’s good, adopting Facebook’s “dynamic privacy” spec should be Facebook’s top requirement for agreeing to adopt OpenSocial. (And heck, Facebook ends up looking like a good guy for agreeing to play along while not selling out the interests of its members.)
  3. OpenSocial and the Facebook platform specs and (related IPR) should be assigned to an independent third party foundation, probably other than the OpenSocial Foundation (given its proximity to Google), whose sole obligation would be to steward specifications of the open [social] web.
  4. Develop interoperable standards, formats and protocols so that 1) applications could be run within Facebook, OpenSocial containers, and on any independent website and that 2) data would be accessible from any of these network providers, using a secure model where the owner of said data determines how their data may be used, who may see it and for how long.

It’s not that we’re far off from this reality, but it will require the concerted effort of a few choice and able individuals within these organizations to make this happen. I believe that, with proper perspective, those agents of change who are already active in building out the future platforms of the social web can grasp the seriousness of the situation and, again, informed by history, will ultimately do the right thing, given the possible alternatives. We’ve made too much progress in the past year to let this opportunity slip out of reach owing to the egos or perceived short term economic benefits to be had by competing for dominance of the social web. It is much better for the health of the overall environment and ecosystem for standards to be set web-wide, and for competition to occur within the marketplace.

Moreover, competing for market domination (where there can only be one) like we saw with Sega and Nintendo will primarily harm the customers of social web services. It is therefore my contention (and wish) that competition be focused on providing higher caliber services and products rather than on the length of the tether used to keep people tied to one network. Condensing and combining the OpenSocial and Facebook platform specifications will take work, vision and compromise, but is ultimately the only way we can avoid what would amount to a costly, unnecessary and unfortunate 10 year standards war where no winner would likely ever emerge.

Advertisements
Standard

22 thoughts on “The battle for the future of the social web

  1. Pingback: Plattformkriege < LostFocus

  2. Chris, I agree with the set up but not this conclusion: “competing for market domination (where there can only be one) like we saw with Sega and Nintendo will primarily harm the customers of social web services.”

    First, this isn’t Highlander or the proprietary console/cartridge world. It may well be that there can be more than one. Nobody needs to budget the time and money to stand in line at Toys R Us to move between vendors. Regardless of how data portability turns out, switching is free and geographically universal.

    Second, as a startup guy, I LOVE standards wars between large, nimble companies — especially when a few large, slow companies are looking on with envy desperate to join the race. Consumer confusion is always part of the equation, but you can either choose to be annoyed by it or use it as an opportunity to do a better job marketing to a confused segment or two.

    For Google and Facebook to agree to an applications (or even privacy) standard this early in the process would radically slow platform innovation and stabilize the market in favor of the largest application vendors and the platforms themselves. That would be great for a dozen or so large-ish companies but terrible for everyone else.

  3. dave mcclure says:

    fascinating post chris. I’m skeptical of any likely détente between Facebook & Google, or any similar Come-to-Jesus awakening by Facebook on standards, but regardless I’m not sure that market competition is harming consumers as much as you think. In particular, if ‘playing fair & using standards’ is as unlikely as I believe then perhaps a battle between 2 or more productive & fast-moving titans (& a thousand startups) isn’t always so bad.

    at the very least im glad to see u not frame this as a simplistic “Facebook=evil / Google=good” discussion. both companies are self-interested regardless of their public posturings. tho again, that is perhaps the best of all possble worlds.

    in any case I look forward to reading / hearing more of your thoughts onthe subject. always worth listening to 🙂

    ps – and glad you’re speaking again at Graphing Social Patterns in DC (yes, that’s a shameless plug)

  4. @Scott: Y’know, I feel for that point and find myself on the one hand wanting to support it, and on the other, feel that maybe with greater specificity in this discussion, you might come to agree that, when it comes to protocols like OpenID or OAuth, adoption by Facebook would generally be a good thing (Google already supports them), whereas competition in the platforms themselves, or in building apps for either, is a good thing given the immaturity of the market.

    Maybe a more apt analogy is between Windows, Mac OS X and the flavors of Linux, where, through data interchange formats, you can generally choose the operating system that works best for you without forfeiting your ability to use the output created on the other platforms.

    My concern, however, lies with the momentum that both platforms have right generated now, and how the design of these platforms may only take into consideration the needs of the silos, as opposed to the desires of or benefits to independent services.

    Let me put it another way: HTML may have been designed for documents, but since it didn’t necessarily bake in any assumptions about how it would be used for applications, everyone had an equally hard time grafting the stuff to work in an application-friendly way. 😉 Conversely, “virality” and “distribution” are being baked into the foundation of Google and Facebook’s platforms and I worry that these two competing standards will be the dominant two, and as a result people will invest heavily in creating into their model(s).

    To give my own project a plug, DiSo is intended, I suppose, to be modeled on becoming a “Linux” of social web platforms. What’s driving our priorities are very different from what’s driving either Facebook’s or Google’s… and what it comes down to, which maybe didn’t come out in my post, is a desire for true choice in the marketplace, rather than a kind of “Republican” and “Republican Lite” type of situation.

    @dave: I suppose my thoughts are still early, and ultimately these things are just natural outcomes along the road of technology development. In all that I’ve read about this stuff lately, I just hadn’t seen this kind of perspective presented, and when Patrick mentioned the book, and I did some reading, I realized, “Geez, recent history really has something to teach us about this current situation!”

  5. It seems we are still very early in the game, with less than 2 years of experience with either platform, to try and consolidated. I would like to see more ideas and proposals at this stage, rather than have to compromise so early in the game. An agreement now would make it so much more difficult to be innovative in the space, as the politics of changing a common specification is going to make it extremely slow.

  6. “SNS” console? Wikipedia agrees: it’s SNES (for Super Nintendo Entertainment System)

  7. Amazing post, not only very thoughtful and well researched, but so well written. I’m really very impressed, this ought to be in the “Best of Technology Writing 2008”

  8. Thanks for the post Chris, glad that you liked Hal’s book: studying history is a great way to understand the present and shape the future. I like your perspective about what should be done.

    Like my daughter says in slide 51 of a recent presentation http://www.slideshare.net/chanezon/south-america-open-social-tour-2008/
    “Anyone can be friends”:-)
    I agree that a dynamic privacy API would fill an important gap from a technical point of view.

    The numbers that Jesse Farmer published recently http://20bits.com/2008/05/06/the-state-of-the-facebook-platform/ may help collaboration: positive feedback works both ways, up and down!
    http://www.inforules.com/ft/ft.htm

    And OpenSocket gives developers the option to use OpenSocial on Facebook today http://www.opensocket.org/blog/

    The next 6 months will be very interesting to live!

    P@

  9. Hm…
    1. What competition you are talking about? Between Google and Facebook? It’s David and Goliath, really 😉
    2. Competition by itself is quite beneficial thingie – yes, of course! What a revelation 🙂
    Can’t you stretch your imagination and think of a non-proprietary open standard instead?

  10. @sexySEO yes, that’s the competition. I agree with you on #2, but this fight is only David and Goliath in the way that Google was the “David of Search” in 1999/2000. The dominant player in social applications is already set in stone (assuming that they don’t sell out to an acquirer who screws it up), and it’s the critical fight for #2 that we’re talking about here.

  11. Pingback: Results: Data Portability’s Future — i-penny

  12. Great perspective, Chris – I really hadn’t viewed the whole scenario in this light yet. Much to think about.

    One thing that I’ve hardly seen discussed anywhere, though, is a technical comparison of the platforms. Regardless of what you think about Google, Facebook, the OpenSocial Foundation, etc., both platforms have different architectures that raise big concerns.

    For instance, all of the sites I’ve seen using Google’s new Friend Connect lose all social features when JavaScript is disabled. OpenSocial is heavily reliant on iframe’s and client-side code, raising questions of accessibility, security, and performance. Even if you think Facebook is an evil proprietary walled garden, you have to give them credit for building a platform that tightly integrates into the site via a template structure that’s processed server-side. Usable Facebook applications can be built with their entire frontends free of iframe’s and scripts (or not – iframe’s and scripts aren’t inherently evil, I’m just making a point). For all the “proprietary” talk regarding FBML, the end result is still HTML.

    I see OpenSocial and F8 following two very different paths regarding implementation, and while I respect OpenSocial’s steps to be more “open,” the iframe/script approach gives me great concern. Regardless of whether Facebook and Google work together or a DiSo approach takes over or what, I hope the eventual “winner” is one that takes into account these kind of technical issues – for the good of both developers and users.

  13. The big activity here at the moment is all about gadgets and gadget containers. But what of RESTful APIs? Does *every* site have to follow the Twitter model and create their own?

  14. Create their own RESTful API? yes, they do, though there’s no reason not to clone others’ syntax. And there’s no reason to re-build the metering/security/reporting/metrics infrastructure. Mashery does all that as a service bureau.

  15. About the REST API, there is one that is being defined in OpenSocial. The spec has been proposed in february in the public spec discussion group, and is finalized these days.
    http://code.google.com/apis/opensocial/docs/dataapis.html
    http://groups.google.com/group/opensocial-and-gadgets-spec/msg/87df6973a9f94fe1
    proposed february
    http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/d4eecee18d84eea1/259d9ff6c5e06f38?lnk=gst&q=rest#259d9ff6c5e06f38

  16. Pingback: Marc’s Voice » Blog Archive » June 2nd blogging '08

  17. Pingback: Marc’s Voice » Blog Archive » Live Mesh could be Twitter’s Plan B or we might have to do it ourselves

  18. Pingback: Marc’s Voice » Blog Archive » A reference design for building the Open Mesh

  19. Pingback: Data Portability | Blogs @ Northern Light

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s