@steveE: 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 apps. 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... @jameswinkle -- 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: http://groups.google.com/group/twitter-development-talk
