You've made a fantastic argument.  The "official reasoning" stated in the 
original message is clearly contradictory as you point out...I think any 
jury would tilt their heads on that cross-x.  

I've been sitting on this for a few days and can only make some distant 
observations. Being relatively new to twitter (and to the API -- and 
especially to the dynamic going on at present) I'm trying to put this in 
context of corporate motivation *vis-a-vis* the User Experience  with 
Twitter Clients.

The apps I use on my iphone and Mac are...let's say...*very much possible*to 
improve upon IMO.  It is not comprehensible to me why Twitter would want 
to squelch* **something new or different* *introduced*  with regards to the 
User eXperience...*especially* for new users...with Twitter clients.  As a 
programmer...it's the first thing I wanted to do -- and the whole reason I 
started digging in the API in the first place a few weeks ago....to bring 
something new to the table that I don't see there.  It seems many people on 
this site feel similarly with regards to existing Clients.  Innovation is 
far from over on the Client side...and...seemingly...should be encouraged as 
many posters have pointed out.

There is justifiable motivation for Twitter to capitalize on their 
service...it is brilliant, categorically historical, and as a comm channel 
blurs the lines between casual chat and causality in real-world events of 
true historical nature.  But is Twitter trying to put its own clients "on 
every desk and in every home?"

My personal opinion is that the threat to the company is not in the access 
to the twitter stream backend (data mining, streams, etc...)...it's to the 
frontend (the firehose backend is being 3rd partied already a la gnip.com).  
The user still has to enter 160 chars --somehow/where/way, and  if that 
stream were ever diverted --  game over.  A Twitter client is that front 
end.  The user entering text into a client is the *sine qua non* of 
Twitter.  That's not a local firehose per user...that's a sparse tweet ... 
once or twice a minute peak.  But the Twitter client frontend is the 
gateway, and it's not that hard to code a basic Twitter client via the API, 
so there can be a lot of Twitter clients out there...and some of them might 
be better than Twitter's.   Is this what they are trying to control?

For Google (search) ...it is to use their search engine and free services to 
bring you to advertising.  If users started using another search engine, 
Google doesn't get data.  Google's search engine has pretty good legs so 
far...and it's proprietary of course.  You enter search text on any handful 
of *standard* web browsers.

For Facebook...network people together to share pics and relationship 
status.  You could probably make facebook server code OSS...it's the 
existing network in-place that keeps people there...it was first and it has 
a brand.  Facebook gets a lot of traffic on their web clients...and a lot of 
data on what people say to each other.  You mostly post your status via *
Facebook's* clients:  web pages via standard browsers or *their* mobile 

For Twitter...there is an in-place network all right, but you can post your 
status (160 *golden* characters) via any number of clients. 

Is this really the threat??  If so...it would seem that most of the API 
accessibility would just steadily disappear over time...


Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 

Reply via email to