Facebook Growth By Age Group: Share of College-Age Users is Declining

by Ben Lorica | @dliman | comments: 12

With the U.S. now accounting for only about a third of all Facebook users, we are starting to see a gradual shift away from its original demographic of college-age users (18-25): 46% of all users are 18-25 years old, down from 51% in late May. The number of users in the 18-25 segment is growing, but at a slower pace than the other age groups. Among the major Facebook age segments, the fastest growing are teens (13-17) and young (26-34) to middle-age (35-44) professionals, with the growth in teens driven by non-U.S. markets. Also note the strong growth in the much smaller 45-54 and 55-59 age groups:

In the U.S., 51% of Facebook users are 18-25 years old, down from 59% in late May. But when one looks at other large and/or fast-growing Facebook markets, the share of the 18-25 age group is less than 50% in most of them:

In the U.S. (51%), Turkey (53%), and France (51%), more than half of all Facebook users are 18-25 years old. In comparison, the other countries shown above have more users who are young (26-34) or middle-age professionals (35-44), pushing the share of 18-25 year olds below 50%. Finally, while there is slight shift away from college-age users both in the U.S. and overseas, the 18-44 age group coveted by advertisers, continues to comprise over 80% of the Facebook user base.

Portable Contacts API Starts to Get Real

by David Recordon | @daveman692 | comments: 13

This evening Joseph and John of Plaxo and I have been hosting a hackathon at Six Apart for the Portable Contacts API (video about PorC). The Portable Contacts API is designed "to make it easier for developers to give their users a secure way to access the address books and friends lists they have built up all over the web."

We originally expected a handful of people to show up and hack on implementing bits of the specification, but so far have been blown away at the progress made and about the twenty people that came. Tomorrow is a summit style meeting hosted by MySpace also in San Francisco to try to finalize the specification among a wide range of providers and consumers. I'm expecting a handful of interesting demos, but wanted to share two that have already come together tonight.

Joseph Smarr and Kevin Marks of Google hacked together a web transformer that integrates Microformats, vCard, and the Portable Contacts API. Given Kevin's homepage which is full of Microformats, they've built an API that extracts his profile information from hCard, uses a public API from Technorati to transform it to vCard, and then exposes it as a Portable Contacts API endpoint. Not only does this work on Kevin's own page, but his Twitter profile as well which contains basic profile information such as name, homepage, and a short bio.

Brian Ellin of JanRain has successfully combined OpenID, XRDS-Simple, OAuth, and the Portable Contacts API to start showing how each of these building blocks should come together. Upon visiting his demo site he logs in using his OpenID. From there, the site discovers that Plaxo hosts his address book and requests access to it via OAuth. Finishing the flow, his demo site uses the Portable Contacts API to access information about his contacts directly from Plaxo. End to end, login with an OpenID and finish by giving the site access to your address book without having to fork over your password.

While the individual building blocks are fairly geeky themselves, pulling them together like has been happening tonight shows that we're only at the beginning of building the next generation of social networks. When the pieces work together, people won't have to know what's going on under the hood; it will just work--and will be almost like magic. John has more photos up on his blog.

Radar Theme: Collective Intelligence

by Nat Torkington | @gnat | comments: 0

[This is part of a series of posts that briefly describe the trends that we're currently tracking here at O'Reilly]

"None of us is as dumb as all of us," but the opposite of this profound truth is also true. Systems that channel individual behaviours to create new and valuable data are showing up everywhere. We point to Amazon Recommendations as the canonical example, but it's hard to find an area that isn't using individual actions to produce collective wisdom.

Watchlist: Luis von Ahn, Intrade, Robin Hanson, David Pennock, Slashdot Karma.

Breaking Down What's Happening on the Social Web

by David Recordon | @daveman692 | comments: 2

The past few weeks, John McCrea, Joseph Smarr, and I have been shooting a 15 minute video podcast called TheSocialWeb.tv. Each week we try to break down what's happened in the Social Web in a way that is understandable so you don't have to be living and breathing this stuff.

This week we discuss Meebo's announcement of Community Instant Messaging since it continues the trend of making the entire web more social while using existing building blocks to do so. As Joseph explained, the underlying architecture Meebo is using is Jabber/XMPP. What this means is that unlike Facebook's Chat, social networks using Meebo's Community IM have the ability to interoperate from day one if they choose to do so. Google's Friend Connect is another great example of reusing building blocks where they take advantage of OpenSocial, OpenID, and OAuth. Overtime supporting these underlying technologies becomes easier as companies like Google and Meebo start to build them into their products.

