“Game over… Facebook is the new MySpace” (Jason Calacanis)

“This is already WAY BETTER than FriendFeed” (Scoble)

“Buzz exists because Google feels threatened by Twitter and Facebook and wants to kill them.” (Newsweek tech blog)

Most of the conversation over the last 24h has been centered around predicting if “Buzz will kill” this or that service. The unspoken assumption that lies behind this debate is that Buzz and the rest of the social web are mutually exclusive.

It’s arguably fair to assume that the leading companies are locked in a zero-sum, winner-takes-all game where the prize is total domination of the social web, considering all the social networks we’ve got so far are silos. To no longer assume everyone has to be using the same branded system to talk to each other is disruptive to the tech biz discourse, which is obsessed with turning everything into a war over which company is “the one”. So much so that the alternative is almost unthinkable.

If the new standards succeed, in 2015 we’ll look back on these debates and shake our heads like we shake our heads today at the early days of warring proprietary phone networks and email systems. The thought that you couldn’t call, text or email people (or companies, or public services) just because you happened to sign up with the wrong phone company or email provider is so blatantly a bad idea it’s absurd. Doubly so for the social Web where everything is already built on the same underlying protocol.

The reason many of the current commentators miss this point is that they are, in the immortal words of Walt Whitman, “demented with the mania of owning things.” (borrowing that quote from Doc Searls).

Let’s see through this entertaining controversy and not lose sight of the real enemy. This enemy is autocracy – the unlimited power of one leader over masses of people – and it feeds on fragmentation. There is a vision worth pursuing that’s bigger than Twitter, Facebook, Google, or any company. It’s the vision of a true global conversation. One of a world where I can tune in to a squabble between tribesmen in Congo and you can @-reply to a joke by a Chinese taikonaut. It doesn’t matter that they’re registered on services we’ve never heard of, speaking in languages neither of us can understand. We can still discover them, follow them, and have a conversation. Because they, like we, are on the same social web.

This morning Google switched on real time conversations on Gmail, mobile, and Google Profiles. The product got the name Google Buzz.

As the former product manager and someone who made the decision to sell a startup and move his family halfway around the world to build said product, it’s an emotional moment to see it out in the wild.

Of course, I left a good while ago and credit is due in its entirety to the team at Google.

What everyone wants to know now is, will Buzz disrupt Facebook and Twitter? Or did it flame up thanks to Google hype, only to smolder away unloved and unused like Wave?

Here’s what I suspect. Although Google’s getting into the game late, the timing may be just right. The game is no longer just about “what are you doing”. As microblogging has become more popular, the stream has become more busy, and people are getting tired of sifting through the noise. So, now that pretty much everyone has shown up for the party, the value is moving to discovery, context, and relevance. The question we increasingly feel our social inbox should answer better is: “given what you know about me, look at everything I subscribe to, and show me only the updates I care about most right here, right now.” In one word: Search. And who has the advantage there? We know who.

Second, look at what’s happening to usage. You don’t need a crystal ball to know that mobile is becoming the primary (in some cases the only) interface to daily social media. Facebook’s and Twitter’s mobile clients? Let’s be straight, they’re lame feed scrollers compared to what they could be. Nobody has come even close to harnessing the full power of mobile. Which of the three companies has its own mobile platform: Facebook, Twitter, or Google? Again, we know who.

Third, note that Buzz is built to be compatible with open standards that enable the distributed production and processing of real time updates. In fact, where standards didn’t exist, ones were set in place, with the philosophy to enable developers working with existing web technologies to apply them with minimal effort. This could be the most significant contribution of the entire project in the long run.

Google’s weakness historically has been in that it hasn’t “gotten sharing right”. If there’s one thing I’m interested to watch get used in real life it’s the sharing model, which allows sharing of both public and private content in the same stream. Having different privacy settings coexist intuitively in an interface is one of the trickiest design challenges there is. A lot of time was spent tuning this, and I’m pretty optimistic about the result.

