Results tagged “facebook”

Update: We've got some results already! Joseph Scott at Automattic mentions in the comments that he's added RSD support for the Twitter API to WordPress.com. I should also make clear that I am very confident that we'll be building apps on top of this API at Expert Labs, so insofar as I'm the Director of the labs, I've got a vested interest in seeing efforts around an open API succeed.

Twitter's API has spawned over 50,000 applications that connect to it, taking the promise of fertile APIs we first saw with Flickr half a decade ago and bringing it to new heights. Now, the first meaningful efforts to support Twitter's API on other services mark the maturation of the API as a de facto industry standard and herald the end of its period of rapid fundamental iteration.

From here, we're going to see a flourishing of support for the Twitter API across the web, meaning that the Twitter API is finished. Not kaput, complete. If two companies with a significant number of users that share no investors or board members both support a common API, we can say that the API has reached Version 1.0 and is safe to base your work on. So now what?

How We Got Here

Like a lot of folks, I've been thinking out loud and pondering the future of Twitter and open web APIs pretty much all year. Some key ideas have bubbled up:

The Pushbutton Web:

[A]ny site or application can deliver realtime messages to a web-scale audience, using free and open technologies at low cost and without relying on any single company like Twitter or Facebook.

The Web Way vs. The Wave Way

• Upgrades to the web are incremental.
• Understanding new tech needs to be a weekend-sized problem.
• There has to be value before everybody has upgraded.
• You have to be able to understand and explain it.

Those posts from this summer show that the ideas behind the Twitter API's "overnight" ubiquity have been kicking around in developer circles for months, if not more than a year. Finally, though, we have shipping examples of broad adoption of an API that's lightweight and suitable for today's most interesting applications. It's not just that Twitter's realtime, though of course that is compelling, but also that these APIs are simple enough for weekend hackers to build interesting projects on, and that they're easy to implement even on mobile devices and in almost any programming language.

So, today, we have support for the Twitter API from Twitter (of course), WordPress and Tumblr. I know I saw folks working on this for TypePad's free service when I was at Six Apart, so I'd assume they just wanted to finish OAuth support before supporting it as well. (See below.)

Of course, I don't need to make any suggestions to developers about what to do with these APIs — I'm sure the gears in everybody's heads are turning about cool new applications to build. Instead, I'd like to make a series of suggestions for the entire Open Twitter API ecosystem, based on what we've learned from past successes and failures in APIs around blogging.

What Server Developers Should Do

• Please please please support OAuth: It's egregious that the newest implementations of the Twitter API are stil encouraging people to share their passwords with third-party sites. Five or ten years ago, this was common practice in APIs because we didn't have better options. Twitter started out using shared passwords, but mercifully has started to bring OAuth support online. But for new services to be encouraging the horrible practice of users entering their passwords into every application willy-nilly is just unacceptable. I think we have a two-week window or so within which the new services supporting the Twitter API could announce their intention to support OAuth and really catalyze client developers into doing the wrong thing, but I fear we may lose another generation of API evolution to this terrible practice. If just one or two services announce intent around OAuth by the end of the year, client developers will follow — if you use WordPress or Tumblr, encourage your service provider to do this. (This is usually where I'd insert a dozen examples of how sharing passwords screws users, services, and the ecosystem, but I know that developers often just use shared passwords because they're lazy. Do the right thing, guys. The client devs will follow along.)
• Support Really Simple Discovery: The RSD format isn't sexy by today's standards, but grew organically out of some smart thinking from when blogging APIs were at the same state of maturity as today's tweeting APIs. Instead of reinventing the wheel, developers should look at supporting RSD and looking for something like a "tweetsapi" endpoint for these new services. That way, any arbitrary site can advertise that it supports the Twitter API, or even future versions of an open MetaTweets API. Pay attention to which APIs are listed as "preferred".
• Think about overloading of source: The source element of status updates in the Twitter API is very interestingly open-ended, and supports use of URLs. Instead of merely advertising your client app, smart use of rel attributes and URLs here could help bootstrap some very interesting new potential.

What Client Developers Should Do