Last week we focused on Gnip and Identi.ca, explaining how Gnip is helping to change the model of accessing data on the web. Traditionally web APIs have been focused on pulling data though things like Twitter's XMPP Stream and Gnip are starting to flip this model on its head. And next week we'll be taping from Facebook's annual developer conference f8 in San Francisco. So please check it out, subscribe to our RSS feed (yes, we know our enclosures are broken), let us know what you think, and how we can do a better job of explaining the Social Web in an understandable way.

Google's Social Graph API Learns a New Trick

by David Recordon | @daveman692 | comments: 1

This past February at Social Graph Foo Camp, Google released the first version of their Social Graph API. (see past Radar coverage) This API was focused on making it easier for developers to understand who a user is and find their other accounts around the web via publicly declared data.

Today I'm driving up to Foo Camp along with Brad Fitzpatrick, the developer of the API, where he has just pushed a new API method live called "OtherMe". This new methods focuses on making it easier for developers to get a holistic view of a user, their feeds, and some basic profile information. You can see this for my profiles in a pretty form from the API. Unfortunately it hasn't been documented yet, but if you're familiar with the existing API it is pretty easy to figure out and real documentation is on its way. This is another large step forward when it comes to opening the social graph. Today it has become many times easier to welcome a new user to your service by presenting a list of people they already know versus asking them if you can scrape contacts from their email address book(s).

Part of Brad's announcement of these changes is below:

Note that this is simply a mechnical transformation on the /lookup method, not offering anything that wasn't possible before. It's just that the transformation was tedious and error-prone and silly to have to repeat in each client library. Hopefully putting it in the server makes it more convenient for everybody.

Why is this useful? A lot of websites are now letting you list your other websites/profiles on your profile, but it's just as annoying to repeat this information on every site as it is to redefine your friends everywhere. If the site incrementally hits this API in the background as you enter profile URLs, the site can then recommend you link/share your other websites. Examples of sites that let you enter your other profile URLs and could use this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, Friendfeed, Mugshot. And that's just off the top of my head from sites I'm familiar with. I'm sure there's a bunch more.

Is SocialMedia Overstepping Facebook's Privacy Line?

by David Recordon | @daveman692 | comments: 6

SocialMedia is an advertising network which places ads within social applications such as those on Facebook and MySpace. SocialMedia claims to be more effective in this type of advertising, due to a patent-pending technology they've developed named FriendRank. SocialMedia CEO Seth Goldstein claims that SocialMedia ads can pay up to 2.5 times more than traditional ads within social networks and that early tests show people are 200 times more likely to respond to a "social ad". See CNET's coverage of SocialMedia's FriendRank launch for more detailed information.

This sounds very compelling, but immediately raises serious questions around privacy and whether a Facebook user knows that SocialMedia is using their profile information in this way. While technology certainly makes this possible, are user expectations being set correctly? Facebook's Beacon functionality faced an uproar at its launch earlier this year not for the technology it provided, but rather for upsetting expectations around privacy, information sharing, and ultimately ad targeting. So how is SocialMedia getting access to the type of information required to create such a compelling social advertising network?

Facebook provides a customizable public profile page for each user (mine is here) which by default makes your name, picture, and a few friends publicly available. SocialMedia could and most likely is using this public information, just like anyone else could too. Multiple sources including ValleyWag and others familiar with the ad platform say that SocialMedia doesn't stop there. Rather they're very quietly also accessing information from Facebook Platform applications directly. This was originally broken by The Social Times a few weeks ago:

So how does SocialMedia display these targeted ads outside of Facebook? Through a collection of data via applications in combination with images obtained via user public profiles and unique cookies they can piece together who you are and who some of your friends are. This is off of Facebook.

The question then is, are social applications properly disclosing the fact that they give your information to SocialMedia, and is that action covered by a clear privacy policy? This is not about the technology behind how SocialMedia might access this information, but rather making sure that the technological implementation matches user expecations. We can start by looking at the process of adding an application on Facebook which does not appear to use SocialMedia for advertising:

If you've ever installed a Facebook application, you're familiar with this screen, which prompts you to grant explicit permissions to each and every application you choose to install. It should be noted that Facebook Platform does not have any affordance for allowing an application to share your information data with a third party. Facebook's Developer Terms of Service explicitly prohibit such sharing, and the technological implementation of the Facebook Platform API make it extremely likely that sharing such data would sometimes involve sharing a developer's secret key with SocialMedia as well. All of this is explicitly and strictly prohibited by Facebook's Developer Terms of Service: (emphasis is mine for readability):