When the Jaiku team joined Google, we were tasked with doing “something cool with mobile and social”. Teemu mashed up Jaiku and Google Maps on the mobile in a couple of weeks, but we couldn’t use it because it was built on Jaiku’s, not Google’s social graph.

The problem at the time was that there was no Google-wide social graph. There was no sharing model or friend groups. There was no working activity stream back-end. There were not even URLs for people. All this had to be built, and parts of the whole (such as Google Profiles and Latitude) were shipped incrementally along the way. The archstone that connects everything together is Buzz in Gmail.

The task has been truly herculean, and I have deep respect for the engineers and designers who pulled it through over literally years of iteration and countless changes. I left before Buzz shipped, but learned a lot of valuable lessons about building something that big.

Did we get it right? It would be great to hear your thoughts.

PS. If you read just one thing on Buzz, make it Tim O’Reilly’s post from earlier today. Tim sees what Google is doing (and should be doing) with Buzz better than any other commentator I’ve seen so far.

Yesterday we flipped the switch and moved Jaiku to App Engine. Today we open sourced the Jaiku code base. The code is available as JaikuEngine on Google Code. Anyone can now set up and run their own JaikuEngine instance on Google App Engine.

The same day Jaiku was migrated, Dave Winer wrote that it’s time to break out and distribute microblogs. I agree. There should be lots of platforms, and they should talk to each other. Jaiku doesn’t do that yet, but now there’s a decent chance that it soon will.

Andy‘s put a lot of work into this open source release. A few hours ago he posted a note to developers in the JaikuEngine-discuss group. Here’s a snippet from that note.

The source lives at http://code.google.com/p/jaikuengine and is reported to be eagerly looking forward to hearing from us all. We have received the following letter:

Dearest JaikuEngine users, contributors,

Wow! It's great to be free.

I'm really looking forward to accepting your patches and keeping you all up  to date on my plans.

So far I've set up a mailing list, jaikuengine-discuss@googlegroups.com and over the weekend I expect to be getting set up to receive and review patches.

If you are really itching to send something in before then, just make a new issue in the issue tracker at http://code.google.com/p/jaikuengine and attach your code.

Working together I'm sure we can come up with some really fun stuff and maybe even do our part to make the world a better place.

I will send more updates soon.

JaikuEngine

On Wednesday we posted on the Google Code Blog that:

As we mentioned last April, we are in the process of porting Jaiku over to Google App Engine. After the migration is complete, we will release the new open source Jaiku Engine project on Google Code under the Apache License. While Google will no longer actively develop the Jaiku codebase, the service itself will live on thanks to a dedicated and passionate volunteer team of Googlers.

With the open source Jaiku Engine project, organizations, groups and individuals will be able to roll-their-own microblogging services and deploy them on Google App Engine. The new Jaiku Engine will include support for OAuth, and we’re excited about developers using this proven code as a starting point in creating a freely available and federated, open source microblogging platform.

Understandably, some people took this to mean that Jaiku was going away entirely.  This impression was exacerbated somewhat by a blogger reporting early that Jaiku was being closed alongside some other products.

The reality is a bit more nuanced, but it is significantly more interesting in my opinion.  First, the jaiku.com domain and the Jaiku user accounts (and their friend graph and their messages) continue to live on just as they have today.  The biggest difference is that behind the scenes Jaiku is moving away from its original proprietary hosting model and on to App Engine.

Personally I love this for several reasons — it is a tremendous validation of the power of the App Engine platform, and another great learning opportunity for the engineers here to work with a very real service.

But the second, and perhaps even bigger news, is that all of the code used to power Jaiku on App Engine is going to be released under the Apache license.  Combine these two changes — Jaiku on App Engine, and open source Jaiku — and you can start see the opportunity that emerges here.

Soon, anyone, for free and with little effort, will be able to install and modify the Jaiku code, launch it on App Engine, and run their own microblogging platform.  Combine that decentralization with standards such as OAuth and the forthcoming activity stream standards, and what we’re seeing here is the accelerating trend away from microblogging being a destination to microblogging being a pervasive and ubiquitous part of the fabric of the web itself.

