Twitter, in and of itself, is pretty stupid. Or to be a bit more analytical and precise, as a web version of a cell phone Short Message Service (aka SMS), it's incredibly limited functionality provides little room for practical value. (It actually started as a way to reflect a message from one cell phone out to a group of friends on their cell phones, via a web based facility.)
By itself, Twitter is a very limited tool that would be permanently consigned to a narrow audience as a small utility function. You can easily think of 5-10 such services that you've tried and (probably) discarded, a few of which you keep using for their narrow purpose.
So what differentiates Twitter from hundreds of other narrow utilities that came (and mostly went)? In a word, a Service Oriented Interface.
Twitter started from day 1 exposing a simple straightforward Web Service interface. Even further, they never offered a feature without simultaneously exposing it. In other words, there is a Twitter "Engine" and there is a Twitter Web Site. The Twitter web site is just another client of the engine, and the engine is fully open for use by anyone.
Further, Twitter never pushed their web site as the primary place to access Twitter, nor even the best place. Their own web site advertises the API and the many products others have created to access Twitter.
So while Twitter had a very narrow set of capabilities, thousands of developers thought of ways to use and leverage Twitter "if only it had ....", and then created the missing functionality. The result was URL shorteners (aka bit.ly), fancy clients (aka Tweetdeck), clients for other devices (iPhone, Blackberry, etc), interfaces into blogging platforms for "notifications", even games (such as Foursquare).
All of this is a perfect example of well defined SOA utility services at the right level of granularity. Simple and easy to use interfaces offering discrete bits of function. Not too discrete that I have to figure out how to put multiple together to work, each completes a "business function" by itself. But not too high level that I'm locked into the vendor's business model.
The result has been an explosive growth of functionality layered upon Twitter.
Now lets take a look at Google Buzz. Google comes along focused on the friend/follow model of Twitter and extends it by automatically creating those relationships using a new algorithm that scans your Gmail interactions to determine relationships. They then offer a richer and more capable client, which can accept longer messages, pictures and/or video. They tie it in to all their providing platforms...if I blog on Blogger it shows up on Buzz, if I read it in Reader and "like" it, it shows up on Buzz. My Tweets can reflect to Buzz, any pictures posted on Flickr or Picasa are buzz'd.
So the client presentation and the native interfacing are worlds ahead of Twitter. But, what Twitter offers for client interaction may be only 5% of what one can do with Twitter, due to all the leveraged API developed tools and features by others. By offering a complete and easy to use SOA interface set from day one, Twitter reached hundreds to thousands of times it's own team's development capacity by allowing full public use of the engine for development of other tools.
Buzz, on the other hand, is currently offering a very limited API - with the API focused on reading the (Buzz stream) data. Further, the API is oriented around public yet somewhat complex standards. "Update feeds are returned in the standard Atom Syndication Format (RFC 4287). Update feeds may contain references to rich media elements, such as audio, images, or video. When available, these media elements will be exposed via the MediaRSS extension..." (Not to worry, it is possible to link an external source into Buzz if "sites are publicly associated with a Google profile, to associate a new feed with a Google Buzz account, the owner of the external site must point back to the Google profile (directly or by association). To make this claim use XFN markup. Site feeds may be published in either the standard Atom Syndication Format, or in many of the variants of the RSS format.")
To summarize Google's position, "Over the next several months Google Buzz will introduce an API for developers, including full/read write support for posts with the Atom Publishing Protocol, rich activity notification with Activity Streams, delegated authorization with OAuth, federated comments and activities with Salmon, distributed profile and contact information with WebFinger, and much, much more."
Well, as a highly technical developer I appreciate a rich feature set and the ability to interface deeply. However, I've worked with some lightweight web site developers and watched them integrate Twitter into their site (not a Twitter widget but integrate to publish site updates as Twitter tweets) in 3-5 lines of PHP code. And frankly I greatly appreciate being able to drop in functionality like Twitter in a few lines of code.
The fact that the Twitter API is so simple to understand and therefore easy to use is the reason that there are tens and hundreds of already developed features which move Twitter from an API based model to a widget or 3rd party utility model.
And in my evalation it is the reason that Buzz will be unsuccessful. If features in the basic vendor web presentation were the success or failure in this space, Twitter would have died long ago. Even providing a better micro-blogging/short message service engine doesn't make a difference.
Twitter's success is it's easy to use SOA web services. And Google, being overly technically oriented, completely missed that point.
There's an important lesson here for Enterprise IT and enterprise architecture. Quick and easy to use tops a very well architected full featured but hard to understand and use API. And when quick and easy is also well architected and powerful, the value is easy to see and the reuse multiplies.
By itself, Twitter is a very limited tool that would be permanently consigned to a narrow audience as a small utility function. You can easily think of 5-10 such services that you've tried and (probably) discarded, a few of which you keep using for their narrow purpose.
So what differentiates Twitter from hundreds of other narrow utilities that came (and mostly went)? In a word, a Service Oriented Interface.
Twitter started from day 1 exposing a simple straightforward Web Service interface. Even further, they never offered a feature without simultaneously exposing it. In other words, there is a Twitter "Engine" and there is a Twitter Web Site. The Twitter web site is just another client of the engine, and the engine is fully open for use by anyone.
Further, Twitter never pushed their web site as the primary place to access Twitter, nor even the best place. Their own web site advertises the API and the many products others have created to access Twitter.So while Twitter had a very narrow set of capabilities, thousands of developers thought of ways to use and leverage Twitter "if only it had ....", and then created the missing functionality. The result was URL shorteners (aka bit.ly), fancy clients (aka Tweetdeck), clients for other devices (iPhone, Blackberry, etc), interfaces into blogging platforms for "notifications", even games (such as Foursquare).
All of this is a perfect example of well defined SOA utility services at the right level of granularity. Simple and easy to use interfaces offering discrete bits of function. Not too discrete that I have to figure out how to put multiple together to work, each completes a "business function" by itself. But not too high level that I'm locked into the vendor's business model.
The result has been an explosive growth of functionality layered upon Twitter.
Now lets take a look at Google Buzz. Google comes along focused on the friend/follow model of Twitter and extends it by automatically creating those relationships using a new algorithm that scans your Gmail interactions to determine relationships. They then offer a richer and more capable client, which can accept longer messages, pictures and/or video. They tie it in to all their providing platforms...if I blog on Blogger it shows up on Buzz, if I read it in Reader and "like" it, it shows up on Buzz. My Tweets can reflect to Buzz, any pictures posted on Flickr or Picasa are buzz'd.So the client presentation and the native interfacing are worlds ahead of Twitter. But, what Twitter offers for client interaction may be only 5% of what one can do with Twitter, due to all the leveraged API developed tools and features by others. By offering a complete and easy to use SOA interface set from day one, Twitter reached hundreds to thousands of times it's own team's development capacity by allowing full public use of the engine for development of other tools.
Buzz, on the other hand, is currently offering a very limited API - with the API focused on reading the (Buzz stream) data. Further, the API is oriented around public yet somewhat complex standards. "Update feeds are returned in the standard Atom Syndication Format (RFC 4287). Update feeds may contain references to rich media elements, such as audio, images, or video. When available, these media elements will be exposed via the MediaRSS extension..." (Not to worry, it is possible to link an external source into Buzz if "sites are publicly associated with a Google profile, to associate a new feed with a Google Buzz account, the owner of the external site must point back to the Google profile (directly or by association). To make this claim use XFN markup. Site feeds may be published in either the standard Atom Syndication Format, or in many of the variants of the RSS format.")
To summarize Google's position, "Over the next several months Google Buzz will introduce an API for developers, including full/read write support for posts with the Atom Publishing Protocol, rich activity notification with Activity Streams, delegated authorization with OAuth, federated comments and activities with Salmon, distributed profile and contact information with WebFinger, and much, much more."
Well, as a highly technical developer I appreciate a rich feature set and the ability to interface deeply. However, I've worked with some lightweight web site developers and watched them integrate Twitter into their site (not a Twitter widget but integrate to publish site updates as Twitter tweets) in 3-5 lines of PHP code. And frankly I greatly appreciate being able to drop in functionality like Twitter in a few lines of code.
The fact that the Twitter API is so simple to understand and therefore easy to use is the reason that there are tens and hundreds of already developed features which move Twitter from an API based model to a widget or 3rd party utility model.
And in my evalation it is the reason that Buzz will be unsuccessful. If features in the basic vendor web presentation were the success or failure in this space, Twitter would have died long ago. Even providing a better micro-blogging/short message service engine doesn't make a difference.
Twitter's success is it's easy to use SOA web services. And Google, being overly technically oriented, completely missed that point.
There's an important lesson here for Enterprise IT and enterprise architecture. Quick and easy to use tops a very well architected full featured but hard to understand and use API. And when quick and easy is also well architected and powerful, the value is easy to see and the reuse multiplies.