• Support RSD: Same logic as above.
• Start sharing parsing libraries: Client devs going to be doing a lot of duplicate work to parse out URLs and usernames and hashtags and maybe even slashtags. But almost every scripting language supports some similar variation on regular expressions, and if you're using that method to tease out meaning from short messages, then lighten your burden by sharing the load. John Gruber's work to share his URL parsing rules should be a model for a dozen other GitHub projects — compete on features and execution, but not on these fundamental interpretations of text.
• Build in the big services, but support the little ones: You'll naturally want to offer menu options for users of the big, centralized hosted services. But (perhaps as part of supporting RSD), you should allow for all of us to have arbitrary Twitter API endpoints on our own domain names — this is good for the web!

What Every Developer Should Do

• Think about piping Twitter API endpoints together: I think it will be common for some kinds of applications that support the Twitter API to be both clients and servers, supporting piping content through, and perhaps applying transformations to the updates. This idea of daisy-chaining services together is likely only going to happen if a lot of parts of the infrastructure support OAuth well, but has the potential to be truly revolutionary if the ecosystem allows it to happen.
• Start looking at people's firehoses: Twitter's firehose of all status updates is about to be broadly available for developers, I know about the free TypePad firehose from my time at Six Apart, and I think WordPress will sell you access to theirs, but I haven't yet been able to find a reference for one for Tumblr. No matter — we should assume that free, open versions of these are coming, and start to figure out how to encourage similar collaboration around the reading side of things, now that the writing side of things is getting hashed out.
• Consider adopting a "+2 Rule": The natural inclination right now for geeks of a certain type is to start dreaming up new standards bodies, or how they can participate in the Open Web Foundation to make a Super Awesome Twitter API Evolution Committee. Here's my recommendation: Don't. Don't do any of that shit, and don't run off to make membership badges for the Treehouse Club quite yet. Instead, just iterate and ship. Keep making new apps and see what you can do to stretch the limits of the existing methods and structures. I love the new geocoding and contributor aspects of the Twitter API, but as I said at the top of this post, I think the period of rapid iteration on the core Twitter API is ending, as new efforts going forward will have to reach consensus.

The good news is, consensus around evolution of the Twitter API can happen simply by saying to each other, "If two application developers who share no common investors or board members can reach agreement around an extension to the API, and between them they have a significant enough number of users to be relevant, then we should all just adopt their work."

This is important because it reframes the conversation from being about technical merits, and all the boys who like to play with APIs always think they know what's "better". I'm sure if I wanted to waste an afternoon, I could tell you a dozen ways in which the Twitter API could be "improved". But guess what? That shit does not matter. Adoption matters, and I'm heartened by the fact that people seem to be getting that.

So, get to work! Please give me feedback if I'm wrong or being stupid about one of my recommendations, but if not, then just start hacking. Stop encouraging people to share passwords, start encouraging services to share tweets, and let's all join in a hearty session of finger-pointing and mockery in Facebook's general direction for their sense of Not Invented Here having overshadowed their opportunity, because they could have really clearly done an "embrace and extend (and extinguish)" on the Twitter API if they hadn't wanted to make their own system a year ago, and now they've lost that power.

Finally, thanks a lot to Dave Winer for essentially inspiring a lot of players in blogging to move towards embracing the Twitter API. Sure, lots of us had the idea, and I've spent a lot of times in meetings arguing for this stuff across the industry, and Automattic and Tumblr and others were brave enough to embrace it. But I don't think anybody's done more to publicly advocate for an open Twitter API than Dave. I'm glad we've evolved as a community to the point where these kinds of breakthroughs aren't the contentious, immature shitfests they used to be.

I've really been enjoying the response to my recent blog posts — here are some more thoughtful replies.

Rafe Colburn, one of my favorite bloggers for a decade now, followed up my Apple and secrecy post with "Apple vs. my preconceived notions":

In one scenario, this is a bubble of sorts. Apple may be doing OK now, but they’re headed for a big crash when people get sick of their behavior. In another scenario — one that I think is, sadly, more likely, Apple continues as they are, adjusting when it must to address reality, but only in the most minimal way.

I've also really been enjoying watching Dave Winer's work recently. In the past we were both too young and stubborn to realize we're amused by a lot of the same things (There's my refrain of "We hate most in others that which we fail to see in ourselves" again!) but these days it is just plain entertaining to watch Dave go. My amusement is amply covered in "Anil's belly laugh", which mentions my response to Dave's latest bit of hacking. As I mentioned on my Twitter account, I also recorded an episode of the Bad Hair Day podcast with Dave and Marshall Kirkpatrick last week.