Now that’s cool.

Will Google have a team of 20 working on Jaiku?  No, and we’re not going to sugar coat it, which is exactly why we posted such an honest an open
letter about the future of the product.  Are there many of us who passionately care about Jaiku and about the possibilities of microblogging?  Absolutely.  And we want you to participate.

Every once in a while comes along a book that changes everything.

The last author to do it to my generation was William Gibson in 1984. For almost two decades, when we imagined the future, we imagined ourselves tapped into cyberspace via our deck alongside Case, the protagonist in Neuromancer.

Tomorrow will mark the day of a literary event likely to be of comparable impact.

The Daemon will launch on the front shelf of Borders bookstores and Barnes & Nobles everywhere.

If this is the first time you hear about the Daemon — well, for one thing, you haven't been following my status updates :) — and you're likely to hear more from other people. It is a Da Vinci Code meets World of Warcraft kind of deal.

Many of the elements we've come to expect from action-packed Sci-Fi are there: a mysterious, gruesome murder; advanced surveillance tech; smart & lethal weaponry; and evil AI at the root of everything. The key difference to Neuromancer, however, is that it all takes place in the real world. It could happen today.

Like Craigslist's Craig Newmark put it, “Daemon is the real deal—a scary look at what can go wrong as we depend increasingly on computer networks.”

Almost as interesting as the fiction is the backstory behind the book. Initially a self-published work, early advocates, myself included, did our best to get it to people's attention and word started spreading on blogs and microblogs.

When I first picked up the book at the Long Now Foundation, I wondered about the odd name of the author, Leinad Zeraus. It took a little while before I realized the pun: it was Daniel Suarez spelled backwards.

A few days ago, I got an email from Daniel. I'm quoting it here with his permission.

"It was grassroots support from early adopters like you that proved to New York publishing houses that there was an audience for Daemon. Without that critical support, my little self-published book might have quietly disappeared.

Instead, it will be front-of-store in every Barnes & Nobel and Borders in the U.S. and is being translated into ten languages. I’ve also signed a deal with DreamWorks for the film rights."

I'm also delighted to note Daniel will be visiting us at Google to speak about the book in a few weeks.

For more on bots and their social implications, watch Daniel Suarez speak at the Long Now Foundation. For a summary of the talk, read Paul Saffo's notes.

Today Apple announced DRM-free music on iTunes.

It’s curious to note where this leaves Spotify, a company that I believe is positioned to become a serious iTunes competitor at least in certain geographical areas.

What does going drm-free tell us about Apple’s future direction for iTunes? It shows that Apple is pushing hard to break the locks that are keeping it from exploiting the full value of iTunes’ impressive catalog. If this spirit continues, it’s not unthinkable that a little way down the road iTunes will look a lot like Spotify.

Spotify makes an iTunes-like music app that differs from iTunes in that the music is freely accessible for listening, but the user can’t (as of today) download copies of tracks to their hard drive.

Spotify CEO Daniel Ek has explained his strategy is to simply provide access to music. He sees Spotify as the supplier of social objects for other social networks.

“We think music data is social objects, and we focus on building tools around them. We don’t necessarily want to be a social network ourselves. That’s also a hint on the future,”

he wrote in a thread on Jaiku earlier today.

iTunes’ per-item sales and Spotify’s freemium subscriptions may seem like competing business models.

However, the two are not mutually exclusive. Spotify could start to offer downloads, essentially turning into iTunes.

Similarly, Apple is not going to abandon sales of music tracks in favor of subscriptions to a streaming service. But it could easily add a free, ad-supported streaming mode (and an ad-free subscription mode) to help drive its per-item sales — essentially turning into Spotify.

If iTunes were to offer free access, where would that leave Spotify? Remember, iTunes killed another promising startup Odeo by becoming a podcasting platform…

