On May 24, Facebook launched the newest version of the Facebook Platform, a set of application programming interfaces (APIs) and services that allow outside developers to inject new features and content into the Facebook user experience.
In this post, I provide an overview and analysis of the Facebook Plaform and what we have learned about it in the three weeks since it launched.
To start, my personal opinion is that the new Facebook Platform is a dramatic leap forward for the Internet industry.
Here's why:
Veterans of the software industry have, hardcoded into their DNA, the assumption that in any fight between a platform and an application, the platform will always win.
Definitionally, a “platform” is a system that can be reprogrammed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform's original developers could not have possibly contemplated, much less had time to accommodate.
In contrast, an “application” is a system that cannot be reprogrammed by outside developers. It is a closed environment that does whatever its original developers intended it to do, and nothing more.
The classic example of an application being vanquished by a platform was the Wang word processor versus Microsoft DOS-based personal computers.
Wang word processors — the application, in this case — were highly evolved, fantastically successful dedicated word processing systems that owned their market, until the general-purpose PC came along. While the PC at first was inferior at word processing, within a few years of its launch the fact that outside developers had built thousands of applications for it — like spreadsheets — that closed Wang word processors could not match, coupled with steadily improving PC-based word processing software like Wordstar, had all but killed the Wang word processor. Wang — one of the most succcessful technology companies of the 1970's — went bankrupt not long after.
This is a story whose moral has historically not been embraced by the web industry to nearly the extent one would have thought.
The web, after all, vanquished proprietary online services like America Online, Prodigy, and Compuserve — the so-called “walled gardens” — in large part because the web is a platform and the walled gardens were not. No single closed service, no matter how good, and no matter how big, could compete with the diversity of thousands and then millions of web sites that were customized to every conceivable user interest and need.
Yet most major web busineses have not themselves sought to become platforms.
Sure, some have released APIs — some have even released very sophisticated APIs — but such APIs have mostly been for interacting with a web system from the outside. Those APIs have been a far cry from the programmability and customizability enabled by a true platform in the sense that the software industry has come to understand it.
Instead, most major web businesses have sailed along without the added lift from platform-style programmability that they could have had at any point.
Until now.
In a nutshell, the Facebook API enables outside web developers to inject new features and content into the Facebook environment.
After signing up for a developer account on Facebook, the developer writes a web application (in the simplest case, a piece of web content; in the most advanced case, a full fledge web application with deep functionality) and hosts it on her own servers. The developer then registers her application with Facebook, and then users can add that application to their Facebook user experience in several different ways, including within their Facebook profile pages.
Viewed simply, this is a variant on the “embedding” phenomenon that swept MySpace over the last two years, and which Facebook prohibited.
However, what Facebook is now doing is a lot more sophisticated than simply MySpace-style embedding: Facebook is providing a full suite of APIs — including a network protocol, a database query language, and a text markup language — that allow third party applications to integrate tightly with the Facebook user experience and database of user and activity information.
And then, on top of that, Facebook is providing a highly viral distribution engine for applications that plug into its platform. As a user, you get notified when your friends start using an application; you can then start using that same application with one click. At which point, all of your friends become aware that you have started using that application, and the cycle continues. The result is that a successful application on Facebook can grow to a million users or more within a couple of weeks of creation.
Finally, Facebook is promising economic freedom — third-party applications can run ads and sell goods and services to their hearts' content.
Metaphorically, Facebook is providing the ease and user attraction of MySpace-style embedding, coupled with the kind of integration you see with Firefox extensions, plus the added rocket fuel of automated viral distribution to a huge number of potential users, and the prospect of keeping 100% of any revenue your application can generate.
The leadership that the Facebook team is showing here rivals anything that the large and established software and web companies have done in this decade.
You may also notice the irony of Facebook leapfrogging MySpace on embedding at the same time that MySpace seems to be getting substantially more restrictive, in some cases even shutting down third-party widgets.
Let's look at some of the key aspects of the Facebook Platform in more detail.
First, perhaps the most architecturally interesting aspect of the Facebook platform is the fact that everything routes through Facebook's servers.
This is known as a “proxy” model — you interact with a third-party Facebook application by interacting with Facebook's servers which turn interact with the application's servers.
There are very sharp pros and cons to this approach, contrasted with the MySpace model where third-party content is pulled directly from third-party servers.
Pros:
Facebook retains much tighter control of the overall user experience. Applications must conform to Facebook guidelines for appearance and content or they are disallowed.
Facebook can provide third-party pages with integral access to Facebook user and activity information — the application can easily be aware of who your Facebook friends are, for example. This allows the applications to be considerably more powerful in the context of a social network than a simple piece of embedded content.
Facebook can cache static content such as images and videos and thereby serve them up faster, improving the overall user experience.
Cons:
Facebook retains much tighter control of the overall user experience. Applications must conform to Facebook guidelines for appearance and content or they are disallowed. Yes, this is also listed above under “Pros”.
Performance will generall be slower than a non-proxy model. There are additional network hops for each access of a third-party application, which causes additional latency. Plus, Facebook's servers do a lot of processing of the third-party content that they are passing back and forth: they essentially rewrite every page on the fly to implement the added features (e.g. FBML) and restrictions (e.g. no Javascript; div's are rewritten) that they provide. This processing inevitably takes time.
On balance, of course, this is a fine set of tradeoffs that accommodate Facebook's dual goals of opening up their environment but in carefully controlled ways, and may well serve as a powerful precedent for how other web businesses will open themselves in the future.
Second, Facebook has really thought through the API suite it provides to developers.
You get a REST web services API that lets your application programmatically interact with Facebook's systems and data in very interesting ways. Developers who understand web services can pick it up in about five minutes.
You get a database query language called FQL — a variant of SQL — that lets you interact with Facebook's databases directly. Developers who are experienced with relational databases and SQL will be right at home.
And, you get a text markup language called FBML — a variant of HTML. FBML strips out some features of HTML, such as Javascript, and adds a new set of features that enable a third-party application page to access Facebook features, data, and look and feel elements in a variety of interesting ways. Anyone who knows HTML can take advantage of it immediately.
This is a very sophisticated yet easy to adopt suite of APIs for a brand new platform, and demonstrates real seriousness of purpose.
Third, there are three very powerful potential aspects of being a platform in the web era that Facebook does not embrace.
The first is that Facebook itself is not reprogrammable — Facebook's own code and functionality remains closed and proprietary. You can layer new code and functionality on top of what Facebook's own programmers have built, but you cannot change the Facebook system itself at any level.
The second is that all third-party code that uses the Facebook APIs has to run on third-party servers — servers that you, as the developer provide. On the one hand, this is obviously fair and reasonable, given the value that Facebook developers are getting. On the other hand, this is a much higher hurdle for development than if code could be uploaded and run directly within the Facebook environment — on the Facebook servers.
The third is that you cannot create your own world — your own social network — using the Facebook platform. You cannot build another Facebook with it.
I won't dwell on these three factors too much right now. Those of you familiar with Ning may, however, expect me to revisit them in the future, and I will :-).
These factors are, however, very reflective of the fact that while the Facebook Platform gives developers a lot of capabilities that they never had before, and access to a huge base of enthusiastic users, as a Facebook developer you're very much living in Facebook's world — you're not creating your own world. And you have to be serious enough about living in that world that you are willing to hit the fairly high barrier of being willing to run your own servers and infrastructure for any applications you build.
Which takes us to…
Fourth, and perhaps most significantly, when your application takes off on Facebook, you are very happy because you have lots of users, and you are very sad because your servers blow up.
Let me explain.
I already described Facebook's viral distribution mechanism by which users became instantly aware of which applications their friends are using, can with one click start using those applications, and automatically spread them to their friends.
This is happening in an environment with 24 million active users — active users defined as users active on the site in the last 30 days. 50% of active users return to the site daily. 100,000 new users join per day. 45 billion page views per month and growing. 50 million users, and a lot more page views, predicted by the end of 2007.
An application that takes off on Facebook is very quickly adopted by hundreds of thousands, and then millions — in days! — and then ultimately tens of millions of users.
Unless you're already operating your own systems at Facebook levels of scale, your servers will promptly explode from all the traffic and you will shortly be sending out an email like this.
ILike was the first third-party application to get serious lift-off on Facebook. Quoting from ILike's blog shortly after their launch:
In our first 20 hours of opening doors we had 50,000 users sign up, and it is only accelerating. (10,000 users joined in the first 12 hrs. 10,000 more users in the next 3 hrs. 30,000 more users in the next 5 hrs!!)
We started the system not knowing what to expect, with only 2 servers, but ready with backup. Facebook's rabid userbase chewed up our 2 servers almost instantly. We doubled our capacity to catch up. And then we doubled it again. And again. And again. Oh crap - we ran out of servers!! Although iLike.com has a very healthy level of Web traffic, and even though about half of all the servers in our datacenter were sitting unused, idle, as backup capacity, we are now completely maxed out.
We just emailed everybody we know across over a dozen Bay Area startups, corporations, and venture firms in a desperate plea to find spare servers so we can triple our capacity for the continued onslaught. Tomorrow we are picking up over 100 servers from different companies to have them installed just to handle the weekend's traffic. (For those who responded to our late night pleas, thank you!)
Yesterday, about two weeks later, ILike announced that they have passed 3 million users on Facebook and are still growing — at a rate of 300,000 users per day.
They didn't say how many servers they're running, but if you do the math, it has to be in the hundreds and heading into the thousands.
Translation: unless you already have, or are prepared to quickly procure, a 100-500+ server infrastructure and everything associated with it — networking gear, storage gear, ISP interconnetions, monitoring systems, firewalls, load balancers, provisioning systems, etc. — and a killer operations team, launching a successful Facebook application may well be a self-defeating proposition.
This is a “success kills” scenario — the good news is you're successful, the bad news is you're flat on your back from what amounts to a self-inflicted denial of service attack, unless you have the money and time and knowledge to tackle the resulting scale challenges.
Will every Facebook application go through this?
No, of course not. The ones that nobody uses will not have this problem.
But the successful ones all will.
The implication is, in my view, quite clear — the Facebook Platform is primarily for use by either big companies, or venture-backed startups with the funding and capability to handle the slightly insane scale requirements. Individual developers are going to have a very hard time taking advantage of it in useful ways.
Fifth, there's the fascinating issue of the Facebook application directory — the page from which users can pick which applications they want to use.
When you develop a new Facebook application, you submit it to the directory and someone at Facebook Inc. approves it — or not.
If your application is not approved for any reason — or if it's just taking too long — you apparently have the option of letting your application go out “underground”.
This means that you need to start your application's proliferation some other way than listing it in the directory — by promoting it somewhere else on the web, or getting your friends to use it.
But then it can apparently proliferate virally across Facebook just like an approved application.
There is already long list of underground apps that you can use — and proliferate.
It will be fascinating to see how Facebook deals with this — will they embrace underground apps, or move to shut them down?
The answer will go a long way towards understanding the true level of freedom that developers have on the Facebook Platform.
In closing:
Congratulations to the Facebook team — big time! — for an amazing leap forward in what the Internet can do for real users and for opening up whole new vistas of opportunities for third-party developers.
This is an amazing achievement — one of the most significant milestones in the technology industry in this decade.
Clarifications and expansions:
In conversations with the folks at Facebook, there are a few clarifications and expansions I'd like to note:
First, my statement that “applications must conform to Facebook guidelines for appearance and content or they are disallowed” is partially but not entirely true. Boxes that contain content from an application on a user's Facebook profile page must be rendered via FBML and have tight controls over what can be included, particularly the no-Javascript limitation. On the other hand, so-called “canvas” pages — the pages dedicated completely to a specific application, and accessible via the left-hand-side app navigation area, can be rendered either via FBML (which is restrictive), an iframe that can include arbitrary content, or a combination of the two. From an iframe you do pretty much whatever you want, but you don't get the FBML features.
Note that you are incented to use FBML because that's the easiest way to achieve integration between your application and Facebook — e.g. to let your app have access to information about the user and her friends. FBML is clearly a good thing; it's just that when you're using it, you can't do certain other things that you're used to. And, as noted, you are required to use it for content that shows up on users' profile pages.
Second, my point that “success kills” — that a successful, widely used application will require a large number of servers to run, at best, and will fall over and die, at worst — is true, but the Facebook folks point out that as an app developer you have a lot of control over how fast your application grows. You don't have to light up all the viral spread features all at once, for example.
I would counter-argue that deliberately tamping down the growth rate doesn't do you any favors either — then you don't get widely used, which for most apps is the whole reason to exist.
My larger point is that if your app succeeds on Facebook, expect to have to do a lot of heavy lifting on your back end and to spend a lot of money on hardware and bandwidth — just like if you built a web app that succeeded outside Facebook, of course.
Some commenters have proposed that Amazon's EC2 service would be a way to easily scale a Facebook app (or a non-Facebook web app). I think EC2 is a great service and have no desire to say anything negative about it. So I will just say two things: it isn't as easy as that, and EC2 is not free either. Bonus points to commenters who want to go into more detail on these topics than I have here!
Plenty of interest this week in 