Twitter, Facebook, and the unselfish API

Bernard Lunn’s ReadWriteWeb piece about the reverse network effect, writes that one of the ways that social networking services can wear out their welcome is by making their user base feel exploited. Intrusive ads, aggressive marketing, or onerous terms of service can create dissatisfaction and eventual exodus. The RWW article has the end user base of the service in mind, but I suspect the same dynamic pertains to the developer community. With that lens, it’s interesting to consider the very different ways that Twitter and Facebook handle APIs and integration.

Twitter’s API is unselfish. Using the straightforward REST API, developers can and do write clients, search tools, mapping tools, recommendation tools, analytics, personal organizing – a wide range of extensions. Twitter doesn’t do anything to constrain developers other than a rate limit. The lightest weight sort of integration is RSS, and Twitter generates RSS feeds for queries and streams, making it trivially easy to disseminate data. The availability of applications helps build the Twitter user base because they make Twitter more useful. Twitter’s business model is up in the air; but whether it moves toward paid accounts for power users, corporate users, advertising, there will continue to be plenty of room for complementary apps.

Facebook’s API is build to serve Facebook more than developers. The original API constrained developers to exposing a limited user interface within Facebook’s strict design. The functionality encouraged the creation of apps that expanded the Facebook user base because users were encouraged to spam their friends. Given the limits of Facebook, applications tended to be shallow. The most successful app developers needed to relentlessly focus on novelty because users would get bored with yesterday’s toy. Still, application developers put up with the limits because Facebook gave them access to oodles of users.

Then, with the move toward the Twitter-style user interface and the strategic shift toward Facebook Connect, Facebook hid and de-emphasized apps in the user interface. App providers, and users who were starting to like using Facebook for richer engagement were short on luck. Facebook Connect looks on the surface like it might provide developers with more breathing room. A developer can build a fully fledged application or community site, and take advantage of Facebook Connect, which lets users to bring their social network to the site.

But this is a deal with the devil. The problem is that when sites use Facebook Connect, they have minimal connection to their user base. An an application or community site wants to create the policies whereby the site communicates to the community, and the community talks to each other. With Facebook Connect, those rules belong to FaceBook. What’s worse, the member database is critical for a site to make money through ads, sales, donations, or services. With FB Connect, all your member database are belong to them. Another sign of Facebook’s weakness at supporting external sites can be seen in the lack of RSS feeds for public data like Pages. Facebook RSS is designed as a black hole. Content can be sucked into Facebook, and can’t get out. Facebook’s goal with APIs and integration is self-interested. They want to own the social graph, the user data, and the content; developers are sharecroppers on Facebook’s land.

I can see why a short-lived temporary site might want to use FB connect as a shortcut. For an established site, the viral aspect of Facebook may make Connect worth a try. But for a site that wants to build community and business value over the long haul, FB Connect is parasitic. Google’s Friend Connect has some less toxic properties – they are using standards for single signon, portable contacts, and portable lifestream data. The problem with Friend Connect is that doesn’t really have a social network. When there is a more open method with good social properties, applications and communities will go there.

Twitter’s unselfish API strategy will enable it to grow it’s community and provide win/win opportunities for developers. Facebook’s selfish strategy looks on the surface like it will help Facebook’s business success, but it risks running aground on RWW’s exploitatin principle – exploit your developers and they will leave when they get a chance.