Speaking of podcasts, This Week in Google is a new one featuring Leo Laporte, Jeff Jarvis and Internet Hero Gina Trapani. This week, they had a very nice look at The Pushbutton Web towards the end of the show. I'm delighted how many people have told me they found that post valuable or useful in talking about this whole area of innovation. Since I'm a lousy coder, writing blog posts like that is the most helpful thing I can do.

Finally, as it's come up in several contexts lately, it's probably worth repeating the key point of a post I wrote two years ago, which attracted some attention then but is probably even more relevant today. The core concept is about "The Watery Web":

It's not true to say that Facebook is the new AOL, and it's oversimplification to say that Facebook's API is the new [MSN] Blackbird, or the new [AOL] Rainman. But Facebook is part of the web. Think of the web, of the Internet itself, as water. Proprietary platforms based on the web are ice cubes. They can, for a time, suspend themselves above the web at large. But over time, they only ever melt into the water. And maybe they make it better when they do.

Thanks, as always to people who've responded to what I've written, and especially to all of those who've taken these posts as starting points and expanded the ideas into some truly inspiring creations.

From my Facebook Usernames post on June 10:

July 31, 2009: MySpace announces MyAddress, a feature for providing more control over the URL where your MySpace profile appears. Instead of constraining users to a few choices as Facebook does, MySpace gives users very broad control over what kind of address they can have. As a result, users pick web addresses that exactly match their obscure handles on the service, instead of using their real names.

From TechCrunch today, talking about MySpace's announcement for July 31 (emphasis mine):

Here’s what else is nice: Because MySpace has had so-called vanity URLs since its inception (unlike Facebook, which just rolled out the feature), you can use those as your email address with the new MySpace Mail. So for a page that resides at myspace.com/techcrunch, the email would be techcrunch@myspace.com, for example. And, if you don’t like the vanity URL you currently have, MySpace is giving you the opportunity to change it to something else (assuming it’s available). This would also change your vanity URL for your profile.

I love the tech industry. I really do.

There have been a lot of great conversations around and about some of my recent posts; Here are some highlights.

My post about Google's Microsoft Moment seems to have really struck a nerve. First amongst the responses, from my perspective, is prominent Googler Matt Cutts' "Why Googlers should read Anil Dash's post. The open-mindedness and willingness to take constructive criticism that Matt shares with a number of his colleagues at Google (I'd also highlight Karen Wickre, who helps lead Google's efforts in blogging and on Twitter) are going to be the factor that decides whether or not Google falls prey to the dangers outlined in that essay. Matt concludes his comments with a simple, and inspiring exhortation:

Googlers, ask yourself how you can help make another one of those moments where you’re proud to work at Google. I think those moments are a great way to keep from becoming just another large company. And if Googlers are open to posts like Anil Dash’s, the web is tell us tons of things it wants us to do, or how to do them better.

Some other notable conversations around these ideas popped up as well:

• The presciently-named (but independent) Google Operating System blog offers up Google's Changing Corporate Culture.
• Ex-Googler, current FriendFeeder and all-around good guy Kevin Fox takes issue with some of my points in Google's Apple Moment. Kevin raises the point that a lot of Googlers did: It's okay for Google to have two different operating systems because they serve two different markets. I don't disagree — I did ask in my original essay "If the keyboard works with my fingers instead of my thumbs, I should use Chrome OS and not Android?" and folks at Google have already responded to me privately with, in effect, "Actually, that might not be such a bad way to put it..." My point, though, was not that it doesn't make good technical sense to have these systems. Rather, that sort of roadmap complexity makes it hard for casual outside observers to believe that their needs are being put ahead of the company's platform ambitions. I'll chalk up the lack of clarity there to my own poor editing and the fact that John Gruber highlighted that bit on Daring Fireball, which may have put more focus on what was a relatively minor point.
• I loved, and totally agree with, Mini-Microsoft's Microsoft Has Turned The Corner. This makes explicit what was part of the subtext of my essay: Even Microsoft doesn't do this kind of shifty crap anymore, if they can help it. And to their credit, Microsoft since Ray Ozzie's ascension has also seemed to regain their ambition and clarity around creating innovative products. I'm not sure if that's correlation or causation, but it's good to see regardless, and this is a post well worth reading in full.
• One of my favorite bloggers, Mike Masnick of TechDirt, asks Has Google Reached The Perception Tipping Point? The post consists of the single word "Yes." Okay, not really, but it's still thoughtfully argued and especially highlights Google's recent track record in the area of intellectual property and DRM, which is TechDirt's strongest suit.
• Finally, a couple more mentions in bigger media: BusinessWeek's Rob Hof offers up a critical look at Google's strategy, which is a welcome change from most mainstream press that tend to slavishly puff up any pronouncement of this scale that comes out of the tech industry. Similarly, Alex Pham at the LA Times puts the Chrome OS story in the context of Microsoft's Office 2010 announcement today. Matt Asay has an even more skeptical take over at CNET. And finally I thought MG Siegler's brief post about the back-and-forth between me and Matt Cutts offered up a nice perspective on the perils and potential of this inflection point in Google's evolution.