Spotify’s success against iTunes is determined by how well it can exploit the fact that as both an online distributor and device manufacturer Apple wears two hats. As a result, the iTunes store is not available on non-Apple portable players (save for the Motorola rokr failure).

The interests of Apple the device manufacturer and Apple the online distributor are fundamentally in conflict. It’s in the iPod unit’s interest to keep iTunes proprietary to the iPod; whereas the iTunes music store would increase its sales significantly if it shipped on third-party devices like Nokia phones the way it does on the iPhone today.

In the end this is a business equation to Apple. As long as Apple makes more money selling iPods, iTunes is likely to stay proprietary. But if the iTunes store were to outgrow the iPod business into the company’s de facto cash cow, or the iPod started to lose market share, Apple could ditch the iPod and integrate iTunes with other portables.

It’s in Spotify’s interest, therefore, that the iPod does well but not too well. Apple has to be compelled to keep iTunes proprietary, but worldwide sales of music players has to be made up of a significant percentage of other manufacturers who want iTunes but are left to look for other options.

As long as iTunes remains locked into the iPod, Spotify has a shot at becoming the de facto music distribution platform for the rest of the world. Of course it’ll face tough competition from other proprietary and open initiatives.

Update: see story on ReadWriteWeb about the latest Activity Streams working group meeting.

For a while now many in the microblogging community have been wondering how to add contacts and exchange updates & comments across services.

For instance, some of my friends are on Jaiku, others are on Twitter, and a third group use Friendfeed. How could I follow everyone without having to deal with creating and managing an account on all three?

Currently, we’re forced to treat services as proxies for communities. For instance, my Twitter and Friendfeed contacts are mostly North Americans, whereas my European friends are on Jaiku.

This is not dissimilar to the way telephone networks used to work in the early days. To call someone, both the caller and receiver had to be on the same network.

Thankfully this is no longer the case with email. Imagine how restricted our day-to-day communication would be if mail servers didn’t interoperate.

Metcalfe’s law says the value of a network grows exponentially in relation to the number of members on the network. Walled gardens have been a bad idea from the start, since they limit the growth of the network. Because of this dynamic, they destroy value – and eventually also themselves.

There are two roads to the inevitable end state where everyone is reachable. Either the little networks agree on a standard for interoperating; or they get devoured by the most powerful player and the world is left with a monopoly.

In telecoms, AT&T gobbled up the regional networks — only to be artificially broken down into a dysfunctional set of baby bells by an antitrust ruling.

This Friday at the Learning about the Open Stack event, John McCrea described how AOL and the other internet walled gardens were brought down by the open Web.

And today, proprietary IM networks are being stamped out by an open protocol, XMPP.

The urgent issue now is to prevent microblogs from becoming the next dysfunctional dinosaurs.

A bunch of activity stream interoperability initiatives have been put forth in answer to this call, and the viable parts are now converging under the open stack umbrella term.

What the community is looking for now are concrete examples and implementations.

In his presentation at Friday’s event, Chris Messina demonstrated the use case of subscribing to someone who lives on a foreign Web service.

In what follows I’ll expand on Chris’ story by discussing another use case, where you add the foreign friend to your address book without needing to go to their site.

Imagine I want to add a friend, David Recordon to my contacts. I know his email address, so I click ‘add contact’ in my client and enter his email.

My client translates David’s email address into his OpenID URL, probably using a method called Email to URL Translation.

Now that my client knows where to find David on the Web, it goes out to David’s URL and fetches a little file that contains machine-readable pointers to David’s public profile and the photos, status messages, bookmarks, blogs, and other feeds he publishes. The enabling standards at work here are likely to be XRDS-Simple and Portable Contacts.

This loop is simply referred to as ‘discovery’.

Once my client is done, it is ready to display its findings to me. Here’s a mock-up to illustrate what I might see (the same mock is in Chris’ slides):