"Facebook Platform" means a set of APIs and services provided by Facebook that enable websites and applications (collectively, "Applications") to retrieve data relating to Facebook Users made available by Facebook and/or retrieve authorized data from other Applications. The term "Facebook Platform" includes any data, images, text, content, code, APIs, tools or other information or materials provided by Facebook through or in connection with such APIs and services (collectively, the "Facebook Properties").

...

5) You may not sell, resell, lease, redistribute, license, sublicense or transfer all or any portion of the Facebook Properties, or use or store any Facebook Properties for any purpose other than as specifically authorized herein.

The bottom line is that though this might seem like an obscure technical issue, sharing user activity and profile information with SocialMedia would be as objectionable as the worst behaviors ascribed to Facebook Beacon. With Beacon people were surprised that their actions from around the web were starting to be shared with their friends on Facebook. It wasn't that everyone objected to this happening, but rather that it was implemented as opt-out which led to information being shared in ways that normal people didn't expect. This in turn completely killed Beacon with participating brands such as Coke dropping support. A few weeks ago Facebook shut off access to Slide's Top Friends application for "allowing access to non-friends' personal information" as reported by Inside Facebook. The following week Facebook's responded with a blog post Building Trust and Protecting User Privacy which started by saying:

Privacy is at the core of Facebook.

Because we provide users with rich privacy controls and respect their choices, users feel safe using Facebook to share their information with their friends. By opening up Facebook through Platform, developers have the opportunity to innovate on top of this information. In exchange, developers commit to treating user information with the same respect that users expect of Facebook. Our Developer Terms of Service strictly limit use of user data and serves as guidelines to these expectations.

But I truly believe that Facebook does try to protect user privacy and by doing so creates an environment promoting the creation of rich profiles tied to real offline identities and sharing more content between friends. Facebook has shown a history of learning from these situations over time. If Facebook learned so much about the dangers of surprise with Beacon, shut off Top Friends for sharing profile information, and continues to block access to Google's Friend Connect for redistribution of profile information then why are they still permitting Platform applications to possibly share this data with SocialMedia? As technologists we must be extremely careful in making sure that our implementations match a normal person's expectations. If we forget to do this, we could collectively end up killing something that might someday become great.

I've tried contacting SocialMedia to ask about how their advertising network works, though unfortunately while I've received replies have not had my questions answered. As full disclosure, I work for Six Apart which launched an advertising network for bloggers earlier this year, and has a privacy policy here. I'll be at O'Reilly's Open Source conference in Portland at the end of the month.

On Wikipedia, storms, teacups, and _why's notability

by Nat Torkington | @gnat | comments: 7

In which our hero ponders the Internet's underwear, the oxymoronic nature of social software, and that not only should you not hate the playa but you shouldn't even hate the game.

It must be a weekend, the interwebs have their panties in a bunch again. This time it's about the Wikipedia entry for _why the lucky stiff, one of the major Ruby hackers. For the backstory, see Deletionist Morons by Tim Bray. In short: Wikipedia editors want to delete _why's entry because he doesn't pass Wikipedia's Notability test.

Social software is a funny old thing, isn't it? On the one hand, we have the word "social" with its overtones of informality, emotion, and all those black turtleneck wearing arts graduates. Then we have the word "software" with its harmonics of precision, logical thought, and Aspies with intravenous caffeine. In fact, when you think of "software" you probably think of people who could easily be described as "antisocial". Is it any wonder, then, that the product of the two doesn't exactly mesh well with our view of the world?

Having read Wikipedia: The Missing Manual, I now know that Wikipedia is social software. Not the reading part, but the editing. There's a human process for humans to follow, whereby the humans use the software to debate (something humans do, not software) and arrive at a decision. This is a human, social, process ... not a software one. A lot of the rancour comes from misunderstanding this.

Perhaps an analogy to another social process would help. Wikipedia is like an open source software project where the great unwashed submit patches, the committers choose which to apply, and the core team make executive decisions when needed. There's no piece of code that determines worthiness to be committed to the source tree. Instead, there are people with judgement and human flaws in the way. The Linux kernel shouldn't grow e-mail protocol stacks, web server hacks, and a built-in relational database just because someone submits the patches. The project's committers are there to keep the software project on track. So too with Wikipedia.

