Delivering a Consistent Twitter Experience
Back in March of 2011, my colleague Ryan Sarver said that developers should not “build client apps that mimic or reproduce the mainstream Twitter consumer client experience.” That guidance continues to apply as much as ever today. Related to that, we’ve already begun to more thoroughly enforce our Developer Rules of the Road with partners, for example with branding, and in the coming weeks, we will be introducing stricter guidelines around how the Twitter API is used.
Were I a Twitter client developer, I would get in touch with other client developers and start talking about a way to do what Twitter does but that doesn’t require Twitter itself (or any specific company or service).
When Twitter started to get traction, a year or two into their existence, I decided that Twitter was the Best Thing Ever. I realized that Twitter, because of their API, actually was a real-time protocol to connect various services in a novel way. I had debates with my other tech-nerd friends about whether Twitter could be one of the fundamental building blocks of the Internet via their powerful API.
Update (2012-07-07): Dave Winer:
Conclusion -- corporate APIs are good for the corporations that own them, and pretty much bad for everyone else. I would be reluctant to develop on any corporate API unless I was prepared to have my work completely deleted or obviated or usurped by the platform vendor. You really don’t have any power. However it’s pretty much impossible to avoid them. But try to.