Wednesday, October 31, 2007

Analyzing the Facebook Platform, three weeks in [by Marc Andreessen]

Jun 12, 2007
http://blog.pmarca.com/2007/06/analyzing_the_f.html

On May 24, Facebook launched the newest version of the Facebook Platform, a set of application programming interfaces (APIs) and services that allow outside developers to inject new features and content into the Facebook user experience.

In this post, I provide an overview and analysis of the Facebook Plaform and what we have learned about it in the three weeks since it launched.

To start, my personal opinion is that the new Facebook Platform is a dramatic leap forward for the Internet industry.

Here's why:

Veterans of the software industry have, hardcoded into their DNA, the assumption that in any fight between a platform and an application, the platform will always win.

Definitionally, a "platform" is a system that can be reprogrammed and therefore customized by outside developers -- users -- and in that way, adapted to countless needs and niches that the platform's original developers could not have possibly contemplated, much less had time to accommodate.

In contrast, an "application" is a system that cannot be reprogrammed by outside developers. It is a closed environment that does whatever its original developers intended it to do, and nothing more.

The classic example of an application being vanquished by a platform was the Wang word processor versus Microsoft DOS-based personal computers.

Wang word processors -- the application, in this case -- were highly evolved, fantastically successful dedicated word processing systems that owned their market, until the general-purpose PC came along. While the PC at first was inferior at word processing, within a few years of its launch the fact that outside developers had built thousands of applications for it -- like spreadsheets -- that closed Wang word processors could not match, coupled with steadily improving PC-based word processing software like Wordstar, had all but killed the Wang word processor. Wang -- one of the most succcessful technology companies of the 1970's -- went bankrupt not long after.

This is a story whose moral has historically not been embraced by the web industry to nearly the extent one would have thought.

The web, after all, vanquished proprietary online services like America Online, Prodigy, and Compuserve -- the so-called "walled gardens" -- in large part because the web is a platform and the walled gardens were not. No single closed service, no matter how good, and no matter how big, could compete with the diversity of thousands and then millions of web sites that were customized to every conceivable user interest and need.

Yet most major web busineses have not themselves sought to become platforms.

Sure, some have released APIs -- some have even released very sophisticated APIs -- but such APIs have mostly been for interacting with a web system from the outside. Those APIs have been a far cry from the programmability and customizability enabled by a true platform in the sense that the software industry has come to understand it.

Instead, most major web businesses have sailed along without the added lift from platform-style programmability that they could have had at any point.

Until now.

In a nutshell, the Facebook API enables outside web developers to inject new features and content into the Facebook environment.

After signing up for a developer account on Facebook, the developer writes a web application (in the simplest case, a piece of web content; in the most advanced case, a full fledge web application with deep functionality) and hosts it on her own servers. The developer then registers her application with Facebook, and then users can add that application to their Facebook user experience in several different ways, including within their Facebook profile pages.

Viewed simply, this is a variant on the "embedding" phenomenon that swept MySpace over the last two years, and which Facebook prohibited.

However, what Facebook is now doing is a lot more sophisticated than simply MySpace-style embedding: Facebook is providing a full suite of APIs -- including a network protocol, a database query language, and a text markup language -- that allow third party applications to integrate tightly with the Facebook user experience and database of user and activity information.

And then, on top of that, Facebook is providing a highly viral distribution engine for applications that plug into its platform. As a user, you get notified when your friends start using an application; you can then start using that same application with one click. At which point, all of your friends become aware that you have started using that application, and the cycle continues. The result is that a successful application on Facebook can grow to a million users or more within a couple of weeks of creation.

Finally, Facebook is promising economic freedom -- third-party applications can run ads and sell goods and services to their hearts' content.

Metaphorically, Facebook is providing the ease and user attraction of MySpace-style embedding, coupled with the kind of integration you see with Firefox extensions, plus the added rocket fuel of automated viral distribution to a huge number of potential users, and the prospect of keeping 100% of any revenue your application can generate.

The leadership that the Facebook team is showing here rivals anything that the large and established software and web companies have done in this decade.

You may also notice the irony of Facebook leapfrogging MySpace on embedding at the same time that MySpace seems to be getting substantially more restrictive, in some cases even shutting down third-party widgets.

Let's look at some of the key aspects of the Facebook Platform in more detail.

First, perhaps the most architecturally interesting aspect of the Facebook platform is the fact that everything routes through Facebook's servers.

This is known as a "proxy" model -- you interact with a third-party Facebook application by interacting with Facebook's servers which turn interact with the application's servers.

There are very sharp pros and cons to this approach, contrasted with the MySpace model where third-party content is pulled directly from third-party servers.

Pros:

Facebook retains much tighter control of the overall user experience. Applications must conform to Facebook guidelines for appearance and content or they are disallowed.

Facebook can provide third-party pages with integral access to Facebook user and activity information -- the application can easily be aware of who your Facebook friends are, for example. This allows the applications to be considerably more powerful in the context of a social network than a simple piece of embedded content.

Facebook can cache static content such as images and videos and thereby serve them up faster, improving the overall user experience.