Hating the humans or even hating the filtering process is a waste of time and energy. The deletionists and the inclusionists both have a role to play. Wikipedia has a lot of things that it is not and the humans are there to keep the project on track. Those who want to delete and want to keep are doing their bit, just as others did by creating a page for _why in the first place.

The creators of any piece of social software must carefully choose where to punch holes in pure computational deterministic perfection to let human attributes like intelligence or taste shine through. Their choices define the project. This "you want X, I want Y, we'll go back and forth citing Wikipedian principles and external sources until a decision emerges or must be made by an administrator" process isn't Wikipedia's weakness, or even its strength, it is Wikipedia.

In social software as in software projects, the human filters sometimes make poor decisions; you can't have the flexibility and intelligence of humans without their flaws. Using Wikipedia but becoming enraged when your favourite marginal entry is deleted is like going to an art gallery but being enraged that you saw something there you didn't like. It's a big waste of time and energy that could better be spent working on this patch I've got to add a relational database to the Linux kernel ....

Thinking in Wikis

by Nat Torkington | @gnat | comments: 3

I clearly remember thinking, when I ordered my copy of Wikipedia: The Missing Manual, "this has got to be a new low for O'Reilly. How can it be anything but a waste of a ream of paper?" I mean, "Wikipedia: it's an online encyclopedia that anyone can improve". There, what else is there to say? Throw in the URL and you've got ten words. But having read it, pressed it into someone's hands saying "you have to read this!", and ordered a new copy, I can safely say that it doesn't waste any of its 500 pages and is well worth reading.

Wikipedia: The Missing Manual talks about the invisible Wikipedia—the social and technical structures that you only see when you want to contribute. They're what prevent Wikipedia from becoming the other great social literary institution that anyone can contribute to, a public bathroom wall. It gives practical advice on topics like: how to improve articles, how to dispute something, and dealing with vandalism and spam. It even covers the ever-timely topic of deleting articles and "notability".

Reading it, I was reminded of open source projects. You think software is what you download until one day you want to contribute something and then you realize there's a whole community of developers behind the zip file, people who have their own customs, heroes, and rituals—put a foot wrong and your effort will be wasted. As you work with them, you go from cursing the stubbornness of these fools who dismiss your work's brilliance as "inappropriate and ill-formed" to realizing "wow, that guy knows more about coding than I do" and then one day you wake up and discover you've spent two hours with the other maintainers of the project educating the n00b who submitted a Frankencode hack to put C++ XML editors and Exchange-compatible email servers into the C timezone conversion library, and you have just typed the phrase "inappropriate and ill-formed".

So now I have another tool in my toolbox, process-backed wikis. I asked on my personal blog could such a wiki help a nation define its character?, and I'll be looking around O'Reilly for situations that fit. For instance, perhaps there's a need for a "books Nat should read even though he's already judged them by their covers" wiki ....

Ignite Boston shows the way to beat commerce interruptus

by Andy Oram | @praxagora | comments: 0

I felt like was I drifting back to the dot-com boom last night during Ignite Boston. Movements that I saw getting stalled seven years ago seem to be finding their way forward again.

Ignite Boston, a party held every few months by O'Reilly, draws people from around the region who are interested in technology and socializing. Last night, the approximately 325 attendees packed two floors of a bar, and it's a good thing the street outside was closed off because there were plenty of celebrants out there as well, escaping the noise inside to have a conversation.

(continue reading)

Google Friend Connect and limits to sharing

by Andy Oram | @praxagora | comments: 3

We're all tired of acquaintances tugging on us to sign up for new social networks, and of the torque we feel bouncing between the networks we're on if we can't resist the herding instinct that brings us to join them. But we wouldn't want to have just one big social network, either. That would inhibit innovation and prevent people from enjoying a site's special features and cultural uniqueness.

Google's Friend Connect, which was announced on Monday and covered by Radar as well as other sites, represents a small step toward a middle ground. It could be considered the natural succession to Google's OpenSocial, also discussed extensively on Radar. The OpenSocial API forms the basis for communications between Friend Connect widgets and the site hosting them, using lightweight Ajax and JSON protocols. Friend Connect uses the APIs provided by other sites for communication with them.

I had a little tour of Friend Connect last night at the party celebrating the opening of Google's new Cambridge office, covered in another blog.

(continue reading)

MySpace's Data Availability is not Data Portability

by David Recordon | @daveman692 | comments: 10