Here's a two-fer: Chris Anderson's CNN Commentary on Google, Microsoft, and Free. Chris ruminates on whether the tech giants' habit of entering new markets with free products funded by the obscene margin they make in their primary lines of business is going to face legal scrutiny in the future. Recommended if you liked either Google's Microsoft Moment or Free Criticism, Science After Data and Airport Books.

Reason mag's Tim Cavanaugh had an amusing riff that referenced that post of mine from the other day: Resolved: The New York Times Should Be Staffed By Volunteers, Like Meals On Wheels. I thought it was a fun read, at least.

And if you're seeking out even more comment on these topics, Silicon Alley Insider has a pretty fun thread in response to my Free Criticism post, along with a slightly more inane one in response to last month's post about The Future of Facebook Usernames.

Finally, some stuff that's actually related to my day job:

• Tony Dearing at AnnArbor.com has a really smart take on a conversation we had about what that site is doing to make a real community-focused local news website. I think the current AnnArbor.com team has the best chance at success of any of the dozens of similar efforts I've seen over the past several years.
• In a similar vein, Ken Edwards has a detailed look at what it's taken to build the new BG Views community at Bowling Green State University. It's always fun to watch a project like that from afar and get to see a new community take off.

Thanks to everyone for great comments on my previous posts, and even more for the inspiring conversations that have happened around these topics. And a specialy thanks to the many of you who've shared links to these pieces on Twitter: @padmasree, @timoreilly were instrumental in kicking off the broader conversation around the recent Google post, and it was really gratifying to see @wilw find a quote in my Free Criticism essay that really seems to have struck a nerve.

The whole world A small number of super-geeky obsessives is abuzz over the upcoming launch of Facebook Usernames, an exciting new feature that will let you put some parts of your name into a web address.

June 13, 12:01am: Facebook launches Facebook Usernames. The gold rush is on!

June 13, 12:01:45am: The first completely irrational, highly unlikely theory about how Google indexes Facebook Usernames is emitted from the ass-end of the SEO industry.

June 13, 12:02am: An enterprising and mischevious nerd who is definitely not me squats on the username of a notable tech trade reporter like Michael Arrington.

June 13, 12:06am: The Facebook username system starts getting overloaded with new registrations, but their tech team clears it up in 20 or 30 minutes, for a total period of slowness of about 35 minutes.

June 13, 12:15am: A first wave of "It's alive! Go get your name!" posts go up on various technology blogs, noting that the service is running a little bit slow. None of these posts mention that you can also register a real domain name that you can own, instead of just having another URL on Facebook.

June 13, 12:45am: TechCrunch discovers that one of its writers can't get his preferred spelling for his name, and notices that registrations in the system are running a bit slow. A Twitter search reveals four other people discussing the same problems, and one person that can't get to the feature at all. The phrase "The Facebook Username debacle" is first used, and becomes the preferred sobriquet for the feature forevermore. 70% of commenters mention that "Facebook Username" can be abbreviated "FU", and each thinks he is the first to think of it.

June 13, 1:00am: #FUFacebook becomes a Trending Topic on Twitter. People who are presently whining about how expensive it is to buy a new iPhone because they bought a new iPhone last year will have the chance to see how obnoxious and overprivileged they look, but will not take the opportunity.