Cons:

Facebook retains much tighter control of the overall user experience. Applications must conform to Facebook guidelines for appearance and content or they are disallowed. Yes, this is also listed above under "Pros".

Performance will generall be slower than a non-proxy model. There are additional network hops for each access of a third-party application, which causes additional latency. Plus, Facebook's servers do a lot of processing of the third-party content that they are passing back and forth: they essentially rewrite every page on the fly to implement the added features (e.g. FBML) and restrictions (e.g. no Javascript; div's are rewritten) that they provide. This processing inevitably takes time.

On balance, of course, this is a fine set of tradeoffs that accommodate Facebook's dual goals of opening up their environment but in carefully controlled ways, and may well serve as a powerful precedent for how other web businesses will open themselves in the future.

Second, Facebook has really thought through the API suite it provides to developers.

You get a REST web services API that lets your application programmatically interact with Facebook's systems and data in very interesting ways. Developers who understand web services can pick it up in about five minutes.

You get a database query language called FQL -- a variant of SQL -- that lets you interact with Facebook's databases directly. Developers who are experienced with relational databases and SQL will be right at home.

And, you get a text markup language called FBML -- a variant of HTML. FBML strips out some features of HTML, such as Javascript, and adds a new set of features that enable a third-party application page to access Facebook features, data, and look and feel elements in a variety of interesting ways. Anyone who knows HTML can take advantage of it immediately.

This is a very sophisticated yet easy to adopt suite of APIs for a brand new platform, and demonstrates real seriousness of purpose.

Third, there are three very powerful potential aspects of being a platform in the web era that Facebook does not embrace.

The first is that Facebook itself is not reprogrammable -- Facebook's own code and functionality remains closed and proprietary. You can layer new code and functionality on top of what Facebook's own programmers have built, but you cannot change the Facebook system itself at any level.

The second is that all third-party code that uses the Facebook APIs has to run on third-party servers -- servers that you, as the developer provide. On the one hand, this is obviously fair and reasonable, given the value that Facebook developers are getting. On the other hand, this is a much higher hurdle for development than if code could be uploaded and run directly within the Facebook environment -- on the Facebook servers.

The third is that you cannot create your own world -- your own social network -- using the Facebook platform. You cannot build another Facebook with it.

I won't dwell on these three factors too much right now. Those of you familiar with Ning may, however, expect me to revisit them in the future, and I will :-).

These factors are, however, very reflective of the fact that while the Facebook Platform gives developers a lot of capabilities that they never had before, and access to a huge base of enthusiastic users, as a Facebook developer you're very much living in Facebook's world -- you're not creating your own world. And you have to be serious enough about living in that world that you are willing to hit the fairly high barrier of being willing to run your own servers and infrastructure for any applications you build.

Which takes us to...

Fourth, and perhaps most significantly, when your application takes off on Facebook, you are very happy because you have lots of users, and you are very sad because your servers blow up.

Let me explain.

I already described Facebook's viral distribution mechanism by which users became instantly aware of which applications their friends are using, can with one click start using those applications, and automatically spread them to their friends.

This is happening in an environment with 24 million active users -- active users defined as users active on the site in the last 30 days. 50% of active users return to the site daily. 100,000 new users join per day. 45 billion page views per month and growing. 50 million users, and a lot more page views, predicted by the end of 2007.

An application that takes off on Facebook is very quickly adopted by hundreds of thousands, and then millions -- in days! -- and then ultimately tens of millions of users.

Unless you're already operating your own systems at Facebook levels of scale, your servers will promptly explode from all the traffic and you will shortly be sending out an email like this.

ILike was the first third-party application to get serious lift-off on Facebook. Quoting from ILike's blog shortly after their launch:

In our first 20 hours of opening doors we had 50,000 users sign up, and it is only accelerating. (10,000 users joined in the first 12 hrs. 10,000 more users in the next 3 hrs. 30,000 more users in the next 5 hrs!!)
We started the system not knowing what to expect, with only 2 servers, but ready with backup. Facebook's rabid userbase chewed up our 2 servers almost instantly. We doubled our capacity to catch up. And then we doubled it again. And again. And again. Oh crap - we ran out of servers!! Although iLike.com has a very healthy level of Web traffic, and even though about half of all the servers in our datacenter were sitting unused, idle, as backup capacity, we are now completely maxed out.

We just emailed everybody we know across over a dozen Bay Area startups, corporations, and venture firms in a desperate plea to find spare servers so we can triple our capacity for the continued onslaught. Tomorrow we are picking up over 100 servers from different companies to have them installed just to handle the weekend's traffic. (For those who responded to our late night pleas, thank you!)

Yesterday, about two weeks later, ILike announced that they have passed 3 million users on Facebook and are still growing -- at a rate of 300,000 users per day.

They didn't say how many servers they're running, but if you do the math, it has to be in the hundreds and heading into the thousands.

Translation: unless you already have, or are prepared to quickly procure, a 100-500+ server infrastructure and everything associated with it -- networking gear, storage gear, ISP interconnetions, monitoring systems, firewalls, load balancers, provisioning systems, etc. -- and a killer operations team, launching a successful Facebook application may well be a self-defeating proposition.