Yesterday MySpace, Yahoo!, eBay, Photobucket (also owned by News Corp), and Twitter announced the Data Availability Initiative. While I could write at length about how this shows the big companies have already realized how to diminish the DataPortability group's brand by linking anything they do "data portability," that isn't the point of this post. The crux of the announcement yesterday was that shortly MySpace would begin allowing third-parties to embed MySpace profile information within their own services in the name of "data portability". Unfortunately, the details around this remain buzzword-laden at best.

Their press release yesterday stated:

Additionally, rather than updating information across the Web (e.g. default photo, favorite movies or music) for each site where a user spends time, now a user can update their profile in one place and dynamically share that information with the other sites they care about. MySpace will be rolling out a centralized location within the site that allows users to manage how their content and data is made available to third party sites they have chosen to engage with.

At first glance this seems like a great thing. MySpace is partnering with Yahoo!, eBay, Photobucket, and Twitter to solve a pain point on the web; the inability to keep parts of your profile in sync around the web where you'd like them to be. The announcement didn't however offer any insight into how this would work beyond that, "the MySpace Data Availability initiative uses OAUTH [sic] and Restful APIs as its core technology underpinnings." After this announcement I had the pleasure of speaking with a reporter who was on the briefing call. He explained that MySpace said that due to their terms of service the participating sites (e.g. Twitter) would not be allowed to cache or store any of the profile information. In my mind this led to the Data Availability API being structured in one of two ways: 1) on each page load Twitter makes a request to MySpace fetching the protected profile information via OAuth to then display on their site or 2) Twitter includes JavaScript which the browser then uses to fill in the corresponding profile information when it renders the page. Either case is not an example of data portability no matter how you define the term!

To make this worse one of the pieces of profile information made available is a list of a MySpace user's friends. Once again there are two reasonable ways to do this: 1) MySpace provides a user's friends as a list of hashed email addresses to Twitter or 2) MySpace provides a user's friends as a list of MySpace usernames. While the hashed email route would certainly be simpler and easier for sites like Twitter to match against their own user database, I highly doubt this will be the implementation due to concerns around undesired account linking. Rather I think MySpace will choose to provide a list of other MySpace usernames. What this means is that in order for Twitter to make use of the information they must encourage all of their users to fill in their MySpace account on Twitter so that they can map a MySpace username to a Twitter username. Obviously in the best interests of MySpace to have more of their profiles linked to from around the web thus increasing page rank, visitors, and thus ad revenue.

At the end of the day it seems that MySpace is trying to become a large centralized profile repository on the internet. One where information might be available but certainly not allowed to be actually moved outside the network's walls. A good try, but just as no one would like Microsoft own identity for the entire web with Passport I fail to see how others will let MySpace own all of the profiles.

Update: Just got off a plane from London and realized that I missed a link to Chris Saad, DataPortability's co-founder, explaining yesterday that they "hope to see the MySpace “Data Availability” initiative evolve toward becoming a compliant implementation of the DataPortability Best Practices." While MySpace did not say in their release that Data Availability is a form of data portability, it certainly seemed to be interpreted that way.

Worldwide Social Network Market Share

by Tim O'Reilly | @timoreilly | comments: 28

Via Azeem Azaar's twitter feed, a great visualization of worldwide social network market share, from Le Monde:

App Engine, Facebook Platform, OpenSocial, and the Future of the Web

by David Recordon | @daveman692 | comments: 10

I was lucky enough to get an invite to Google's Campfire One event where the company announced App Engine. App Engine basically allows web developers to take advantage of Google's infrastructure to scale if they're willing to build their app using Google's tools. While drinking hot apple cider, Brady wrote a great post digging into a bunch of the different aspects of App Engine.

During the presentation, I tweeted, "Thinking App Engine with Google Accounts integration is a threat to both Facebook Platform and OpenSocial. Metaphor shift." I thought a decent amount, well at least a few seconds, before I SMS'd that, since I knew it would be lacking quite a bit of context. I completely agree with Kevin Marks that App Engine looks like a great platform to host Facebook and OpenSocial apps, but that wasn't actually my point.

Early mashups on the web took data from somewhere and combined it with an API from somewhere else in order to create new value. The resulting mashup was the same for every viewer, but that didn't last long. Quickly came the era of mashups allowing customization of data inputs. Today tools like Yahoo! Pipes, Dapper, and Microsoft Popfly bring the ability to "mashup" to a wider audience. Want to know the largest "mashup" (in the most loving sense of the word)? Facebook Platform. Call me crazy, but hear me out.

