As regards developers, their message is to not build "client apps that mimic or reproduce the mainstream Twitter consumer client experience". However, the mainstream Twitter client experience may at any time be expanded to include whatever you're doing already. That's always a danger when building on someone else's API like this, but the 'inflection point' comes when a company actually starts replacing 3rd party developers' tools with official products.
That should help developers decide what to do next... In my case, it's more clear that I don't want to have anything to do with the Twitter API.
Building applications that are nothing but Twitter enhancements is probably not a good bet; at least, not if it's your only bet.
Saying that, it would have been nice if they'd got there sooner.
If there is anything we know from twitters past; uptime will be minimal with a bandwidth intensive service such as this.
Many of these features should have been done a long time ago, instead of letting an eco system grow as deeply as it did, knowing full well that any opportunity to monetize the platform would involve cannibalizing developers and creating resentment.
Having said all that, I'm looking forward to these changes as it will definitely create a more cohesive user experience.
However what is not cool is the way in which these directions have been taken and the path chosen over the past year or so.
So yes great move for Twitter, the ecosystem and millions of users but somewhere this is getting ugly for companies that were solving this purpose for over 4 years when Twitter did not feel it necessary to do so for "users".
Personally, though, I still don't like how they are pushing out third-party developers, but I see some understandable motives for the decision.
warning the ecosystem to stay away from building “client apps that mimic
or reproduce the mainstream Twitter consumer client experience.”
That might be what they're saying, but what I'm hearing is stay away from any Twitter integration.