June 13, 9:00am: The first mainstream coverage of the feature happens in the New York Times, which includes a one-line mention of the launch in a lengthy feature about Twitter's Verified Accounts. The story includes a colorful illustration of Kanye West, but omits any mention that you can also register a real domain name that you can own, instead of just having another URL on Facebook.

June 13, 12:01pm: Twelve hours after launch, a passionate and vitriol-filled flame war erupts amongst web protocol nazis about exacly which 300-series HTTP header should be used to redirect from the old /profile.php?id=500012896 URLs to the new system. Mark Pilgrim writes an overwrought essay on the topic, and 300 Ubuntu users on netbooks use their free hand to Digg the post. For these nerds, "The Facebook Debacle" refers to the improper headers used on the redirects, instead of the few minutes of difficulty in registering names.

June 13, 12:01pm: Within twelve hours of launch, the OpenID community will quietly reach out to Facebook, asking about their plans to have Facebook Usernames become an OpenID provider. Facebook will decline to comment, Simon Willison will write a thoughtful and persuasive essay about the benefits to Facebook if they were to embrace such a thing, and Andy Baio will politely link to it on Waxy Links. Months later, Facebook will actually implement the feature. For this community, this cordial and fruitful exchange will be referred to "The Facebook Debacle".

June 13, 3:00pm: I tweet a link to my post about owning your identity online. The few folks who read it seven years ago nod in agreement, and everyone else considers reading the short bit.ly URL to be equivalent to reading the post.

June 13, 4:04pm: A white guy named David discovers every variation of his name on Facebook is already taken, and finally reconsiders the condescending contempt he's always had for black people who give their kids unique names. This tiny bit of racial reconsideration is the only unequivocally good news to come out of the Facebook Usernames launch.

June 15, 8:00am: A short and punchy Monday morning story about Facebook Usernames appears on USA Today's website, omitting any mention of the word "debacle", but dwelling heavily on the preponderance of URLs with "Hussein" in them. This vestige of the Presidential elections, which briefly convinced college kids that changing their middle name on a website was a form of political activism, is promptly interpreted as an Al Qaeda sleeper cell movement by most of the paper's print readers.