If you discard useless sheep-throwing applications, you're left with apps that at their core either bring data into Facebook or take data within Facebook and interact with services outside the Facebook garden. Take iLike, for example. With it you can build a rich music library, add music you like to your profile and then share that with your friends. iLike builds Facebook apps (and Hi5 apps, and OpenSocial gadgets, etc.) because iLike knows that its users have friends who don't already use iLike. Causes is another amazing Facebook Platform application, one that makes charity giving social and integrates a payment API. At the end of the day, iLike and Causes take data from multiple places and combine it using the platforms provided by Facebook (and Hi5 in the case of iLike).

At this point you might be saying, "well, OpenSocial solves that" which it does (sort of), but I see an internet where applications are directly creating "mashups" with each other. If the evolution of a mashup went from making it easier with Popfly to making it viral with the Facebook Platform, the next evolution is removing the large social network as the container all together. One of the key components of App Engine is the ability for a site to take advantage of Google Accounts for login. Today that means that every App Engine site could have a shared sense of a user; the ability to understand who someone is across different App Engine sites and Google services. (Obviously I'd love to see Google move toward supporting OpenID for this sort of thing, but small bits piece by piece work for me.)

Imagine if Google Accounts added support for the (upcoming) OpenSocial REST APIs. All of a sudden, each of these App Engine sites could start injecting activity and querying for activity across each other. Maybe you'll argue that this just means that Google Accounts could become the next big social network, but isn't it a bit different when this functionality is just a part of your hosting infrastructure? What if Google Accounts ignored the notion of friends and instead left that to actual social networks? If done right, this really could be the first shipping glimpse of the distributed social web that there is to come.

I'll be speaking more about this sort of stuff at Web 2.0 Expo on Thursday, May 24th in SF.

Open Source "Social App Server" Might Crack Garden Walls?

by Jim Stogdill | @jstogdill | comments: 5

From right here in Philly's backyard, Ringside Networks came out of stealth mode yesterday to launch the first open source "social application server."

And what is that exactly?

It's the software guts of a social network that you can use behind your own firewall, old school style, to build social networking "stuff" into your own site.

Companies that want to build social applications (for runners sharing times at Runlicious) or socially aware marketing programs (like Jeep owners sharing pictures and videos) will be able to use social servers to develop the whole thing on their own websites. Their brand on their site instead of their brand on Facebook next to the "get help for your gambling problem" advertisement.

Developing a social network will be harder to do this way than it would be using a white label network like Ning, but it will be completely customizable, will integrate neatly into the rest of the site, and all the data will be right there for the application owner to mine.

That's the simple version anyway; use social servers to roll your own social apps and sites. But I also wonder how it might upset the balance of power inside the behemoth walled gardens of Facebook and Myspace.

OpenSocial took the first shot at the garden walls with a goal of empowering users to keep their social data portable (well, portable inside Google anyway). However, while OpenSocial promises developers social apps without servers, Ringside is saying that at least some developers are going to want their own stuff under their control. I think social app servers are going to take shots at the wall too, but with the social networking advertisers and application ecosystem as the core constituency.

By supporting Facebook's API (with other API's to follow), Ringside makes it a lot simpler to take a social application written for Facebook and move it to its own site, or visa versa as shown in this picture. This kind of write once deliver anywhere approach to social applications raises all kinds of interesting possibilities.

Like,... Don't want to have to enter your favorite beers into Beer! in both Facebook and Myspace? If Beer! builds their application on a social server that can tie your Facebook user name to your Myspace user name, you won't have to. Facebook and Myspace just become two points of presence for the application, and they'll be on equal terms with Beer!'s own web site. Wherever you log in, you see your beers and (most of) your beer friends.

Facebook opened up this possibility when they designed their platform to have the developer's servers do the heavy lifting. Doing it this way meant they didn't have to provide all of the servers and gear to run the applications, but it also means that it's easier to stick a social server outside the wall and treat it and other branded networks like distribution shelf space. Once an application can seamlessly span the networks, it can do more than map a user's identity across sites, it may also piece together a social graph that is bigger than any one site's. Sort of an application-specific super graph.

In one possible end state, users own all of "their" social graph and data in OpenSocial, and application providers own all of "their" social graph and data in their own social application servers. Meanwhile, the big branded social networks are still in the game with very large "lily pad graphs," but they no longer see the whole picture for any one user or any single application.

As this evolves we may see developers building first for Facebook and Myspace to get quick viral adoption in a huge audience. However, as soon as they can they may start to drive traffic over to their own sites where they can provide a better or different interface with a more carefully managed brand experience. Imagine if NBC let you show your first YouTube video from a planned series at 7pm on Thursday, for free.