This is a "success kills" scenario -- the good news is you're successful, the bad news is you're flat on your back from what amounts to a self-inflicted denial of service attack, unless you have the money and time and knowledge to tackle the resulting scale challenges.

Will every Facebook application go through this?

No, of course not. The ones that nobody uses will not have this problem.

But the successful ones all will.

The implication is, in my view, quite clear -- the Facebook Platform is primarily for use by either big companies, or venture-backed startups with the funding and capability to handle the slightly insane scale requirements. Individual developers are going to have a very hard time taking advantage of it in useful ways.

Fifth, there's the fascinating issue of the Facebook application directory -- the page from which users can pick which applications they want to use.

When you develop a new Facebook application, you submit it to the directory and someone at Facebook Inc. approves it -- or not.

If your application is not approved for any reason -- or if it's just taking too long -- you apparently have the option of letting your application go out "underground".

This means that you need to start your application's proliferation some other way than listing it in the directory -- by promoting it somewhere else on the web, or getting your friends to use it.

But then it can apparently proliferate virally across Facebook just like an approved application.

There is already long list of underground apps that you can use -- and proliferate.

It will be fascinating to see how Facebook deals with this -- will they embrace underground apps, or move to shut them down?

The answer will go a long way towards understanding the true level of freedom that developers have on the Facebook Platform.

In closing:

Congratulations to the Facebook team -- big time! -- for an amazing leap forward in what the Internet can do for real users and for opening up whole new vistas of opportunities for third-party developers.

This is an amazing achievement -- one of the most significant milestones in the technology industry in this decade.

Clarifications and expansions:

In conversations with the folks at Facebook, there are a few clarifications and expansions I'd like to note:

First, my statement that "applications must conform to Facebook guidelines for appearance and content or they are disallowed" is partially but not entirely true. Boxes that contain content from an application on a user's Facebook profile page must be rendered via FBML and have tight controls over what can be included, particularly the no-Javascript limitation. On the other hand, so-called "canvas" pages -- the pages dedicated completely to a specific application, and accessible via the left-hand-side app navigation area, can be rendered either via FBML (which is restrictive), an iframe that can include arbitrary content, or a combination of the two. From an iframe you do pretty much whatever you want, but you don't get the FBML features.

Note that you are incented to use FBML because that's the easiest way to achieve integration between your application and Facebook -- e.g. to let your app have access to information about the user and her friends. FBML is clearly a good thing; it's just that when you're using it, you can't do certain other things that you're used to. And, as noted, you are required to use it for content that shows up on users' profile pages.

Second, my point that "success kills" -- that a successful, widely used application will require a large number of servers to run, at best, and will fall over and die, at worst -- is true, but the Facebook folks point out that as an app developer you have a lot of control over how fast your application grows. You don't have to light up all the viral spread features all at once, for example.

I would counter-argue that deliberately tamping down the growth rate doesn't do you any favors either -- then you don't get widely used, which for most apps is the whole reason to exist.

My larger point is that if your app succeeds on Facebook, expect to have to do a lot of heavy lifting on your back end and to spend a lot of money on hardware and bandwidth -- just like if you built a web app that succeeded outside Facebook, of course.

Some commenters have proposed that Amazon's EC2 service would be a way to easily scale a Facebook app (or a non-Facebook web app). I think EC2 is a great service and have no desire to say anything negative about it. So I will just say two things: it isn't as easy as that, and EC2 is not free either. Bonus points to commenters who want to go into more detail on these topics than I have here!

Appendix -- some interesting links:

Leaked Google Video Discusses Google Reader, Social Efforts

2007-09-11

http://blogoscoped.com/archive/2007-09-11-n21.html

A video disclaimed to be "Google - Confidential" with the title "Nooglers And The PDB: Reactor (Ben Darnell, September 6, 2007)" made its way onto a public Google Video page. A "noogler" is what people at Google call new employees; "Reactor" is Google's codename for the back-end to Google Reader, the video says, and someone posting under the nickname "Fanboy" in this blog's forum provided us with a nutshell of the talk. While the video has been removed by now, others – including Ionut Alex. Chitu, who also blogged on this in the meantime – were able to see it, and I've also got hold of a copy.

