I think Facebook's launch of the F8 application platform was a great move. It created a community of developers that will do the much of the work of making Facebook more compelling than the rest of the social networking sites.
But I think there are three things I would do right now to keep the momentum going and ensure that Facebook continues to be relevant.
Update 09/17/07: Looks like they were listening to me (hah!) - Facebook, Accel, and some of the Facebook founders announced a grant program (the fbFund) to fund businesses being built on the Facebook platform.
1. Engage Your Developer Community More Substantively, Directly, and Transparently
The developer community will grow Facebook's relevance - so Facebook should be doing everything possible to support their innovative activities.
This means treating them not as "arm's length" third parties, but as true development partners whose needs really have to be understood and met. A great example of this is the state of documentation for the platform. Its very hard to get started now - some of the very basic information that any would need to start understanding how F8 works was written by me on the developer wiki! I wrote an ascii-art diagram that depicts the architecture of a typical "Facebook application". I had to construct this solely from talking with other developers in IRC. The wiki is a great start, and the documentation on the web is useful, but it woefully inadequate in describing some of the basics of what a Facebook application is, and how it interacts with the Facebook site.
While the blog does help in communicating upcoming changes, there have been some recent hiccups which illustrate the need for a more active, and transparent communication channel to developers. Developers should be treated like business partners for whom downtime and surprise platform changes cost real money.
Facebook should be doing the following:
- Improve developer documentation immediately.There needs to be a whole layer of documentation that defines what an application is, what the model for an application is (think of a component interaction diagram), and a discussion of security and privacy assumptions and mechanisms.
- Provide better ways to test & debug applications - currently, to develop a multi-user application, a developer has to either create dummy accounts, or "borrow" accounts from friends, both of which are against the Terms of Service, as I understand it. It would be nice if for each application, a developer were instantly given 5 or 6 "test accounts" associated with that application whose functionality was limited to testing. Also, it would be nice if there were a way to test applications on a "private testbed" instance of FB so that tests could be done on pre-release code without showing it off the world while testing!!
- Perform maintenance and platform changes during scheduled windows of time that are advertised at least a week in advance. Its very painful to make plans to demo an FB app only to learn that changes in the FB platform are going to be rolled out the night before.
- Be 100% transparent about system failures, downtime, etc. Linden Labs does a great job of this with Second Life - you always know when something is down and what they are doing to fix it.
- Embrace developer communication channels that are outside facebook, especially the Freenode #facebook IRC channel. Log that channel, use it to generate FAQ questions and answers.
- Have your developers, or someone who is explicitly responsible for supporting the developer community hang out on the IRC channel and in other venues as much as is possible (make it part of their job description). Have a bigger presence in community events like BarCamps, SuperHappyDevHouse, etc..
2. Actively Reach Out to Communities of Interest to Make Them Communities of Users
There are a lot of communities of interest (such as grassroots political organizations, community organizations, and school groups (PTAs, etc)) that would thrive on Facebook, but are simply not aware of the potential or do not understand the capabilities of applications built on the facebook social graph.
Facebook should find people in those communities who have an interest in technology and actively support them by doing the following:
- Create a forum for bringing developers and communities of interest together. This can be a something as simple as an actively shepherded FB group whose signal to noise ratio is managed well.
- Hire evangelists who have a passion for these communities to do outreach and bring them in. These evangelists should know these communities and have credibility there, but should also understand what the platform is capable of.
- Fund development efforts to create key applications (or "application templates") to support important user communities. For example, fund developers to create an application to support grassroots political campaign efforts. Such an development effort, executed properly, would then make it a "no brainer" for these grassroots groups to recruit new users who would likely be "sticky" FB users because of their experience with a high quality Facebook application.
3. Open Protocols, Open Data Formats, Break the Silos
This is perhaps the most important one. Facebook is the center of the social networking universe, for the time being. It is in a unique position to shape the future of social networking applications. It has the opportunity to make social networks truly open and interoperable by working with existing open standards efforts like OpenID, OAuth,and the efforts around Portable Social Networks. But why would Facebook do this?
- These open standards are being developed to provide a better experience for the user (google "user-centric identity" for an idea of what this means). Better experience means happier users. Happier users mean less churn and more user growth.
- Innovation blooms when innovation isn't subject to centralized control or access. When I build an application for Facebook, I love the fact that there's a built in network of users, but I *hate* the fact that if the users don't like Facebook, or Facebook decides to break my application, I lose my users. Make Facebook an attractive platform to build applications on, but as an application developer, don't make me choose between Facebook or non-Facebook users. Use open standards so I can do both. Sure, make it to make the Facebook experience superior for my users (or easier for me to develop), but don't make me choose either-or.
- There's a proven record of consumer Internet companies succeeding wildly when explicitly NOT locking-in their users and developer communities. One could argue, for example, that Google's email and gtalk are so popular because they interoperate very well with every other XMPP and Email service out there. Google retains and grows its userbase through great user experience and convenience, not through lock-in.
- Because you have no lock-in (except for user loyalty), innovation happens in the long tail developer community, providing a laboratory of innovation that Facebook itself may not have the ability to create. This community of innovation could make everyone's offerings better and by creating an active market of ideas in the social networking space. This is essentially the idea that "innovation happens elsewhere".
- While recognizing Facebook's unique position as the "800 lb gorilla", the long tail of the innovation community would act as check and balance against the threat of Facebook dominance, thus giving Facebook more credibility as a platform. Open standards would make the switching and interoperability costs relatively low for users. This would BENEFIT Facebook by giving legitimacy as a platform that must act within certain bounds of reasonable behavior, as judged by the community of innovators and users. In short, Facebook could say "you can build on our platform knowing that we'll treat developers and users right because if we don't we know they have options".
Facebook has a really special opportunity here to do things right - I'm interested in hearing what Facebook people have to say... please find me on Freenode IRC as GabeW or on email.