Or, developers may use the write once deliver everywhere strategy to deliver their app as widely as possible. Where Facebook and Myspace were once king, in this scenario they may end up as two of many application points of presence with awareness of only a piece of the associated social graph. The successful application developer with a network-spanning super graph might then be free to monetize it however and wherever they can.

Well, at least until the API wars start in earnest. There is a good reason for the server to be open source, it will spread the load of keeping up with all those inevitable API changes.

To be free, information has to be smart (comments on Chris Anderson's "Free!")

by Andy Oram | @praxagora | comments: 5

WIRED Magazine's editor in chief Chris Anderson, following up on the popularity of his Long Tail meme, theorizes in the March 2008 issue of WIRED about the modern tendency to put information online at no cost. I'll start this blog with the implications of offering free information in the computer field, and build from there to what I agree and disagree with in Anderson's article.

Anderson's taxonomy of "free" contains six models that justify giving the information away. The idea of "free as in freedom" (that is, open source information in the GPL or Creative Commons style) doesn't enter at all into his article. Is that important, given that the article is economic rationale for business? I think it's a crucial omission.

(continue reading)

The "New Privacy"

by Allison Randal | comments: 4

There was a great session on Online Privacy on NPR's Science Friday today, including a guest spot by Emily Vander Veer, the author of O'Reilly's Facebook: The Missing Manual. You can subscribe to the podcast or download today's episode directly.

The discussion here is yet another independent confirmation of the new definition of privacy that's emerging in American culture. We used to fight for the right not to reveal information about ourselves. The "new privacy" is about fighting for the right to spread your personal information all over very public forums but still control how it's used. It's an almost Escher-esque redefinition of language. To quote my own earlier writing: "If you paint something on the city wall, don't expect it to be hidden."

Daniel Weitzner made a big point on the show of the parallels between protection for the kind of information we display on Facebook and legislation to protect medical and financial information. He missed a crucial difference: the medical and financial information protected by those laws prevents information that must be revealed in one context (to your doctor or banker) from leaking out into other contexts. But, if you posted your bank and credit card details and medical records on a public web site for the world to see, people might accuse you of being stupid, but they wouldn't claim that we need tighter legislation on the use of information.

Shelly Farnham on What Makes Facebook Apps Work

by Tim O'Reilly | @timoreilly | comments: 2

As many of you know, last fall, we released a report entitled The Facebook Application Platform, with analysis that demonstrated that far from being a "long tail" marketplace, Facebook has very much of a "short head" when it comes to applications.

As a social scientist, Shelly Farnham didn't think that was the end of the story. She asked if she could have access to our data set so she could do some additional analysis. We liked her analysis so much that we decided to publish it as a second report, The Facebook Application Ecosystem: Why Some Thrive--and Most Don't.

Shelly just did a great blog post about the report, explaining some of what she found. Here are a few tidbits:

In reviewing the dominant types of applications, it is clear that most of the applications are helping users achieve social goals such as improved communication, learning about the self relative to others, finding similar others, improving self-presentation, engaging in social play, and engaging in social exchanges via gifts and media...

In examining each application, we spent some time with the reviews and the discussion topics, expecting that applications that were more active would have more posts by users. We found however that reviews were not reviews. Rather, the review section seemed to be largely used for users to communicate with application developers, giving their feedback and reporting bugs, and to each other about the application.

The discussion topics section was used more for users to connect to one another. What was striking, however, was that both of these sections tended to be used to a greater degree when social applications (e.g., social games) did not provide a venue for verbal interaction within the game itself. The reviews then became overloaded with demands for the user-to-user communication required to use the application. These overloaded review sections, much like the overloaded horoscope or game discussion areas, reinforce the message that people come to social sites to be social, and will twist any application into an opportunity to communicate.

Good stuff, reminding us that social network applications are used socially, and that developers providing functionality that enhances social behavior are winning. These comments emphasize a basic web 2.0 (and open source) principle as well: users are co-developers. If you don't give them what they want, they will hack your system, overloading its features so they get what you didn't give them outright.

Exploring the Facebook Application Ecosystem: A New O'Reilly Radar Report

by Jimmy Guterman | comments: 0

After we published our Facebook Application Platform report, we heard from a lot of people. One of them was Shelly Farnham. And like Victor Kiam, the entrepreneur who liked that razor so much he bought the company, we liked Farnham's ideas so much that we're publishing her report.

With Graphingl Social Patterns West going on this week in parallel with ETech, it's a good time to release the new O'Reilly Radar report, The Facebook Application Ecosystem: Why Some Thrive -- and Most Don't. Stuffed with data, the report shows the application features that lead to success, the best practices for launching and building Facebook applications, why people are using the top Facebook applications, and whether targeting demographics or user interests is a surer way to success.

Our original Facebook report showed, for the first time, how Facebook has become a winner-takes-all platform. This new report shows what to do to be among the winners.

You can order the report here.

Graphing Social Patterns West: Monday Highlights & AppNite Demo Contest

by Dave McClure | comments: 3

Alright folks, we're less than 48 hours away from the beginning of Graphing Social Patterns West 2008... w00t! I'm flying down to San Diego tomorrow, and looking forward to seeing everyone :)

