blog.pmarca.com

[For background on Open Social, please see these three prior posts: Open Social overview; screenshots and screencast; and a report from the Open Social launch.]

Ning has gone live with full Open Social beta support as of this afternoon.

First, a warning and disclaimer: as I've previously mentioned, the Open Social API is not yet stabilized and will still change. The API is officially on version 0.5 and I expect it to go through at least a few more revs before it goes to 1.0, although that should presumably happen pretty quickly. So everything I'm describing here, and everything we're doing with Open Social live on Ning, should be considered very beta/sandbox-y -- and not just "oh yeah, all this Web 2.0 stuff is beta" kind of beta, but real good-old-fashioned will-probably-break kind of beta!

How is Open Social live on Ning?

We have added Open Social functionality to all social networks on Ning, except for those that have modified their underlying source code. Which is to say, if you have gone to Ning and created a social network in the past, or if you go to Ning right now and create a new social network, you now have the option of turning on Open Social in your network. So, most of the 115,000+ networks on Ning today have the option of turning on Open Social.

Turning on Open Social is a decision that each Network Creator gets to make. By default it's turned off -- so if you just go to Ning and look at a network and the Network Creator hasn't turned on Open Social, you won't see anything different. But if a Network Creator goes into the management UI and turns on Open Social, then bingo, it'll be on.

This gives each Network Creator the option of either experimenting with Open Social today, or not. In time, as the API stabilizes, we will turn it on across the board, and also provide Network Creators with even more control over how it applies to their individual networks.

So what happens when a Network Creator chooses to turn on Open Social for her social network on Ning?

First, the Network Creator -- the person who created and/or owns the network -- can add Open Social gadgets/apps to the network's home page. All users will see and interact with those gadgets/apps.

Second, each member of the network can go to her personal profile page within the network and add Open Social gadgets/apps to her profile page. All other users will see and interact with those Open Social gadgets/apps when they visit that profile page.

How should this be used today?

Not to sound like a broken record, but the main way this should be used today is to experiment with the Open Social API and with Open Social gadgets/apps. In fact, we that recommend anyone who is running a network today and wants to play with Open Social should create a new demo network for that purpose.

That said, if you want to turn on Open Social on your production network, go crazy -- but expect the underlying Open Social API to continue to change and for gadgets/apps that run today to possibly not run in the future!

What about a directory of Open Social gadgets that I can play with?

Just click here for a gallery of Open Social gadgets/apps that you can start playing with.

If you have an Open Social gadget/app that you'd like us to add to our gallery, please read this.

How about a screencast?

Sure!

How about screenshots?

Here's a personal profile page with an embedded Open Social gadget/app (in this case, iLike):

Here's how a Network Creator adds Open Social capability to her network:

Here's the gallery of Open Social gadgets/apps:

Here's what happens, for the moment, when a user says she wants to add a gadget/app -- this will get better:

Documentation?

Early developer documentation for creating Open Social gadgets and using them on Ning is here.

Also of course see the main Google documentation for the Open Social API.

More information?

See here for the official Ning blog post announcing this support.

How do I send feedback?

We'd love to hear what you think and learn about how you want to use Open Social on Ning and elsewhere -- just go here.

Also, if you do something cool, send me email at pmarcablog (at) gmail (dot) com!

Have fun!

Tonight, a small group of entrepreneurs, technologists, executives, bloggers, press, and professional campfire tenders gathered in Mountain View below the official Google tyrannosaurus rex and formally launched Open Social into the world.

