Since day one Twitter took the opposite approach to other social networks — mainly the one that begins with F, ends with k, and has "aceboo" in the middle — by allowing people to build out of the service using a robust API. This helped nurture a broad ecosystem of third-party products. Now Twitter wants to turn its sweater inside out, threatening to evict developers who build competing apps. Some argue this is the right move as the company matures; others disagree.

I believe if this is the move Twitter wants to make, it should clean up its side of the street first and fix the vast inconsistencies in its own products. Also, rather than kill these third-party app-makers, maybe there's a mutually beneficial business model in their existence?

There's a some assumptions packed into what you wrote – lemme unpack a couple:

1) I'm not sure how what was posted on Friday amounts to a new policy for Twitter. Since 2009, Twitter has been saying largely similar things and the reaction this week seems similar to what happened back then.

2) Mass scale eviction seems unfounded. I could be unaware of the changes. But the LinkedIn integration was a specific deal and not just any old API use.

3) I don't think the inconsistencies you highlight in your Bits blog piece are really that damning for Twitter's apps. I think it's fine to have platform-tailored experiences. The apps could be better but that's a different thing.

From where I stand, Twitter has gradually been narrowing the categories of apps that it deems worthwhile to devote platform resources to. That seems reasonable: even for a company with Twitter's considerable resources, there are only so many developer support hours in the day and CPU cycles to go around. Twitter is trying to clarify what sort of apps it will really support, not evict all third-party developers wholesale.

I disagree with Goldman on how damning the inconsistencies in Twitter's own apps are, though. Twitter should be setting the precedent for quality in its developer ecosystem, and as Nick's piece points out, they demonstrably are not. It would be nice to see them keep their apps consistent, usable, performant, and current.

I think it'd be good if the same logo was consistent through out and if there were new features like read state across the suite. But stuff like differing button placement may actually make sense for the platform in question. I would push to consider even wider inconsistencies and try new concepts for consuming non-follower content on iOS instead of just repeating the tri-tab layout everywhere.

To be clear: I think there are lots of improvements that could/should be made to the native apps.

I think the consistency that's needed isn't really about UX. It's about being able to expand and adapt the nature of Twitter itself.

Yes, the iPad app should take advantage of the iPad's format, and that sort of thing. I use and like TweetBot on iPhone and iPad, but the tablet version doesn't really make great use of all the screen real estate available to it. Twitter could do something really creative and different with its iPad app. But they need to nail the fundamentals first.

A parallel here is Apple's iCal: say what you will about its skeuomorphic UI elements, but it adapts reasonably well to desktop, iPhone, and iPad in terms of information display. That's not enough, though. There's a market for un-innovative competing calendaring apps like BusyCal because iCal is unstable, poor at input, and only sees major updates when Apple ships new versions of its OS.

Definitely true. The U.I. issues do go beyond logos. But when I'm explaining to my family how to use Twitter and I get them all buttered up on the iPhone app and then get a calling asking "Where's the Tweet button on the iPad?" It shows me there is a potential consistency issue.

Question: Let's just say, hypothetically, that Twitter decided it was going to cutoff apps like Tweetbot. Isn't there a scenario where those optional experiences can be leveraged into additional revenue? (I don't know how, just an idea.) This seems to be the issue most people are complaining about, the all-in options that might exist in the future. (I know this is assumption, but Twitter isn't saying whether it's a right or wrong assumption.)

I admit that I'm less concerned about the UI stuff -- as Jason points out, there can be benefits in having different experiences for different platforms or use cases, although lots of things about the iPhone version bug the heck out of me.

But I do think that Twitter is bent on ratcheting up the API controls -- otherwise why mention it at all? The problem is that we don't know what it is going to do, and so there is lots of fear and uncertainty. And developers feel somewhat gun-shy with good reason, I would argue.

Anil's point seems to be that developers are just whining because they have lost control and Twitter is a big company that can do everything on its own. I think that kind of attitude has risks, but I could be wrong :-)

Without waxing too nostalgic, I still think that there is a huge benefit to being a massive open platform because you never know what app or business model some developer may build on the platform. By "maturing" Twitter ends up limiting the number of possibilities for what it still could become.

The idea of charging for access to 3rd party apps or Twitter exerting this control just because that's what BigCos do misses a more obvious motivation: It's in the best interest of users if the nature of Twitter (what Tweets look like, how you can interact with them) is fluid and adaptable. By asking Twitter to treat tweets more like an open standard you give up some of this flexibility.

There's an analogy (not mine) to email: it's great that SMTP is a standard bc that lets clients and ISPs interoperate. But it also means that the fundamental form of email has been substantively unimproved.

I'm biased but I do believe these changes are considered first and foremost from the perspective of what is best for users.

One thing that's being missed a bit here is that Twitter really seems to be tightening its grip on site/services that ingest tweets, not that facilitate posting to Twitter themselves. They haven't made moves like throttling third-party consumer apps like Tweetbot (as Facebook has), but instead cut back the means by which tweets can be used as content.

Perhaps, as this move and a few others suggest, Twitter recognizes the benefits to users of having an open and usable API for things like Twitter clients (which help them harvest more user-generated content), but are actually realizing the power they hold in distributing that content. They care abotu user UI, butthey need to make the most of the resources they collect everyday: tweets.

Okay, I'm gonna way oversimplify this. Here we go.

The way I see it, this whole "Delivering a consistent Twitter experience" controversy has nothing to do with Twitter as the "realtime cloud API company" (see: Dalton Caldwell). It's about a stale end-user experience that's not evolving fast enough.

No one cares about that LinkedIn integration. Good riddance. But I have a hard time believing the fate of the API would still touch a nerve if Twitter actually led the market in the best designed, most innovative Twitter clients and experiences.

Imagine if Twitter iterated and experimented as quickly as the other guys in building great new products for its own medium.

Ship great product. Maybe then this API conversation won't matter as much.