Now, I can confirm that projects by the name of "Mustang" and "Mocha", as mentioned in the nutshell, exist within Google; I can also confirm that a Ben Darnell works at Google (update: I now have reason to believe it's spelled "Maka-Maka", even though as mentioned something called "Mocha" does exist within Google). This and other details make it look like the video is real indeed. Following is Fanboy's nutshell (my emphasis):

Google will work on a standard for feed publishers to tell aggegrators about changes in the feed ('this post has been deleted' etc.). Such a standard doesn't exist yet. They will be working with blog tools like Blogger and MovableType.

2/3 of the content has only one subscriber. Think about feeds for own-name-searches, own blogs and blog comments. There are feeds with up to tens of millions of subscribers. The crawl rate of feeds is prioritized when they've got more subscribers. They're updated within one hour when there's more than one subscriber, or else once in three hours.

The feed backend now contains 10 terabytes of raw data from 8 million feeds. The index size grows with 4% a week, but this number is probably not accurate.

Currently the standard distributed database called BigTable is mostly used. For search Mustang is currently used, Google's library for creating search engines. Mustang underlies the web search and most other search engines, except for Gmail's search feature as that requires instant updates and a specific index for each user. Mustang currently handles 1-2 search queries per second, but is able to handle thousands.

The Reader team is going to integrate more social features. Currently items can be sent to friends by email, and there are no plans for creating a Reader-inbox for that.

Google's recent big social effort is called Mocha-Mocha (or Mocka-Mocka?), and will become the infrastructure for all social stuff across all of their applications. As a part of this, a new feature called Activity Streams will be introduced or at least implemented in Reader this quarter. This will be comparable to Facebook's News Feed (Minifeed?) feature, and integrate Gmail's addressbook and contact list.

Also there will be some other Gmail and Orkut integration, but this might just mean there will be links to Reader.

Google is interested in allowing users to comment on items they share, but this currently isn't a priority.

Calling tags 'labels' is called 'kind of a historic accident and needlessly confusing'.

When you press the 'Mark all as read' button, Google remembers that you've 'read' all items between two timestamps. You can never uncheck the 'Mark as read' checkbox for those items.

Currently there is no plan to integrate Reader with Universal Search. This is because Universal Search doesn't provide its backends with user IDs (so Gmail results can't be shown either), and because it requires a lookup time of less than 1/4 second, which Reader cannot provide yet.

When searching in Reader, you may also get results from before you aren't subscribed to anymore, or from your friends' items. This is intentional, but by some users considered as a bug.

Three people are working on Reader's backend, and three plus one intern are working on the frontend.

Very soon, Reader will recommend feeds to the user, based on previous subscriptions and other Google activity.

Next week, Reader will be released in several languages. One month after that, it will be available in 40 languages.

According to FeedBurner statistics, Google Reader is the world's largest full-content reader. My Yahoo is the largest headline reader, [but] also iGoogle is big. As Google has grown into the market, the usage of Bloglines hasn't really decreased much.

Reader has a loyal user base (based on pageviews per user), higher than any other product except for Gmail and Orkut. 70 % of the users use Firefox, so feed syndication is still mostly a geek thing.

Feeds are currently monetized by FeedBurner. Reader might be more directly monetized in the future, but Google wants to watch out showing ads next to other people's content. This is a problem with Google News too. They might do something like they did with the non-free Opera: show the content owners' ads in the interface when they're AdSense publishers. Google wants to make publishing full articles in feeds more interesting to webmasters by creating ways to monetize them.

[Thanks Fanboy!]

ATT Internet Break-thru [by Marc Andreessen]

Este artigo é importante demais, estou reproduzindo em vermelho as partes que devemos fixar para que fiquemos "na mesma página" daqui pra frente.

O autor é o Marc Andreessen, o cara que inventou o browser. Ele têm visão, you bet!

Open Social: a new universe of social applications all over the web

Oct 31, 2007

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:

"Containers" -- social networking systems like Ning, Orkut, LinkedIn, Hi5, and Friendster, and...
"Apps" -- applications that want to be embedded within containers -- for example, the kinds of applications built by iLike, Flixster, Rockyou, and Slide.

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

With the Facebook platform, only Facebook itself can be a "container" -- "apps" can only run within Facebook itself. In contrast, with Open Social, any social network can be an Open Social container and allow Open Social apps to run within it.
With the Facebook platform, app developers build to Facebook-proprietary languages and APIs such as FBML (Facebook Markup Language) and FQL (Facebook Query Language) -- those languages and APIs don't work anywhere other than Facebook -- and then the apps can only run within Facebook. In contrast, with Open Social, app developers can build to standard HTML and Javascript, and their apps can then run in any Open Social container.

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:

One set of standard HTML and Javascript pages for consumption by normal web browser.
Another set of HTML and Javascript pages that use the Open Social API's Javascript calls for consumption with Open Social containers/social networks.
A third set of pages in FBML (Facebook Markup Language) that use Facebook's proprietary APIs for consumption within Facebook as a Facebook app.
Perhaps a fourth set of pages adapted for the Apple iPhone and/or other mobile devices.

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:

Being an outstanding container. Open Social apps will be able to run easily and reliably inside Ning social networks -- all 113,000+ of them. Ning Network Creators will be able to quickly and easily add Open Social apps to their networks, and Ning users will be able to quickly and easily add Open Social apps to their profile pages.
Being an app publisher. Ning already automatically produces Facebook apps for every Ning network -- specifically, video, photo, and music players -- using the Facebook proprietary platform approach. We will do the exact same thing for Open Social -- we will automatically produce Open Social apps for every Ning network.
Being an outstanding environment within which you can build new Open Social apps. More on that a bit later!

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:

You can write purely to the Open Social API. If you do this cleanly enough, your app will run unchanged in any compliant Open Social container. (Google is actually not making this claim -- they're calling Open Social "learn once, write anywhere", which is not the same as "write once, run anywhere". But in practice, the API is simple enough that "write once, run anywhere" should work just fine.)
You can write an app that is specific to one container. For example, there may be some apps that make sense only in LinkedIn -- business-related apps, say. There may be other apps that make sense only in Ning -- apps that presume that users are creating their own social networks, say. And there may be yet other apps that only make sense in Salesforce.com, which will also be an Open Social container. In those cases, you are targeting your app to one specific container, and so using whatever additional APIs that particular container provides, in addition to the Open Social APIs, is a no-brainer.
Finally, you can write an app that behaves differently depending on which of several containers it's running in. Your app just discovers which container it's running in, and then does whatever it wants on a per-container basis.

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!

Google APIs Watch

updated: redirecting default page to ./more (are they editing to include OpenSocial???)

SocialStream - An Introduction to the Project [X2: a.k.a. OpenSocial]

index.php

Socialstream is the result of a Google-sponsored capstone project in the Master's program at Carnegie Mellon University's Human-Computer Interaction Institute. This project was guided by three goals that built upon each other:

Initial Task: Rethink and reinvent online social networking

Refined Focus: Discover the user needs related to social networking and explore how a unified social network service can enhance their experience.

Prototype Goal: Create a system for users to seamlessly share, view, and respond to many types of social content across multiple networks.

Directed to help improve the online community orkut, the project's scope was not to simply redesign the interface. Our team considered how online social networking could bring greater value to users, especially for ages above twenty. After initial brainstorming and research, we chose to focus on the effects of a new model for online social networking: a unified social network that, as a service, provides social data to many other applications. Our user research examined needs related to online as well as offline social networking and considered how they related to a unified social network service model. Through this user research we identified a set of archetypes that represent common behavior patterns that existed across multiple study participants and also formulated a summarized list of their high level needs.

Socialstream is our response to these needs; it is the result of a rigorous user-centered design process that involved formal research and evaluation with over 30 participants.

To explore our final prototype, please visit the solution section.

NYT Google and Friends to Gang Up on Facebook

http://www.nytimes.com/2007/10/31/technology/31google.html?_r=1&oref=slogin

By MIGUEL HELFT and BRAD STONE

Published: October 31, 2007

SAN FRANCISCO, Oct. 30 — Google and some of the Web's leading social networks are teaming up to take on the new kid on the block — Facebook.

On Thursday, an alliance of companies led by Google plans to begin introducing a common set of standards to allow software developers to write programs for Google's social network, Orkut, as well as others, including LinkedIn, hi5, Friendster, Plaxo and Ning.

The strategy is aimed at one-upping Facebook, which last spring opened its service to outside developers. Since then, more than 5,000 small programs have been built to run on the Facebook site, and some have been adopted by millions of the site's users. Most of those programs tap into connections among Facebook friends and spread themselves through those connections, as well as through a "news feed" that alerts Facebook users about what their friends are doing.

The New York Times learned of the alliance's plan from people briefed on the matter. Google, which had planned to introduce the alliance at a party on Thursday evening, later confirmed the plan.

"It is going to forestall Facebook's ability to get everyone writing just for Facebook," said a person with knowledge of the plans who asked to remain anonymous because he was not authorized to speak on behalf of the alliance. The group's platform, which is called OpenSocial, is "compatible across all the companies," that person said.

"Facebook got the jump by announcing the Facebook platform and getting the traction they got. This is an open alternative to that," the person also said.

The alliance includes business software makers Salesforce.com and Oracle, who are moving to let third-party programmers write applications that can be accessed by their customers. The start of OpenSocial comes just a week after Google lost to Microsoft in a bid to invest in Facebook and sell advertising on the social network's pages outside the United States. And it comes just before the expected introduction by Facebook of an advertising system next week, which some analysts believe could compete with Google's.

Joe Kraus, director of product management at Google, said that the alliance's conversations preceded Microsoft's investment in Facebook. "Obviously, we would love for them to be part of it," Mr. Kraus said of Facebook. Facebook declined to comment.

Facebook's success with its platform has proved that the combination of social data and news feeds is a powerful mechanism to help developers distribute their software. They are now seen as must-have functions for many Internet companies. Other social networks and Web companies, including MySpace and the instant messaging service Meebo.com, have announced plans to open their sites in similar ways.

For now, however, Facebook has become the preferred platform for software developers.

By teaming with others, Google hopes to create a rival platform that could have broad appeal to developers. A person briefed on the plans said the sites in the alliance had a combined 100 million users, more than double the size of Facebook.

The developers of some of the most popular Facebook applications, including iLike, Slide, Flixter and RockYou, are expected to be present Thursday evening at Google's headquarters in Mountain View, Calif., where they will announce that they will tailor their programs to run on the OpenSocial sites.

The effort faces several hurdles. Developers may not see the advantage to writing programs that run across such remarkably different networks as, for example, LinkedIn, which caters to business professionals, and hi5, which is popular in Central America.

For Google, the effort could breathe new life into Orkut, which is popular in Brazil and other countries, but not in the United States. While the move could also help some rival social networks, Google could benefit from their success, in part, by helping to sell advertising on those sites.

Indeed, that strategy would fit into a model that Google has begun talking about recently. Vic Gundotra, who heads Google's developer programs, said last week that Google would soon begin an aggressive project to create software tools and give them away free in an open-source format.

The goal, he said, is to improve not just Google's applications, but any software that runs on the Web. That, in turn, would drive more Internet use, and Google would benefit indirectly by selling advertising, he said.

Google has not been able to establish itself as a force in social networking, and it clearly wants to. "One of the things to say, very clearly, is that social networks as a phenomenon are very real," Eric E. Schmidt, Google's chief executive, said in a recent interview. "If you are of a certain age, you sort of dismiss this as college kids or teenagers. But it is very real."

Google said it has advertising relationships with several social networks, including a $900 million partnership to sell ads on MySpace, which the company said is performing well. Google is also making some money on Facebook, through ads that run inside applications that are used on that network.

A person familiar with Google's efforts said that those applications have been far more effective for advertisers on social networks than users' personal pages. "It is early, but those ads work very well, whereas the ads in overall social media platforms have shown less performance," the person said. Mr. Kraus said that over time Google hoped to bring other social elements to Web applications, whether or not they run inside social networks. Analysts expect other Google services, including iGoogle, to be equipped with social features eventually.

Google Announces OpenSocial, an API Connecter For Social Networks

Google has decided that when it comes to Facebook, if you can't beat 'em, API 'em. Google's OpenSocial, which will launch at code.google.com/apis/opensocial tomorrow, will be a set of APIs that developers can use to create applications that work on any participating social network. Google's goal is to create an open layer that runs atop all social networks, diminishing the power of all the networks in the process.

It's a smart plan, especially with the "fad" nature of most social networks, giving up on trying to have the most popular social network and instead trying to be the application layer that everyone uses. Google failed to buy Facebook, it'll never get MySpace, Orkut will never be popular in the U.S., and a year from now, some unpredictable new network could be the new Facebook. Even if Facebook doesn't use OpenSocial, new startups will use it, ensuring the next Facebook is a Google partner, not a competitor.

OpenSocial is a set of three common APIs, handling profile information, friend/social graph data, and activity data (news feeds). All participating networks have to do is agree to accept the API calls and give back the requested data, and all that does is the hugely important step of opening up the data in the networks to be used by external applications, or by other social networks.

At launch, participating social networks are Google's own Orkut, plus Ning, Plaxo, Friendster, viadeo, Hi5, LinkedIn and Oracle. Application providers already signed up are Flixster, iLike, RockYou and Slide, already the most popular Facebook developers, making it likely that the most popular third party Facebook features could soon be arriving at its competitors. The presence of Google's Orkut, hugely popular outside he U.S., will be enough to make OpenSocial important despite lacking Facebook and MySpace.

One thing OpenSocial doesn't do is let one social network access the data from another network, something Marc Canter has been pushing for lately. While the applications can use profile, friend and activity data, it can't actually grab it and create a profile on a another network, like taking your LinkedIn data and using it to build a Friendster profile. You'll still need to sign up with and create a profile on every network seperately.

Also participating are ING, Hyves, Tianji and Salesforce.com. There will be a developer sandbox at sandbox.orkut.com. No word on if Yahoo plans to participate, and you can expect Microsoft to stay out of it (Windows Live Spaces is a major social network, and Microsoft's Facebook ownership stake will make it want to stay out of this war).

The draft press release, reprinted from VentureBeat, after the jump:

MOUNTAIN VIEW, CA — November 1, 2007 – Google, Inc. (NASDAQ: GOOG) today announced the release of OpenSocial — a set of common APIs for building social applications across the web — for developers of social applications and websites that want to add social features. OpenSocial will unleash more powerful and pervasive social capabilities for the web, empowering developers to build far-reaching applications that users can enjoy regardless of the websites, web applications, or social networks they use. The release of OpenSocial marks the first time that multiple social networks have been made accessible under a common API to make development and distribution easier and more efficient for developers.

The proliferation of unique APIs across dozens of social websites is forcing developers to choose which ones to write applications for – and then spend their time writing separately for each. OpenSocial gives developers of social applications a single set of APIs to learn for their application to run on any OpenSocial-enabled website. By providing these simple, standards-based technologies, OpenSocial will speed innovation and bring more social features to more places across the web. Users win too: they get more interesting, engaging, or useful features faster.

"The web is fundamentally better when it's social, and we're only just starting to see what's possible when you bring social information into different contexts on the web," said XXXX. "There's a lot of innovation that will be spurred simply by creating a standard way for developers to run social applications in more places. With the input and iteration of the community, we hope OpenSocial will become a standard set of technologies for making the web social."

Learn Once, Reach Across the Web

One of the most important benefits of OpenSocial is the vast distribution network that developers will have for their applications. The sites that have already committed to supporting OpenSocial — Website Partner A, Website Partner B, Website Partner C, etc. –- represent an audience of well over 100 million users globally. Critical for time- and resource-strapped developers is being able to "learn once, write anywhere" — learn the OpenSocial APIs once and then build applications that work with any OpenSocial-enabled websites.

Several developers, including Gadget Partner Z, Gadget Partner Y, Gadget Partner X, etc., have already built applications that use the OpenSocial APIs. Starting today, a developer sandbox is available at http://sandbox.orkut.com so developers can go in and start testing the OpenSocial APIs. The goal is to have developers build applications in the sandbox so they can deploy on Orkut and ultimately other OpenSocial sites.

More Social In More Places

The existence of this single programming model also helps websites who are eager to satisfy their users' interest in social features. More developers building social applications more easily translates directly into more features more quickly for websites.

"Orkut has tens of millions of passionate users who are constantly clamoring for new ways to have fun with their friends and express themselves through Orkut," said Amar Gandhi, group product manager for Orkut, Google's social networking service. "By using OpenSocial to open up Orkut as a platform for any developer, we can tap into the vast creativity of the community and make new features available to our users frequently."

The common method that OpenSocial provides for hosting social applications means that websites can engage a much larger pool of third party developers than they could otherwise. They can direct resources that might have gone to maintaining a proprietary API and supporting its developer community to other projects.

Because OpenSocial removes the hassle from developing for individual websites, developers can unleash their creativity anywhere that catches their interest. This will translate into a wave of social features in contexts outside of the personal entertainment and games that are traditionally thought of as the social web.

Three APIs available now

The OpenSocial APIs give developers access to the data needed to build social applications: access to a user's profile, their friends, and the ability to let their friends know that activities have taken place. OpenSocial resources for developers and websites are available now at code.google.com/apis/opensocial.

Developers will have access to:
- Three JavaScript and Gdata APIs to access social functions
- A live developer sandbox on Orkut at sandbox.orkut.com

Websites will have access to:
- A tool to help OpenSocial-enable their websites
- A support forum for communicating with Google and other websites

All of these resources and the live developer sandbox are available now.

Developers already at work

Dozens of developers have helped test early iterations of the OpenSocial APIs and Google is grateful for the extensive feedback they have provided.

[List of all gadget developers]

Links to these gadgets are available at http://code.google.com/apis/opensocial.

October 31st, 2007 Posted by Nathan Weinberg | MySpace, Orkut, Services | one comment

Tuesday, October 30, 2007

Using Press Releases to Get Free Publicity

How Can a Press Release Help You Get Free Publicity?

What is a Press Release?

A press release or, news release as it is also called, is a condensed article that is written in a journalistic style. A press release is not a sales document, resume, or an advertisement. The purpose of the news release is to highlight what is interesting and newsworthy about your company or organization. This can include announcing product releases, new services, or drama within your market.

What are the Press Release Costs?

Press releases are relatively inexpensive to prepare and distribute. Compare the price of a full-page ad from a major news publication – generally tens of thousands of dollars. Even local papers typically charge several thousand dollars. For less than a few hundred dollars, you can receive better, more comprehensive coverage than paid advertising. Research shows that most news releases generate a higher return than even high powered ad campaigns.

Free Publicity

When members of the news media feature your story pulled from your press release, free publicity is being generated. Frequently, your story can show up not only in one major newspaper, but in three, as well as in news talk shows carried on major networks such as NBC or CBS. If you are looking to publicize in local markets only, releases can be directed to those local publications and hit editor’s news feeds who write for your specific industry. If you are looking for global coverage, news releases are the best marketing tools. In a sense, a press release is a gift that just keeps giving.

News releases not only reach journalists but they also capture potential customers and/or investors which means that your products and/or services can be both funded and be made more profitable simply based on the media attention your release receives. Whatever your target audience may be, news releases offer you a way to become known to the public without a significant investment. Even large corporations who spend millions of dollars on ad campaigns continue to use news releases to maintain public interest which results in higher revenue.

Added Benefits for Sending a Press Release

Another advantage to sending out news releases is that there is always demand. All news organizations, to include magazine editors, broadcast, and industry specific editors use press releases to develop the bulk of their published news stories. From a consumer stand point, editors who report on your news release are considered disinterested parties, meaning that your announcement was chosen because of public demand for relevant and useful information. Often, paid advertising is suspect in the customer’s eye because companies are more interested in their products selling than what is in the best interest of their customers.

To sum up, the benefits to sending out news releases include:

low cost
increased visibility for your company
high demand for press releases
added credibility for your organization
new customers
new investors
free publicity

This free publicity generated from your news release is all the better because the media has given its stamp of approval which adds credibility and value to your company or organization.

PRWeb Direct Services

PRWeb Direct Services provide expertise at every stage of the news release process. From rough draft to final copy, from copy to edit/polish, from search engine optimization to tracking, and finally the extensive distribution and coverage networks, our experience and proficiency deliver results.

NewsCrafters™ Writing Services

NewsCrafters is the writing arm of PRWeb. Our staff is made up of experienced seasoned writing professionals who understand marketing, news, editing and quality news release writing. We pride ourselves on our excellent communication skills and providing you with the best services possible. No release is final till you are completely satisfied.

Our writing services begin with a $69 edit/polish which comes highly recommended. All writers need an editor especially in the field of news releases and wire services.

The $149 Rough draft to final copy is essentially a rewrite for your targeted audience.

If you are beginning from scratch, we offer a $299 package that includes mining your website for relevant material, a rough draft and final copy that provides the hook needed to compete for editorial attention and interest.

Research has shown that editors take approximately 7 seconds to read your headlines and first paragraph. Style and content win out over other less crafted releases. NewsCrafters are masters of style and copy and can bring your news story to the forefront.

Advertising: Facebook 'consistently the worst performing site'

Plenty-of-Fish owner has the perfect bay for huge success

WSJ 23/05/2007

http://online.wsj.com/article/SB117987775136211487.html

The headquarters of what may be, on a per-capita basis, the busiest, most profitable site on the entire World Wide Web is on the 16th floor of a brand-new Vancouver building with panoramic views of the nearby Canadian Rockies.

It happens to be the apartment of 28-year-old Markus Frind, the owner and sole employee of PlentyOfFish.com, a free online dating site and a model for the next generation of Web entrepreneurship.

Lots of people run Web sites by themselves. But it's likely that no other solo venture runs at the scale of PlentyOfFish. For the week ended April 28, it was the 96th-busiest Web site in the U.S., according to the HitWise tracking service. That means it has more traffic than some of the Net's best-known destinations, such as Apple.com.

Busy Web sites like these usually require scores of people: technicians, certainly, to keep the servers running, but also programmers, marketers and the rest. Mr. Frind says people often don't believe him when he says PlentyOfFish is all his.

I needed to see for myself, so I spent an afternoon touring the company's roomy offices, which most people would call a spare bedroom. Unless there is a team of programmers hidden down the hall, or off in Bangalore, things are exactly as Mr. Frind says they are.

Mr. Frind was born in a small rural town in northern British Columbia. He headed to Vancouver in the late 1990s, went to trade school in computers and rotated through several dot-com jobs before starting PlentyOfFish in 2003 to keep himself busy.

The site was done without much of a plan, though Mr. Frind was intent on finding out how far he could get keeping it entirely free of charge. Most other dating sites charge anywhere between $20 and $40 a month for membership.

The site became popular in Canada and, later, in the U.S. Mr. Frind says he doesn't know exactly why.

There are now 1.2 million active members. HitWise says it's one of the five-busiest dating sites. Nielsen/NetRatings says that by some measures, such as the time its members spend on the site, it ranks second after eHarmony.

How does he do it? In large part, by keeping things simple. The graphical design ranges from rudimentary to nonexistent. No wonder, since Mr. Frind did it himself. The site also won't win any J.D. Power awards for customer support. If you write in with a problem, the odds are long about hearing back from either Mr. Frind or his girlfriend, Annie Kanciar, who helps now and then answering emails.

The site runs on Microsoft software on a half-dozen machines at a hosting facility a few miles away. From his bedroom, though, Mr. Frind can keep tabs on everything going on. When I was visiting last week, he showed me the site's monitoring program: 43,000 people were at PlentyOfFish at that moment, with 500 Web pages a second being sent out.

When you have that kind of traffic, you can make money three ways: via Google's small text ads, with bigger banner ads and through "affiliate marketing," where other sites pay you for sending them customers. Mr. Frind does all three -- and does very well. A few months back, he posted on his blog a picture of a check from Google for nearly $1 million for a two-month period. Google confirmed the check was for real.

Mr. Frind says the site brings in between $5 million and $10 million a year; lest even more competitors get onto his success, he declines to be more specific. That puts him ahead of some of the Web's best: Last year, each Google employee generated an average $1 million in sales.

PlentyOfFish is the success that it is because of several converging Web trends. Servers and server software have become simple and reliable enough that they can run on their own, without a lot of babysitting. What's more, a remarkably sophisticated economic infrastructure now exists that allows busy Web sites to make lots of money, certainly enough for one person to live very well. (Mr. Frind's consumption so far doesn't appear to be conspicuous; his major indulgence is travel.)

Mr. Frind, as one person, can afford to give it away. The big dating sites can't make enough just on Google ads to do the same thing, but the smaller sites can. One small site, HotOrNot.com, is dropping its monthly fees, fashioning itself after PlentyOfFish.

An ascent of free sites could shake up the online dating scene, which is already struggling with flattening growth in the U.S. Nate Elliott, who follows online dating for Jupiter Research, doubts the big Web sites have anything to worry about from for-free competitors. Mr. Frind disagrees; he said his own traffic in Canada has fallen lately as Facebook, the free social-networking site, has become more popular up north.

Many companies would respond to that sort of competitive pressure by hiring someone -- say, a strategic planner. Mr. Frind says he has no plans to do so. He has nothing against employees, he says, and he insists he isn't a control freak. Instead, he just enjoys the freedom to work on whatever part of the site interests him on a given day, without having to fret about who else might be involved. "No one else has ever done something like this before," he says. "It's like my own personal toy."

Write to Lee Gomes at lee.gomes@wsj.com

X2iN | Digital Knowledge Mashup