As I write this, Google is about half an hour away from officially putting the Open Social spec and code on the Internet for general consumption. At that same time, the video from the launch event should be going live. Keep hitting this currently nonworking link until you get satisfaction! [Correction -- the official site is up at that location! Also, here's the video of the launch event with all the demos.]

So how'd it go?

Great! In addition to speakers from Google, the launch event included demos from a wide swath of the "coalition of the willing" assembled in support of Open Social -- including the newest member and Open Social supporter, MySpace.

All of the demos were -- to my knowledge -- live running code. And they worked.

The T rex not only did not eat us, but did not fall over on us.

They had smores.

What's not to like?

So what else happened today?

Well, I may have mentioned that MySpace joined the OpenSocial coalition! Along with Six Apart, Bebo, and most likely a few other new partners whose names I'm forgetting in my post-smore sugar haze.

The total aggregate user base of the Open Social partners is now in excess of 200 million people.

What a world we live in. Developers of Open Social apps will have distribution to 200 million users. I'm sorry, I know I'm supposed to be cynical about this stuff, but that's astonishing.

What's the smartest thing anyone has said today about Open Social?

That would have to be Anil Dash:

As Anil said, comparing Facebook to AOL is not an accurate analogy -- for one thing, Facebook was a web site from day one and AOL was not; for another thing, Facebook has opened up a platform, even if it is proprietary, and AOL never opened up any kind of platform.

However, there is a larger point that I'd like to make based on this history. And it is this:

Freedom wins, and openness wins. You can hold it back for some period of time, but in the long run, freedom always wins because freedom and openness let people all over the world be fully creative and innovative in every way they want. And the creativity and innovation that freedom and openness enable will always swamp anyone's attempt to wall off a proprietary world with tight controls and sharp limitations.

In the mid-1990's, people told me all the time, "AOL has all the users; why would you think this web thing is ever going to amount to anything?" And it was true -- AOL did have all the users. In the beginning, AOL had tens of millions of users when the Internet had low single digit millions at best. Everyone was scrambling to do deals with AOL to get access to that huge user base, and every media company we met with (there were no Internet companies yet) laughed at the idea of regular people ever using the web.

We saw how that turned out. It turned out that people -- regular people, normal people -- embraced the web at flank speed precisely because it gave them the ability to create, and to experience, millions of web sites that reflected their interests, desires, and identities. Now, as that happened, AOL also became hugely successful by being one of the easiest on-ramps to the Internet -- but once broadband hit and consumers no longer needed a dialup ISP to get on the Internet, AOL went into a tailspin from which it has never recovered, swamped by the power of the decentralized, open, free web.

The world is filled with people who have great ideas -- big and small -- and the approach that lets the most people express their ideas tends to win.

I am not predicting the death of Facebook. I think the Facebook people are brilliant and are going to do very well over the next several years, have an excellent chance of building a huge and enduring franchise, and have an enormous amount to gain by all of this, including Open Social. But the idea that you hear from time to time that "all the users are on Facebook" and "the game is over; the Facebook platform has won" is silly, as you can see every time you use a web site that doesn't end in "aol.com".

And remember! One of the great things about Open Social is that it's not an either/or choice for app developers. It's quite easy to develop for both Open Social and Facebook, and in practice that's what I'll bet most serious app developers will be doing for the next few years, at least.

What's the dumbest thing anyone has said today about Open Social?

Obviously:

And to think that some people wonder how it is that Gartner still has any clients!

What's next for Open Social?

All of the partners finalizing and releasing all of the initial OpenSocial container and application implementations, of course. I know frenzied work is happening at all companies involved right now. Everyone can just smell the opportunity, and people are going to drive to ship as quickly as possible.

There may even be some surprises coming on this front...

The other thing that needs to happen, of course, is formalization of the process by which Open Social gets maintained and evolved. The obvious thing is some kind of lightweight working group and standards process, perhaps similar to the IETF working group model. Keep your eyes peeled for progress on that front as well!

What happens after Open Social?

Why, the great social advertising network wars of 2008, of course. More on that soon!

In yesterday's post, I described the new Open Social API, sponsored by Google and supported by a wide range of Internet companies including my company Ning.

In this post, I present a screencast and a series of screenshots that show Open Social in action.

First, the screencast:

Next, the screenshots:

As you are probably aware, Ning is a system that lets you create your own social network for anything -- your family, your school, your church, your sports team, your business, your nonprofit, whatever you want.

To illustrate Open Social in action, our screenshots are based on three networks out of the 113,000+ networks currently running on Ning: Dub Pages, a network of car customization enthusiasts; Tu Diabetes, a network of people touched by diabetes; and Ask A Ninja, a network of fans of the popular online video series Ask A Ninja.

Because Open Social is not quite ready for production launch, the screenshots below show modified versions of these networks that we have used internally to develop and demonstrate Ning's support of Open Social. Thanks to these network creators for letting us play with their networks like this!

These examples feature the use of the Open Social API to embed applications from two other Internet companies: iLike, an online music sharing service; and Flixster, an online social movie ranking and rating service -- both of whom have announced support for Open Social. These examples are all based on the idea of embedding either iLike or Flixster applications within the three Ning social networks via Open Social.

To start, here's the home page of the Dub Pages network with the embedded iLike application:

You can see in that screenshot that the iLike application is completely integrated into this network's home page. The musical selections within the iLike application are chosen by the network creator/owner; everyone who comes to the network gets to see them and listen to them.

If you're a member of the Dub Pages social network, you have your own personal profile page; here's what that page looks like, including the iLike application embedded via Open Social:

Since that's your page, you get to control the music selections within the iLike app; you can choose whatever music you want, and next time you come back to your profile page, that's the music you'll see -- the Open Social API includes a storage API that lets apps store arbitrary information across sessions.

Here's another screenshot of your personal profile page, this time showing the iLike app in action -- here the user is displaying more information about the song "The way I are" by Timbaland; the information has opened up right inside the iLike app right there in the profile page:

Embedded Open Social apps can resize themselves whenever they want to incorporate whatever functionality the user triggers -- so as an app creator, you get a lot of power to let users do things right inside their personal pages.

Shifting from iLike to Flixster as the embedded application, here's the home page of the Tu Diabetes social network with the embedded Flixster app:

Same concept -- the owner of the network gets to determine what movies show up within the Flixster app on the network home page.

Here's the profile page for an individual user:

Just like a Facebook app, an Open Social app can allow the user to click on a link within the embedded version of the app and expand into a "canvas page" that lets the embedded app show much more information in the page, but still inside the social network. Here the user on Tu Diabetes has clicked on a link in her profile page; this is the resulting canvas page that the Flixster app gets to control:

And here the user has clicked on a link on that first canvas page, which generates a second canvas page:

Finally, to prove the point, let's see that same Flixster app embedded in a different network -- the Ask A Ninja network:

And a profile page within Ask A Ninja:

And a canvas page within Ask A Ninja:

You'll notice in those Ask A Ninja examples that the Flixster app is not as visually integrated as in the other examples. In a real production system, the Flixster app will pick up the styles of the parent page. We left it the way you see it in these examples so you can clearly see the difference between the embedded app and the rest of the page in each example.

One more note: these examples are a little light on social functionality -- they don't do a lot yet with the user's friends information, or the user's activities feed, etc. The Open Social API supports a lot of those capabilities, and the app developers are now busy at work developing the full version of their Open Social apps that will do a lot more social stuff. I will post more screenshots over the next few weeks/months as those apps get more and more socially sophisticated.

And then one final note: these screenshots were not Photoshopped; this is all live running code!

My company, Ning, is participating in this week's launch of a new open web API called Open Social, which is being spearheaded by Google and joined by a wide range of partners including Google's own Orkut, LinkedIn, Hi5, Friendster, Salesforce.com, Oracle, iLike, Flixster, RockYou, and Slide.

In a nutshell, Open Social is an open web API that can be supported by two kinds of developers:

This is the exact same concept as the Facebook platform, with two huge differences:

If you recall how I previously described the Facebook platform as "a dramatic leap forward for the Internet industry", you'll understand why I think Open Social is the next big leap forward!

Open Social takes the Facebook platform concept and provides an open standard approach that can be used by the entire web. Open Social is an open way for everyone to do what Facebook has done...

...including Facebook itself, potentially -- more on that below.

Technically, Open Social is implemented as what I call a "plug-in API", or a "Level 2 platform". In other words, it's not a web services API -- rather, it's a way for external applications to "plug into" a host environment (or "container"). And then, in addition to literally showing up inside the pages of a container, the external app can make Javascript calls to retrieve all kinds of useful information from the container and perform all kinds of useful functions within the container, such as "give me a list of all of this user's friends" or "inject this event into this user's activity feed".

Open Social basically standardizes the concept of a plug-in API in such a way that neither host social networking environments (containers) nor external applications will ever have to invent another plug-in API, or have to choose between multiple competing proprietary plug-in APIs.

Open Social's API is based entirely on Javascript. If you know HTML and Javascript today, you will be able to immediately use Open Social to turn your web applications and web sites into Open Social apps. You can also use standard web development tools to build Open Social apps. This is obviously a much better way to operate than having to learn a proprietary marketup language or query language.

Finally, although Open Social provides standard API calls to do many of the things you'll want to do as an Open Social app, nothing will prevent containers from implementing additional Javascript or web services APIs to provide additional functionality to developers. Open Social app developers can therefore choose to stay "onroad" and have their apps run in any Open Social container, or go "offroad" for one or more specific containers to do special things. Open Social standardizes common functionality but doesn't prohibit innovation. More on that below.

Open Social is very practical. Many standards die an early death because they are too complicated and hard to implement. Open Social is what you want in a standard -- it's expansive enough to do useful things, but limited enough to be very easy to implement, both for containers and for apps.

At this Thursday's launch event, you will see Open Social already running in a variety of containers, including Ning, Orkut, Hi5, and LinkedIn, and across a variety of apps, including iLike, Flixster, and Slide. I'm talking about working code. At Ning, it took us only a few days for us to add support for Open Social as a container -- because we already had all the necessarily underlying APIs and mostly just had to map to them -- and the app developers in the launch created Open Social versions of their apps even more quickly. We also have live running examples, such as iLike, of the same app running in multiple containers -- Ning, Orkut, and Hi5 -- proving the interoperability that the Open Social specification promises.

Now, all that said, Open Social is not quite ready to go live on Ning and the other partners. The API has to stabilize a bit, and containers have to finish testing and validating their implementations. But public production systems aren't far off -- Ning, for one, will go live as soon as we possibly can, probably just as soon as Google finalizes the API.

What does this mean for today's Facebook app developers?

Today's Facebook app developers just got very good news -- they will be able to take all of the work they did to build their Facebook apps and create Open Social versions of their apps very easily... and by so doing, get access to a huge new pool of users -- as many as 100 million users just via the initial Open Social partners, more than twice as many users as Facebook has today.

As an app developer, there's no real reason to choose between Facebook and Open Social. It's easy to do both. You've already put in most of the effort -- creating a new set of front-end HTML and Javascript pages is almost trivial, and that's all you need to do to have your app "port" to Open Social and work within Open Social containers like Ning, Orkut, Hi5, and LinkedIn.

What does this mean to web sites that aren't Facebook apps?

If you have a web site today, and you want to turn your web site into an Open Social app, that's perhaps even easier than "porting" a Facebook app. Just take your current HTML and Javascript front-end pages and create a version of those pages that use the Open Social API. QED.

Are people really going to maintain multiple sets of front-end pages for their web sites for Facebook, Open Social, etc.?

I think so, yes. I think any web site going forward that wants maximum distribution across the largest number of users will have a single back-end, and then multiple sets of front-end pages:

The overwhelming good news here is that these pages can all be served and serviced by the same back end code -- and of course, 95%+ (and usually 99%+) of the effort involved in building any web app consists of building the back end. Having already built the back end, it's a very small amount of effort to create any of these front end pages.

What does this mean for Facebook?

Well, to venture a few opinions...

Facebook did an absolutely outstanding job kick-starting this whole approach with their proprietary Facebook platform. That plus their very large walled garden user base generated a rush of app development and adoption on Facebook that has performed very well for them over the last five months.

Open Social -- by making this exact same kind of opportunity available to any other social network or container and every app developer and site on the web, in an open and compatible way -- will prevent Facebook from having any kind of long-term proprietary developer lock-in. Developers will easily write to both Facebook and Open Social, and have every reason to do so -- in fact, 100+ million reasons to do so.

If you're Facebook, you'd probably prefer to have that proprietary lock-in, and so this announcement may not make you that happy. However, all is not bad for Facebook, because a big part of what's happening today is market expansion, and Open Social will definitely help fuel market expansion, which is in everyone's interest, including Facebook's.

Look at it this way: most users on the Internet (1.3+ billion, with 100 million joining every year) are not yet using any social networking service. The more compelling social networking becomes, the more users who will discover and start using social networking, and the bigger the pie gets for everyone, including Facebook.

Meanwhile, most software developers in the world are not yet building apps for social networks -- Facebook or otherwise. The more developers who build social networking apps -- Facebook or otherwise -- the more apps there will be on social networks, and the bigger the pie gets for everyone, including Facebook.

It's hard to see Facebook losing in a world of a billion or more social network users, and hundreds of thousands or millions of social network apps. And it's also easy to see how a lot of other people -- containers, and app developers -- will win, as well.

In fact, if rumors of a Facebook web-wide ad network are true, then this could be great for Facebook in another way -- such a Facebook-run ad network could be an outstanding ad network for all of these new Open Social web applications!

Finally, note that Facebook can easily support Open Social any time they want. They probably won't do so right away, but in the long run, it will probably be a no-brainer for them, because then they will pick up whatever Open Social app developers who aren't also Facebook developers.

Is this good for the web?

This is very, very good for the web. Open Social is the kind of standard that web developers love, and can easily use. I think it will become a standard part of many developers' toolkits. It builds on HTML and Javascript, many people can support it, and it will be interoperable -- I know that because it already is interoperable for the partners in this week's launch. It's all good.

How will Ning support Open Social?

We will aggressively support Open Social in every conceivable way, including but not limited to:

Where's MySpace?

Beats me.

Where's Yahoo?

Beats me.

You mentioned that Open Social containers can implement additional Javascript or web services APIs -- won't that break compatibility?

No, I don't think so. Think of it this way. As an app developer, you have three options:

No standard can possibly anticipate all of the different use cases and scenarios people will think up. Standards that try to anticipate all of the different use cases fail, because they are too complex and generally impossible to implement. Standards that standardize behavior that is clearly standard, while leaving open the ability to innovate on top, succeed. The history of this kind of thing is quite clear, and Open Social is on the right side.

Closing thought?

Congratulations to Google -- the crew at Google has been outstanding in conceiving of, implementing, and evangelizing Open Social to the initial set of partners -- and now, to the world. Thanks!

[Title with sincere apologies to Mitch Albom and his wonderful book.]

One of the hottest of hot topics these days is the topic of Internet platforms, or platforms on the Internet. Web services APIs (application programming interfaces), web services protocols like REST and SOAP, the new Facebook platform, Amazon's web services efforts including EC2 and S3, lots of new startups talking platform (including my own company, Ning)... well, "platform" is turning into a central theme of our industry and one that a lot of people want to think about and talk about.

However, the concept of "platform" is also the focus of a swirling vortex of confusion -- lots of platform-related concepts, many of them highly technical, bleeding together; lots of people harboring various incompatible mental images of what's about to happen in our industry as a consequence of various platforms. I think this confusion is due in part to the term "platform" being overloaded and being used to mean many different things, and in part because there truly are a lot of moving parts at play that intersect in fascinating but complex ways.

This post is my attempt to disentangle and examine the topic of "Internet platform" in detail. I will go at it by identifying three distinct approaches to providing an Internet platform, and project forward on where I think each of the three approaches will go. At best, I might be able to help make a new landscape clear. At worst, hopefully I can at least provide one framework for future discussion.

Let's start with a basic definition. From a previous post:

A "platform" is a system that can be programmed 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.

We have a long and proud history of this concept and this definition in the computer industry stretching all the way back to the 1950's and the original mainframe operating systems, continuing through the personal computer age and now into the Internet era. In the computer industry, this concept of platform is completely settled and widely embraced, and still holds going forward.

The key term in the definition of platform is "programmed". If you can program it, then it's a platform. If you can't, then it's not.

So, if you're thinking about computing on the Internet, whenever anyone uses the word "platform", ask: "Can it be programmed?" Specifically, with software code provided by the user? If not, it's not a platform, and you can safely ignore whoever's talking -- which means you can safely ignore 80%+ of the people in the world today who are using the term "platform" and don't know what it means. (Yes, there are hardware platforms too! But those are different and I'm not talking about them.)

Now, traditionally in the field of computing, there has been a single main way of providing a platform. You provided a computer system -- a mainframe, a PC operating system, a database, or even an ERP system or a game -- that contained a programming environment that let people create and run code, plus an API that let them hook into the core system in various ways and do things.

To quote Tony Stark, "That's how Dad did it, that's how America does it, and it's worked out pretty well so far."

The Internet -- as a massive distributed system of many millions of internetworked computers running many different kinds of software -- complicates things, and gives rise to three new models of platform that you see playing out in the Internet industry today.

I call these Internet platform models "levels", because as you go from Level 1 to Level 2 to Level 3, as I will explain, each kind of platform is harder to build, but much better for the developer. Further, as I will also explain, each level typically supersets the levels below.

As I describe these three levels of Internet platform, I will walk through the pros and cons of each level as I see them. But let me say up front -- they're all good. In no way to I intend to cast aspersions on what anyone I discuss is doing. Having a platform is always better than not having a platform, period. Platforms are good, period.

So, let's walk through the three levels of Internet platforms.

Level 1 is what I call an "Access API".

This is the kind of Internet platform that is most common today. This is typically a platform provided in the form of a web services API -- which will typically be accessed using an access protocol such as REST or SOAP.

Architecturally, the key thing to understand about this kind of platform is that the developer's application code lives outside the platform -- the code executes somewhere else, on a server elsewhere on the Internet that is provided by the developer. The application calls the web services API over the Internet to access data and services provided by the platform -- by the core system -- and then the application does its thing, on its own. That's why I call this an "Access API" -- the key point is that the API is accessed from outside the core system.

This is of course the approach taken by eBay, Paypal, the Google Search API (before they killed it), Flickr, Delicious, etc. Whenever someone pulls photos out of Flickr to put them on another web site, or whenever someone creates a Google Maps mashup, they're using a Level 1 Internet platform.

This is undoubtedly a very useful thing and has now been proven effective on a widespread basis. However, the fact that this is also what most people think of when they think of "Internet platform" has been seriously confusing, as this is a sharply limited approach to the idea of providing a platform.

What's the problem? The entire burden of building and running the application itself is left entirely to the developer. The developer needs to provide her own runtime system, programming language, database, servers, storage, networking, bandwidth, and security, and needs to take responsibility for running all of the above -- and then exposing the application to users. This is a very high bar in terms of both technical expertise and financial resources.

As a consequence, you don't see that many applications get built relative to what you'd think would be possible with these APIs -- in fact, uptake of web services APIs has been nothing close to what you saw with previous widespread platforms such as Windows or the Mac.

This is, however, by far the easiest kind of Internet platform to create. As the platform owner, you don't have to worry about developer code running inside your system or developer functionality injecting itself into your system; you retain completely control over your user interface; and you can sharply limit the load impact that third parties can have on your systems -- i.e., throttling is straightforward.

Because of this and because Level 1 platforms are still highly useful, notwithstanding their limitations, I believe we will see a lot more of them in the future -- which is great. And in fact, as we will see, Level 2 and Level 3 platforms will typically all incorporate an Level 1-style access API as well.

Level 2 is what I call a "Plug-In API".

This is the kind of platform approach that historically has been used in end-user applications to let developers build new functions that can be injected, or "plug in", to the core system and its user interface.

For example, Photoshop has for a long time had a widely used and highly successful plug-in API. Lots of people have used the Photoshop plug-in API to build tons of new functionality for Photoshop ranging from support for new file formats to new ways to retouch images to new special effects to apply to images.

More recently, Firefox is well known for having a great plug-in, or extension, API that lets third parties build a wide range of Firefox plug-ins. These plug-ins span functions from blogging to dowloading to search to language translation.

In the Internet realm, the first Level 2 platform that I'm aware of is the Facebook platform.

When you develop a Facebook app, you are not developing an app that simply draws on data or services from Facebook, as you would with a Level 1 platform. Instead, you are building an app that acts like a "plug-in" into Facebook -- your app literally shows up within the Facebook user experience, often as a box in the middle of a page that Facebook otherwise defines, such as a user profile page.

Your Facebook app can of course also use Facebook's Level 1-style access API -- their web services API -- to pull data or services from Facebook's core systems -- and in fact the two approaches neatly complement each other, because without the access API your embedded Facebook app wouldn't know anything about the system in which it was embedded and wouldn't be very useful.

I think that Facebook's platform approach is a harbinger of a large number of new Internet plug-in APIs that will be created for lots of other Internet services from here on out. Which is great: developers will be able to inject new functions into many other Internet services in the future, just like they can with Facebook today.

As a historical side note, in retrospect, this is what AOL should have done in the mid 1990's when the web first popped up. At that point, AOL had a huge user base relative to the consumer Internet. However, AOL was completely closed -- third parties couldn't build new functions or apps that could plug into AOL and be used by AOL users. As a consequence, all of the creativity and third-party effort that AOL might have harnessed had they provided a plug-in API -- a way for third parties to build apps that would inject new functions into the AOL user experience -- went to the web instead. A few years later, it became clear to AOL users that the web is where all the interesting stuff was, and then when broadband came along and people had to switch ISPs anyway, the users bailed on AOL.

Seen through this lens, Facebook -- and I mean this in the best possible way -- is the new AOL, but, by also being a platform, executing the opportunity correctly.

Technically, with an Internet plug-in API approach such as Facebook's, the third-party app itself lives outside the platform -- outside the core system -- just like I described for Level 1 platforms. The code for the app runs somewhere else. This means that just like with Level 1 platforms, the entire burden of building and running a Level 2 platform-based app is left entirely to the developer -- who still needs to provide her own runtime system, programming language, database, servers, storage, networking, bandwidth, and security, and who still needs to take responsibility for running all of the above.

As a result, the technical expertise and financial resources required of a Level 2 platform's developer -- if she intends to build a meaningful app -- are very high.

Technical expertise: the developer has to be a world-class expert at building and deploying Internet applications, which have lots of moving parts.

Financial resources: the developer has to foot the bill for servers, storage, networking gear, bandwidth, etc., which can be significant for meaningful apps -- especially if they succeed.

In fact, if an app succeeds on a Level 2 platform, the technical and financial burdens on the developer can rapidly become overwhelming -- leading me to summarize with the phrase "success kills".

On top of that, there's an issue for the platform provider as well. When a third party app embedded into a Level 2 platform is down, because the developer doesn't know how to scale or doesn't have the money required to do so, the error shows up as an error within the core system. For example, whenever an individual Facebook app is down, users see the error within their Facebook pages -- even though Facebook itself is not responsible for the app outage, nor could Facebook do anything about that outage even if they wanted to. Ordinary users will not realize who is at fault and will tend to blame the core system -- in this case, Facebook.

For these reasons, I think that while Level 2 platforms are clearly very powerful and are wonderful for users, these issues sharply constrain the number of developers who can build apps to those who have the technical capability and the financial resources to build their own primary Internet systems anyway -- which is a small fraction of the people who will ultimately want to be developers on popular Internet platforms.

The great news, though, is that unlike a Level 1 platform where the burden of exposing the app to users is also placed on the developer, Level 2 Internet platforms -- as demonstrated by Facebook -- will be able to directly help their developers get users for their apps. This is one of the reasons I have called the Facebook platform a breakthrough -- Facebook provides a whole series of mechanisms by which Facebook users are exposed to third-party apps automatically, just by using Facebook. This is great for developers, and hopefully new Level 2 Internet platforms will follow in Facebook's footsteps -- and not in MySpace's, which could have been a Level 2 Internet platform well before Facebook but instead took a very hostile stance towards third-party developers.

It is also worth nothing that Level 2 platforms are significantly harder to create than Level 1 platforms. Facebook, for example, had to anticipate and provide technical solutions for a whole series of issues -- user interface issues, security issues, performance issues, caching issues, etc. -- to provide their plug-in API that providers of access APIs don't have to worry about. This is perhaps why we haven't seen more Level 2 platforms -- yet.

Level 3 is what I call a "Runtime Environment".

In a Level 3 platform, the huge difference is that the third-party application code actually runs inside the platform -- developer code is uploaded and runs online, inside the core system. For this reason, in casual conversation I refer to Level 3 platforms as "online platforms". Let me explain.

In addition, it is highly likely that a Level 3 platform will also superset Level 2 and Level 1 -- i.e., a Level 3 platform will typically also have some kind of plug-in API and some kind of access API.

Put in plain English? A Level 3 platform's developers upload their code into the platform itself, which is where that code runs. As a developer on a Level 3 platform, you don't need your own servers, your own storage, your own database, your own bandwidth, nothing... in fact, often, all you will really need is a browser. The platform itself handles everything required to run your application on your behalf.

Obviously this is a huge difference from Level 2. And this difference -- and what makes it possible -- is why I think Level 3 platforms are the future.

Let's start with one big issue right up front: Level 3 platforms are much harder to build than Level 2 platforms.

As a platform provider, once you accept the idea that user code -- code that you didn't write and you can't vet for quality or security -- is going to run within your platform, you have a whole pile of issues you have to deal with that a Level 2 platform can simply ignore.

The Level 2 platform's apps will be running their code elsewhere -- at the end of the day, the running code is someone else's problem. With a Level 3 platform, all the running code for all the apps is your problem.

What are some of those issues? To list a few: You have to provide a runtime environment that can execute arbitrary third-party application code. You have to build a system for accepting and managing that code. You have to build integrated development tools into your interface to let people develop that code. You have to provide an integrated database environment suitable for applications to store and process their data. You have to deal with security in many different ways to prevent applications from stepping on one another or on your system -- for example, sandboxing. You have to anticipate the consequences an application succeeding and needing to be automatically scaled. And you have to build an automated system underneath all that to provide the servers, storage, and networking capabilities required to actually run all of the third-party applications.

And you probably also have to provide Level 2 functionality -- a plug-in API -- and Level 1 functionality -- an access API -- so that third-party applications can actually do useful things once they are running within your system.

The bad news is that this is a truly intense technical and business undertaking, and not for the faint of heart.

The good news is that what it makes possible is magical.

Here's what's magical: the level of technical expertise required of someone to develop on your platform drops by at least 90%, and the level of money they need drops to $0. Which opens up development to a universe of people for whom developing on a Level 2 or Level 1 platform is prohibitively difficult or expensive.

Actually, it gets even better than that. You can provide an open source ecosystem within your platform to let users freely share code with one another -- actual running code! You can in essence have your own open source dynamic within your platform -- in the best case, allowing users to clone and modify one another's applications with a level of ease that the software industry has never seen. The rate of rapid evolutionary application development that can result from this approach will, I think, be mind-boggling as it plays out.

You can also, if you want, provide a marketplace that lets people buy and sell code -- then you can have the open source dynamic and the profit incentive. The sky's the limit in terms of how much development can happen on a platform like that.

The Level 3 Internet platform approach is ironically much more like the computer industry's typical platform model than Levels 2 or 1.

Back to basics: with a traditional platform, you take a computer, say a PC, with an operating system like Windows. You create an application. The application code runs right there, on the computer. It doesn't run elsewhere -- off the platform somewhere -- it just runs right there -- technically, within a runtime environment provided by the platform. For example, an application written in C# runs within Microsoft's Common Language Runtime, which is part of Windows, which is running on your computer.

I say this is ironic because I'm not entirely sure where the idea came from that an application built to run on an Internet platform would logically run off the platform, as with Level 1 (Flickr-style) or Level 2 (Facebook-style) Internet platforms. That is, I'm not sure why people haven't been building Level 3 Internet platforms all along -- apart from the technological complexity involved.

However, I think this will change, because the advantages of being a Level 3 platform -- particularly the advantages to the developer, and thereby for the platform -- are so overwhelming.

So who's building Level 3 Internet platforms now?

First, I am -- Ning has been built from the start to be a Level 3 platform.

I'll be writing more about this in another post, but in a nutshell, Ning is a full online platform for creating and running social networking applications. We provide all of the platform functions I described above, including the ability for users to either create their own applications or run clones or modified copies of applications we or other people provide.

There are close to 100,000 such applications currently running on the Ning platform -- you can see them at Ning in the form of all of the various social networks and applications in the system -- and that number is growing very quickly.

Second, in a completely different domain, Salesforce.com is also taking a Level 3 platform approach -- Salesforce now provides quite sophisticated ways for users and developers to create and upload code and program the Salesforce platform from a browser.

Salesforce provides a Level 3 platform both because it lets users easily customize Salesforce to do whatever they need, and also because it definitively trumps the criticism they historically got from packaged software vendors like Siebel who accused Salesforce of not being as adaptable as a piece of software you install on your own servers.

You probably don't see this in action much -- unless you're a Salesforce user -- but they're doing really interesting work in this area and getting great results.

Third, and again in a completely different domain, Second Life is a Level 3 platform.

It's a little different in that Second Life provides its own client -- for its immersive 3D world -- but you can think of the Second Life client as analogous to a browser in that it's an Internet client that draws on content being sent down from Second Life's servers.

Then, within Second Life, there is a complete runtime environment for running code provided by any user -- you can create items within Second Life and program them to do anything and behave in any way that you can possibly imagine. And you can, with permission, look at the code of another user's item and then make a copy or modify it to do whatever you want. And all of that code is running on Second Life's servers.

It's a tremendously dynamic platform that lets users build a dizzying array of worlds and objects that are all completely customized -- programmed.

Fourth, Amazon is -- I would say -- "sort of" building a Level 3 Internet platform with EC2 and S3. I say "sort of" because EC2 is more focused on providing a generic runtime environment for any kind of code than it is for building any specific kind of application -- and because of that, there are no real APIs in EC2 that you wouldn't just have on your own PC or server.

By this, I mean: Ning within our platform provides a whole suite of APIs for easily building social networking applications; Salesforce within its platform provides a whole suite of APIs for easily building enterprise applications; Second Life within its platform provides a whole suite of APIs for easy building objects that live and interact within Second Life. EC2, at least for now, has no such ambitions, and is content to be more of a generic hosting environment.

However, add S3 and some of Amazon's other web services efforts to the mix, and you clearly have at least the foundation of a Level 3 Internet platform.

Interestingly, Amazon's FPS -- Flexible Payments Service -- is itself a Level 3 Internet platform. You actually upload code written in a specialized programming language -- which they called GK, for "Gatekeeper code" -- that controls how payments happen; that code runs within Amazon's online systems. It's a really innovative way to provide a highly flexible vertical service -- and great to see!

Fifth and last, Akamai, coming from a completely different angle, is tackling a lot of the technical requirements of a Level 3 Internet platform in their "EdgeComputing" service -- which lets their customers upload Java code into Akamai's systems. The Java code then runs on the "edge" of the network on Akamai's servers, and is distributed, managed, and secured so that it runs at scale and without stepping on other customers' applications.

This is not a full Level 3 Internet platform, nor do I think Akamai would argue that it is, but there are significant similarities in the technical challenges, and it's certainly worth watching what they do with their approach over time.

These examples illustrate one final point about Level 3 platforms: you have to commit to never killing your platform. This is a sharp difference.

Think about it: For a Level 1 or Level 2 platform, if you kill the platform, you still have a working and useful system. If the Google Search API gets killed -- and it was! -- you still have Google Search which is still useful to its users. If the Facebook platform gets killed -- which presumably it won't be -- you still have Facebook which is still useful to users as a social networking service in exactly the same way it was before they introduced their platform.

On the other hand, if you kill a Level 3 platform, you destroy the whole reason people use your system to begin with -- to develop and run custom code. If you remove the platform from Ning, Ning is useless -- applications don't run, and users can't do anything. If you remove the platform from Salesforce, all the users who are using customized apps can't use Salesforce anymore. If you remove the platform from Second Life, none of the objects or experiences in the virtual world work anymore and the whole user experience collapses.

Like my old boss Jim Barksdale used to say, it's the difference between the chicken and the pig at a ham and egg breakfast. The chicken's involved but the pig is committed.

I believe that in the long run, all credible large-scale Internet companies will provide Level 3 platforms. Those that don't won't be competitive with those that do, because those that do will give their users the ability to so easily customize and program as to unleash supernovas of creativity.

I think there will also be a generational shift here. Level 3 platforms are "develop in the browser" -- or, more properly, "develop in the cloud". Just like Internet applications are "run in the browser" -- or, more properly, "run in the cloud". The cloud being large-scale Internet services run on behalf of users by large Internet companies and other entities. I think that kids coming out of college over the next several years are going to wonder why anyone ever built apps for anything other than "the cloud" -- the Internet -- and, ultimately, why they did so with anything other than the kinds of Level 3 platforms that we as an industry are going to build over the next several years -- just like they already wonder why anyone runs any software that you can't get to through a browser. Granted, I'm overstating the point but I'm doing so for clarity, and I'm quite confident the point will hold.

Three closing notes!

First, how will we see the new platforms of the future?

We are used to seeing platforms ship as products -- you buy and install a PC or a server and you build an app that runs on it, or equivalently you download and install an open source platform such as Perl or Ruby and you build an app that runs on it.

The platforms of the future won't be like that. The platforms of the future will be online services that you will tap into over the Internet, perhaps with nothing more running locally than a browser. They won't have anything you download, or even an SDK. They will look more like services than software. To paraphrase the Book of Matthew, "you will know them by their URLs".

Second, beware overfocusing on the apps of the past when thinking about the platforms of the future.

Lots of people got confused by the idea of apps running in the browser because when they thought of apps, they thought of the apps they used already on their PCs -- Word, Excel, Powerpoint -- and not the apps that would get built on the web -- eBay, Amazon, Salesforce.com. Now, it turns out in the fullness of time that word processing, spreadsheets, and presentation apps are also moving into the web -- as Google is demonstrating. But way before that happened, the web led people to create lots of new kinds of applications that were not possible on the PC.

A new platform typically enables a new set of applications that were not previously possible. Why else would there be a need for a new platform?

But: keep this in mind; look for the new applications that a new platform makes possible, as opposed to evaluating the new platform on the basis of whether or not you see older classes of applications show up on it right away.

Third, lots and lots of people have opinions about platforms, but the people whose opinions matter are programmers, and people who can make decisions about what programmers program.

This sounds incredibly elitist, to which I say: first, the whole point of platforms is that they let people program on them. So people who aren't programming, or making decisions about programmers programming on them, don't have a lot to do with them, and often don't know what they're talking about. Second, is is really easy to learn how to program -- in fact, it's never been easier. So there's really no excuse for anyone who wants to have opinions to not learn to program -- in fact, that's a great excuse to learn how to program!

And on that note, I'm going to go to sleep now and dream about "for" loops and "if/then" statements.

In a previous post I discussed Facebook's new platform approach, and described it as a turbocharged way to inject new content and features into Facebook from external services.

And I described at length some of the complexities involved in doing so, including scaling.

Tonight, my own company, Ning, released a new service that makes it trivially easy to inject your content -- videos, photos, and music -- into Facebook in such a way that:

Enough with the bullet points -- here's a screencast:

Missing screencast here!

In a nutshell, it works like this:

That's it -- your videos, photos, and music can now be introduced into Facebook by any user and spread throughout Facebook and beyond.

As far as we're aware, this is the first time anyone can create an application on Facebook without knowing any code or setting up an application on your own servers -- and really shows off the flexibility of the Ning platform.

Let's see it in action -- here's what a social network on Ning looks like, in this case a Smashing Pumpkins fans social network called Pumpkins Central. You'll see that this social network includes video that a user has uploaded.

Here's how a user adds that video to her Facebook page -- this should look familiar, this is just how users add any application on Facebook today:

And here's a user's Facebook page with that video embedded -- notice that the Pumpkins Central branding is maintained:

When the user -- Kyle in this case -- clicks on the Pumpkins Central logo in the video player, he will go to the origin page for the video on the Pumpkins Central social network -- not some other random place.

A live example: assuming you already have a Facebook account, go here to add a photo slideshow from Kyle Ford, a product manager at Ning.

Check it out, and if you have any questions or issues, please join us at the Ning Network Creators social network or visit Ning Help.

Other links on this topic:

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:

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!

Appendix -- some interesting links:

There are a ton of free cheatsheets, quick references, and downloadable resources for programming languages and related technologies online -- in this post I've tried to organize and list some of the best for web development.

I've focused on HTML, CSS, Javascript, and PHP, since those are the languages we use most commonly at Ning, but many of these sites point to resources for other languages as well.

As far as I can tell, all of the material assembled here is freely available. I've tried to avoid anything that points to pirated or illegal content. Please let me know if you see anything that isn't supposed to be free and I'll remove it from the list.

Please post suggested additions to this list as comments!

Meta-reference sites -- organized lists of references and cheatsheets:

http://www.gotapi.com/
A wonderful online API reference covering many programming languages.

http://www.digilife.be/quickreferences/quickrefs.htm
An organized list of quick references and cheatsheets.

http://techcheatsheets.com/
A great site with links to cheatsheets on lots of programming languages.

http://refcards.com/
Another great site organizing various cheatsheets.

http://whatis.techtarget.com/definition/0,289893,sid9_gci826135,00.html
A very long and thorough set of links to cheatsheets all over the web.

Other meta-reference sites:

http://mypage.bluewin.ch/yuppi/links/cheatsheets.html
http://www.petefreitag.com/item/455.cfm
http://www.smashingmagazine.com/2006/10/30/cheat-sheet-round-up-ajax-css-latex-ruby/
http://www.fuzzyfuture.com/programming/the-developer-cheat-sheet-compilation/
http://lorelle.wordpress.com/2005/10/10/html-css-php-and-more-cheat-sheets/
http://3spots.blogspot.com/2005/10/cheatsheets.html
http://webdeveloper.econsultant.com/cheat-sheets/

Key providers of cheatsheets:

http://www.visibone.com/
Visibone, the company that makes the best commercial cheatsheets for HTML, CSS, colors, etc. Site includes free resources and downloadable versions of several great cheatsheets.

http://www.ilovejackdaniels.com/cheat-sheets/
Original cheatsheets for HTML, CSS, PHP, and other technologies.

http://www.deepx.com/resources/quickref/
Original cheatsheets for CSS, XML, and related technologies.

HTML cheatsheets:

http://html-tags.info/
Free version of Visibone's HTML cheatsheet.

http://www.ucc.ie/doc/World-Wide_Web/htmlcard.html
HTML cheatsheet from Andrew Ford.

http://www.utoronto.ca/ian/books/extras/html-7nov2000.pdf
HTML cheatsheet from Ian Graham.

http://www.ilovejackdaniels.com/cheat-sheets/html-cheat-sheet/
HTML cheatsheet from ILoveJackDaniels.

http://gosquared.com/liquidicity/archives/51
HTML cheatsheet from Liquidcity.

http://www.htmlgoodies.com/beyond/reference/article.php/3472851
Maran Wilson's HTML cheatsheet.

http://www.cdburnerxp.se/htmlcheatsheet.pdf
Florian Schmitz's HTML cheatsheet.

http://www.arnspub.com/QuickRef/
An online reference to HTML organized by tag.

http://www.blooberry.com/indexdot/html/index.html
Brian Wilson's online HTML reference.

http://www.ilovejackdaniels.com/cheat-sheets/html-character-entities-cheat-sheet/
ILoveJackDaniels' HTML character entities cheatsheet.

CSS cheatsheets:

http://www.deepx.com/resources/quickref/CSS-1.0.pdf
CSS cheatsheet from DeepX.

http://www.utoronto.ca/ian/books/extras/css1-sheet-7nov2000.pdf
CSS cheatsheet from Ian Graham.

http://www.ilovejackdaniels.com/cheat-sheets/css-cheat-sheet/
CSS cheatsheet from ILoveJackDaniels. (And really, who doesn't?)

http://www.gosquared.com/liquidicity/archives/33
CSS cheatsheet from Liquidcity.

http://www.spectrum-research.com/V2/projects_css_reference.asp
CSS cheatsheet from Spectrum Research.

http://www.veign.com/downloads/guides/qrg0007.pdf
CSS cheatsheet from Veign.

http://home.tampabay.rr.com/bmerkey/cheatsheet.htm
CSS cheatsheet from Brett Merkey.

http://lesliefranke.com/files/reference/csscheatsheet.html
CSS cheatsheet from Leslie Franke.

http://www.lazycat.org/webdesign/cssref.php
CSS cheatsheet from Matt Robinson.

http://www.blooberry.com/indexdot/css/index.html
Online CSS reference from Brian Wilson.

http://meyerweb.com/eric/css/references/css1ref.html
http://meyerweb.com/eric/css/references/css2ref.html
CSS online references from Eric Meyer.

http://www.design215.com/toolbox/css_guide.php
A detailed overview of CSS from 2006 that covers features that work on most browsers.

Javascript cheatsheets:

http://wps.aw.com/wps/media/objects/2234/2287950/javascript_refererence.pdf
Addison-Wesley Javascript cheatsheet.

http://sage.math.washington.edu/home/agc/lit/javascript/javascriptcheatsheet.pdf
Javascript cheatsheet from Holmer Hemsen.

http://www.ilovejackdaniels.com/cheat-sheets/javascript-cheat-sheet/
Javascript cheatsheet from ILoveJackDaniels. (I really don't understand how he produces so many cheatsheets, drinking as much Jack as he must.)

http://www.mytechsupport.ca/tools/docs/JavaScript_Quick_Reference.pdf
Luke Terheyden's Javascript cheatsheet.

http://javascript-reference.info/
Visibone's free Javascript reference card.

http://www.visibone.com/regular-expressions/
Visibone's free Javascript regular expressions card, focused on Javascript.

http://www.quirksmode.org/js/contents.html
Extensive assortment of Javascript references on various topics.

Browser compatibility matrices:

http://www.quirksmode.org/dom/compatibility.html
http://www.quirksmode.org/css/contents.html
Comprehensive browser compatibility matrices for DOM, HTML, CSS, and event handling.

Colors:

http://www.visibone.com/colorlab/
Visibone's free interactive web color picker.

http://html-color-codes.com/
Visibone's free web color quick reference guide.

http://www.veign.com/downloads/guides/qrg0006.pdf
Veign's web color reference guide.

PHP cheatsheets:

http://www.ilovejackdaniels.com/cheat-sheets/php-cheat-sheet/
PHP cheatsheet from ILoveJackDaniels.

http://www.stevengould.org/portfolio/independent/php-refcard/PHPRefCard.pdf
PHP 4 reference card from Steven Gould.

BONUS -- Google cheatsheets:

http://www.google.com/help/cheatsheet.html
Official Google cheatsheet.

http://www.googleguide.com/advanced_operators_reference.html
Google advanced operators cheatsheet from Google Guide.

BONUS -- free downloadable programming books:

http://freecomputerbooks.com/
Outstanding site organizing links to many free programming books, tutorials, and lecture notes.

http://www.freetechbooks.com/
Another organized set of links to free programming books.

Other sites for free programming books:

http://www.techtoolblog.com/archives/195-free-online-programming-books
http://www.computer-books.us/
http://www.onlinecomputerbooks.com/