After selecting David’s contact information and some of his feeds, I click ‘Save’, and a subscription request is sent to these services. They return a few of David’s most recent public updates to me.

The next time David logs into these services, he sees a standard new subscriber notification. His service can perform discovery on me to display my name and profile summary to him, and allow him to reciprocate.

David may also choose to allow me to see some of his private information, such as his contact details. The enabling standard here is of course OAuth.

I have never needed to join any of the services David uses; in fact, I don’t even need to know their names. It is irrelevant to me if he uses Twitter, Plurk, or Friendfeed to publish his status updates or prefers Flickr, Photobucket, or Picasa for sharing his photos. All I care about is seeing his updates and being able to respond to them using my own client.

Information wants to be free, and social objects want to travel.

For a nice demonstration of federation in action, see this video by Sebastian Küpers.

I took a call with a few Nokians today about innovation. Constrained by the 140-character limit on microblogs I crammed the bottom line of my hour-long argument into three points. The note started getting comments on Jaiku and pick-up on other blogs, so I thought I’d post them here:

1. binge on your own dogfood
2. live by usage stats
3. iterate like mad

Like @constantine notes in the Jaiku thread, the real decision power comes from executing on this. A lot of people ‘get it’ but that’s not enough.

People also misinterpret the third point to mean you should release constantly without any quality control.

Those folks miss that there’s a progression here: keep dogfooding and only release when you can no longer not release. Then iterate based on what features get usage.

The secret is actually not included in my list. It is to hit the right feature set for launch.

A lot of startups end up in feature-shaving mode. One day they wake up to the painful reality that their product is too complex because they tried out a lot of different ideas.

Although obesity is not a great starting point, there are examples of successful overhauls. For instance, the first version of Flickr was a Flash application with real time chat and photo sharing. Few if any of those early features remain on Flickr today.

I believe turnaround always requires external shock. Often comes in the form of a change in leadership. When I asked a friend on the Flickr team if some specific event took place that enabled the company to execute such a drastic change of course, he replied smugly: “Caterina happened”.

I’ve also been asked many times if industry gatherings are a waste of time for startups. This conversation happened after LeWeb and it seems to recur every time an event splits attendees’ opinions.

Personally I’ve found that events and partnerships that go live on a certain date are great ways to force a big bang release. They help the team to focus and create a building sense of urgency. And it’s gratifying to ship just in time for a party :)

There’s probably lots more to be said. Feel free to add your points to the list.

This year Google handed out limited-edition unlocked G1’s to employees as christmas presents. I picked mine up a few hours ago.

Although I’ve been carrying various versions of the handset for over a year now, it was a new experience to open one of my own from a real consumer box.

The G1 is very close to a post I wrote 3 years ago on the missing disruptive mobile device. (Thank you, Matt Jones, for reminding me about it. I hope the day comes when you emerge from behind the camouflage and return to blog for us once more).

While the power of the G1 in terms of features and functionality is unparalleled, the basic user experience is still a bit stuttery and not yet as velvet-smooth as flow on the iPhone.

If they were Argentine tango dancers, switching from the iPhone to the G1 would be the equivalent of pairing up with a beginner after coasting smoothly with a top dame or don.

This particular beginner is a fast learner though. It also has social object-producing capabilities none of the others have.

The top Android app lists by Gizmodo and TechCrunch seem a bit dated. If you’re an Android user or following the developer circuit, let’s hear from you! What apps should I be installing?

In December 2007 Brian Oberkirch and I sat down in my home in San Francisco for a discussion about social objects. This week Brian added the conversation to his series of podcasts on social software.

Although it’s been a year and some of the discussed services have evolved (for instance, OpenSocial has progressed in leaps and bounds), the discussed ideas continue to be at the core of my work.

Here’s a topical breakdown of the 42-minute MP3 file in roughly chronological order:

• definition of a social object
• Facebook and OpenSocial
• what makes a good social object
• verbs
• making objects shareable
• turning invitations into gifts
• charging publishers not spectators
• status updates as social objects