June 15, 9:00am: In its opening weekend, between four and five million people (or between two and three percent of Facebook's ostensible population) will have registered Usernames for themselves. Tech pundits will say "everyone has a Facebook Username now" and refer to that assertion as an article of faith in future posts about identity. It will not be until 2012 that Facebook supports the full range of diacritical marks and international characters that let the other 5.5 billion residents of Earth use their name as a username, but this fact will go unreported.

June 15, 11:00am: In response to the growing buzz on TechMeme about "The Facebook Debacle", Mark Zuckerberg posts on Facebook's blog with the news that the company has created the Facebook Username Dispute Resolution Community. This group is tasked with creating a policy for arbitrating who can get what names, how conflicts between different people's usernames are resolved, and how to report squatting of usernames. The post omits any mention that you can also register a real domain name that you can own, instead of just having another URL on Facebook. Over the course of its 18-month existence, the FUDR Community will attract thousands of comments, 80% of which ask for The Old News Feed back, and 85% of which contain one or more typos or deviations from standard spellings of English words.

June 15, 1:00pm: LinkedIn posts a thinly-veiled but very smart update on their company blog that happens to mention in passing that they've had friendly usernames as an option for URLs for years, and that it's more likely you want to show your professional profile to the world as the first Google result for your name. The post omits any mention that you can also register a real domain name that you can own, instead of just having another URL on LinkedIn.

June 15, 1:30pm: The Google Profiles team will write a post that features a bad pun in the headline, ostensibly serving to announce some minor recent feature update, but in reality just trying to remind people that hey, you can get a Google URL. The post omits any mention that you can also register a real domain name that you can own, instead of just having another URL on Google.

June 15, 2:00pm: An enterprising young web hacker will realize that there are 24 items in this list, which means that if you add in a free space, you can very easily turn this post into a 5×5 Facebook Username Bingo Card. Combined with the Creative Commons license on this blog, it makes for a fun idea and a Flickr Pool pops up for people to show the FU Bingo cards they've generated.

June 15, 4:00pm: The first web-savvy celebrity in Hollywood will hold a meeting with their marketing team about what it will take to get their preferred username. During this meeting, the smartest person in the room will try to explain the difference between a profile page and a fan page, why there are different processes for getting vanity URLs for each, and why a person or brand doesn't have control over all the fan pages that can be created about them. That person will be ignored by everyone else for the duration of the meeting. The issue will be ignored by Facebook for nearly a year.

June 16, 10:00pm: The Domai.nr guys release a service that lets you sign in with your Facebook Connect account and automatically find what variations of your name are available as real domain names. While the feature is cool and works well, the team struggles to get press coverage for the launch, since it's predicated on the idea that you can register a real domain name that you can own, instead of just having another URL on Facebook.

June 19, 9:00am: The Bureau of Labor Statistics will announce the unemployment numbers for May, showing a loss of 660,000 jobs, with 1/3 of them being white-collar jobs. Coincidentally, 220,000 unemployed professionals will realize to their horror that their Facebook profile now ranks above their LinkedIn profile if a prospective employer googles them, and that they have no idea how to use Facebook's privacy settings.

July 31, 2009: MySpace announces MyAddress, a feature for providing more control over the URL where your MySpace profile appears. Instead of constraining users to a few choices as Facebook does, MySpace gives users very broad control over what kind of address they can have. As a result, users pick web addresses that exactly match their obscure handles on the service, instead of using their real names.

February 15, 2010: Microsoft launches a similar URL service for usernames, providing friendly URLs for millions of people on Windows Live and XBox Live, and providing the feature to more people in one day than Facebook has succeeded in delivering usernames to in eight months. Because the announcement goes out on President's day, and because it's Microsoft, nobody really notices except for a two-line mention on Mashable, half of which is a joke about Bing. Both Microsoft's own announcement and the Mashable post omit any mention that you can also register a real domain name that you can own, instead of just having another URL on Live.com.

October 31, 2010: AOL has an internal meeting about providing friendly URLs to users of AIM and Bebo, and make a bold decision to put it on their 18-month roadmap.

I hope you find this overview of the future timeline of Facebook Usernames useful to understand where this exciting feature is going in the future, how our industry will adapt and respond to this sort of innovation, and how our tech trade press will hold the powerful company's feet to the fire as this sort of capability becomes mainstream in the years to come.

And oh hey, add me as a friend on Facebook! Or become a fan of mine! Or something.

This one's been kicking around in my head for a while, and maybe you can all help me understand it. With any contemporary social networking site, I can control who has access to the things I share, and I can update or change or revoke the relationships that enable that access at any time.

For example, I can share a photo on Flickr with just my friends, or a post on Vox with just my family, or display my profile on Facebook to just my contacts. And then, if somebody ceases to be my friend, I can change their status and they no longer have access to that information. It's a unliateral, technologically enforced restriction, and circumventing the restriction would be tantamount to hacking and likely to get you banned from any of these services.

So, with all of that being said, how are privacy settings on social networks different than DRM restrictions placed on media content files from companies? Is it because I'm not a corporation? Is it because the DRM technology is provided by Flickr or Facebook instead of by Apple's iTunes or Microsoft's WIndows Media? Is it because I only (theoretically) grant permissions to dozens or hundreds of people, instead of millions?

This is a genuine question, because it's something I'm not sure I know how to articulate. I can certainly identify the difference in intent, but I am not sure I can explain the difference in definition. Feel free to comment here, or post a link or reply to @anildash on Twitter and I'll collect the best explanations I get.

I've seen a number of people make reference to Facebook's application platform without knowing a lot of background about some historical examples that might be useful to learn from. So, since I remember a good bit of info about these things, I figured I'd share it for future reference.

In 1995, Microsoft believed that its proprietary development tool, codenamed "Blackbird" would be the dominant platform for creating rich online experiences. While it would eventually evolve into a tool that created reasonably standard HTML, Blackbird's ability to make attractive and pleasing aesthetic experiences for MSN was considered a no-brainer to replace regular HTML for anything that needed to seem polished. It wasn't an unreasonable assumption at a time when most browsers were showing ugly text on a plain grey background with almost no advanced layout or design.

In 1999, AOL believed that its proprietary development tool, called RAINMAN (Remote Automated INformation MANager) would be the dominant platform for creating rich online experiences. While it would eventually be replaced by tools that created reasonably standard HTML, Rainman's ability to make attractive and pleasing aesthetic experiences that integrated seamlessly into the AOL client was an effective replacement for HTML for tens of millions of users who wanted a polished and social first experience on the Net in the late 90s as they first got online. This wasn't an unreasonable constraint to impose on the experience at a time when having a rich interactive experience meant downloading complicated browser plugins for video, or configuring temperamental client software just to read email.

AOL was always secretive about Rainman, and remains so to this day, even though Rainman has been largely retired in favor of standard HTML, which has let AOL open up much of its proprietary content to the public web. But Microsoft really wanted to get the word out about Blackbird. There were even conferences for developers, to promote Blackbird for their applications. Ironically, MSN would reverse direction from Blackbird almost immediately after launch, eventually building much of its original content around a small vector plugin called FutureSplash. One big reason you have Flash in your browser right now is because MSN aggressively distributed millions of copies of the FutureSplash plugin with all of their client software, and eventually, with Windows itself. But that's a whole 'nother story.

Back in late 1995, the venerable Release 1.0 newsletter offered an analysis of Blackbird that's well worth reading in its entirety. Some highlights:

Microsoft's challenge is to make MSN flourish soon, so that it won't be eclipsed by more open systems, making Blackbird irrelevant, or at least obsolescent. ... The question at hand is whether Microsoft's networked-application architecture makes it beyond MSN's walls and becomes more commonly used. The innovations Netscape is introducing, described above, make this a difficult task. This is where the battle between proprietary operating systems and the Internet is being fought.

...

Microsoft wants Blackbird to be an inviting environment for third-party tools. The pace of technological change will help. Connectivity will change all standalone applications, making many obsolete. With Blackbird, Microsoft is attempting to offer traditional Windows applications a viable path to re-create and re-validate themselves in the networked world. ... Blackbird has its own representation format, the Blackbird Markup Language (BML), which is a variant of HTML enhanced to be OLE 2.0-aware.

In 2007, Facebook has released its proprietary development platform, codenamed F8. Blackbird was to provide better presentation, and Rainman promised better social abilities, than open standards of their time made possible. F8 promises a combination of both aesthetic and social capabilities, with the key feature of the platform (presented as an "innovation") being the social APIs for friends lists. F8's ability to create broadly-distributed social applications that integrate seamlessly into the Facebook environment offers an experience that, for now, exceeds what publicly-available social APIs can do. It's not an unreasonable behavior that people are building and using applications on the platform today.

• Just like Blackbird, Facebook's APIs offer more features than the available open standards do today.
• Just like Blackbird, Facebook's APIs have inspired conferences and development toolkits and a lot of reactive responses in the industry.
• Just like Rainman, Facebook APIs offer native integration with social functions like buddy lists.
• Just like Rainman, the user experience for integrating those applications is far easier than the equivalent behavior on the open web.
• Just like Rainman, Facebook's APIs support applications that have millions of users, users that the conventional wisdom says could never be displaced.

It's not true to say that Facebook is the new AOL, and it's oversimplification to say that Facebook's API is the new Blackbird, or the new Rainman. But Facebook is part of the web. Think of the web, of the Internet itself, as water. Proprietary platforms based on the web are ice cubes. They can, for a time, suspend themselves above the web at large. But over time, they only ever melt into the water. And maybe they make it better when they do.

Some links:

• We're opening up the Social Graph. Six Apart, where I work, is committed to helping create, promote, develop for, and popularize the open standards that will be needed for helping grow social platforms from Facebook or anyone else.
• The O'Reilly Radar Research Report on Facebook's application platform. Interestingly, given the Release 1.0 report I quoted above, that publication has evolved into Release 2.0, which is now an O'Reilly publication.
• Jason Kottke on "Facebook vs. AOL". He covers much of the fundamentals that I've discussed here, and helped inspire me to offer some more concrete examples of the history of these sorts of efforts.
• Somehow I'd missed it at the time, but Scott Heiferman had drawn the analogy to Rainman first. I still feel people aren't very familiar with that point in web history.
• Graphing Social Patterns, the conference on Facebook and its applications that Dave McClure is currently hosting.
• The circle of web life, another similar historical lesson.