Facebook: Opening Up, But on Its Own Terms

Last week we began talking with a independent programmer who ran into a bit of trouble with Facebook over a snippet of code he developed and published that allowed users to update their Facebook status without visiting the site.

Christian Flickinger, who runs the blog Technologist for Hire, posted some PHP code here last April that took advantage of Facebook’s mobile service to perform this simple task. While Facebook offers an RSS feed to export status updates, unlike Twitter it fails to provide a way to import status updates. Christian’s code was meant to fix this shortcoming and consequently help others innovate with the way Facebook status updates are handled. He did not use the code to create a website for updating Facebook statuses; he simply made it available for others to modify or run as is on their own servers.

One such way to use Christian’s code was to incorporate it into a program that takes status updates and pushes them out to multiple status handlers such as Facebook, Twitter, Skype, Adium, and Quicksilver. Another use could be to take information from a music player, instant messaging program, or blogging platform and automatically make Facebook status updates from any activity (such as newly played songs, away messages, or post headlines). After publishing the code, Christian indeed found that several other developers used his code to create programs around the idea of “federated status”.

This past Thursday, however, Christian received an email from a Facebook engineer that requested he take down the code from his blog. While recognizing that Christian was simply trying to provide something useful, the engineer insisted that the code was, and had always been, against Facebook’s terms of service (see “User Conduct” section, bullet #3). As a way of explanation, he suggested that allowing people to automate against Facebook from outside of the site would create a “slippery slope”. The engineer backed up his request by insinuating that he would disable Christian’s Facebook account and/or take legal action if he refused to remove the code.

After Christian stood by his post, Facebook demonstrated on September 4th that it wasn’t bluffing and shut down his account. Christian soon realized that Facebook meant more to him than fighting this out and took down the code; Facebook has since reactivated his account. Several others who had used his code also caved and took down their enhancements.

While Facebook certainly has the right to contact users about violations of their terms of service, I must ask myself “what is Facebook so worried about?”. The company has made great strides in opening up the network with the developer platform, data feeds, and people search. These developments suggest that Facebook wants to make the components of the Social Graph available for wider consumption and utilization.

And yet, it has quite aggressively quelled certain developers that have built Facebook-integrated services. Last fall, the same Facebook engineer involved in this case sent the creator of UnFaced, a compatibility calculator, a similar cease and desist request. Facebook declined to provide a substantive reason for their actions in either of these cases.

Changes to Facebook’s terms of service over the last half year may also suggest that the company has become increasingly cautious about how and when they open things up. Their terms currently prohibit the “use [of] automated scripts to collect information from or otherwise interact with the Service or the Site.” However, archives show that this line was added sometime after February 10, 2007. So, instead of slackening their policies for independent developers, they seem to be tightening them.

What do you think? Was Facebook overbearing or reasonable in the way it handled Christian’s code? Generally speaking, is Facebook “developer-friendly”? If you have developed for Facebook, please share your experiences below.