If you're a developer, make sure you enter our AppNite Live Demo Contest -- submissions are due by *midnight Saturday 3/1* (that's tonight!). Two lucky winners will receive MacBook Air notebooks for the best app demos.

Here's the lineup for Monday:

• The Future of Social Networks - Charlene Li, Forrester Research


• MySpace Platform Overview - Amit Kapur, MySpace


• Facebook Platform Overview - Ben Ling, Facebook


• Ten Million in Ten Weeks - BJ Fogg, Stanford University


• Facebook Business Marketing 101 - Rodney Rumford, FaceReviews.com


• Giving Good Poke - Beth Kanter, Beth's Blog


• Yahoo!'s MyBlogLog API - Ian Kennedy, Yahoo / MyBlogLog


• Social Networks & the NEED for FEEDS - panel


• Bring Your Own Platform (BYOP) - panel


• Widget Strategies & Social Platforms - panel


• Privacy Management & Data Portability - panel


• DiSo: Distributed Social Networking - Chris Messina, Citizen Agency

In addition to the conference sessions above, in the evening we'll have the AppNite contest, the O'Reilly Radar keynote from Tim, and then Ignite ETech organized by Brady Forrest, the program chair for ETech, being held concurrently with GSP.

See you in San Diego!

New Release 2.0 on Next-Generation CRM ... and a New Installment of Our Facebook Application Platform Report

by Jimmy Guterman | comments: 0

In this month's Release 2.0, we consider the next generation of customer relationship management (CRM) and the search for an all-in-one-place inbox and address book.

We need some sort of universal inbox and address book because it's not just email that we're neck-deep in nowadays. Once you've figured out a way to organize one means of input, there's another one. Are you up-to-date on all the RSS feeds? Your Facebook friends? Their Twitter tweets? In recent months, we have started to see high-profile attempts to create universal inboxes from two different directions: online social networks and CRM systems.

As the need to store and organize more information grows more acute, both online social networks and CRM systems have grown dramatically in membership and in the amount of information stored and shared. There are millions of people who have accounts on both social networks and CRM systems, but of course our needs and expectations on these systems differ. Your contact record in someone's Siebel system identifies you as a current or potential customer; your contact record on MySpace may identify you as a folk singer or stand-up comedian. There are good reasons for keeping this information separate, but it is difficult to maintain multiple personalities online, just as it is in real life.

Yet the lines between the persona you present to your social network and someone's CRM record of you get blurred regularly. You might date someone you work with; you might engage in some business with an old college buddy. Separately, your social networks and CRM systems are useful. But they might have something to teach one another. In the new issue of Release 2.0, we explore what happens when the various forms of online communications smash together, in search of that universal inbox and address book. Email inboxes are taking on aspects of social networks and CRM systems. CRM systems are getting more social. Social networks are being used to track business contacts and replace other forms of online communication like email and chat. You can, for example, update your Facebook status via Twitter. And the goal for these projects seems to be the same: everything, organized, in one trusted place. The new issue of the newsletter reports on where we are -- and where we're going.

And while we're considering how online social networks are changing things, we have completed the third and final edition of our Facebook Application Platform report. In the months since we published the initial version of the report, we've seen:

* the winner-take-all nature of Facebook applications grow more prominent,
* a flattening or even declining usage among some top applications,
* a rise in the desire for truly useful Facebook applications -- not just frivolous ones,
* and much more.

We have updated our data on the most successful Facebook applications, the most-used ones, the most successful vendors, and much more. The platform is very much alive. but it is experiencing growing pains. (Purchasers of previous versions of the report get this one for free.)

You can order either a single issue or a subscription to Release 2.0 here and the Facebook Application platform report here.

Next week we'll have two more new reports to announce. We're debuting them at Graphic Social Patterns and ETech and we'll tell you about 'em here as well..