The Case for TwttrSDK

Twitter hasn't had the best of months years. The platform is full of bots, its full of trolls and its most dedicated users are angry over changes to its API that degrade the experience for anyone using a client that isn't the one produced by Twitter. In short, if Twitter can do something to make their platform worse, they have probably tried it. The first two are probably fairly obvious as to why they are a problem for the platform, but the third one, the API changes, are a bit less obvious to most users as to why these changes are issues.

Long-time Twitter users know the history, but lets recap here for a moment. Concepts such as the term "tweet", the company logo, the use of #hashtags and the popularity of the platform itself, were all driven by developers who created apps that used Twitter's API. The concepts that make the platform what it is and largely its success, would not exist without the work of independent software developers.

But so what? Twitter is now a relative juggernaught and doesn't have the need for these independent developers any longer, right? What have you all done for Twitter recently, anyway? Twitter claims that only a very small portion of its userbase even realize that there are apps that work on the platform which are not created by Twitter. If we assume that is true, then losing those customers wouldn't be a big deal, right?

Lets take an example from a different industry... automotive. All the major manufacturers create high-end cars of which they sell only hundreds or in the low thousands each year. These cars usually cost substantially more than your average sedan and are generally regarded as only being of minimal profit to the company bottom line. So why bother with this small percentage of customers who, in the grand sense, don't mean anything?

Two reasons... first, these users are often the most fanatical for the brand; they're the die-hard customers who keep coming back because they love the product. They are the ones who advocate for the brand to anyone who will listen. Second, these automobiles are the testing platform for future capabilities. What gets created in the small scale eventually is adopted by the mass-market automobiles. Without these low volume platforms, the manufacturers don't have a way to test out new ideas in the market to see how customers respond. It should be the same for Twitter as it is for the automotive manufacturers. So how come Twitter is so hell-bent on cutting off this segment of their community?

What Twitter Wants

This is a tough one, because its mostly speculation. When it comes down to it, the reasons Twitter has given for these changes are less than satisfying. Again, lets assume they are being honest about this being a small percentage of users. If that's the case, then revenue probably isn't the answer. Third-party applications typically do not display advertising, and since Twitter isn't removing the capability of these applications completely, we have to assume that they're ok with not forcing these customers to the first-party applications, which do display ads.

Another reason that has been speculated on by members of the technology news and analysis community is that Twitter wants to have full analytic data on all users, not just those that use Twitter's own applications. I imagine that Twitter does want this data, but if they're willing to forego revenue on these customers, is usage data really that important? It seems like a stretch to me to think that, if this really is such a small percentage of users, that Twitter really cares about this more than ad revenue.

One of the reasons Twitter cites is not being able to retain parity between their third-party APIs and the first-party APIs used by Twitter's own applications. At first, this seems to make sense; maintaining two things is definitely more difficult than maintaining one thing. Focusing more your engineering teams on pushing the platform forward seems to be the right thing to do. Yet, those of us who do this kind of work realize that there is a really easy solution here... give 3rd parties access to the first-party API. Make it the responsibility of the 3rd parties to maintain their applications at parity with the first-party solution and if they don't make the changes in sufficient time, shut down their apps. Its harsh, but I think most independent developers would take that deal.

Another option

I titled this post The Case for TwttrSDK, which is a way I feel that Twitter could not only make its goals work, but also give third parties a path forward without requiring Twitter to maintain two sets of APIs. The concept is simple, but there definitely would be some work to get this to happen. I think this could be a path to make all parties happy.

Twitter would modify its own application in such a way that it is essentially two pieces: TwitterUI and TwttrSDK. (Yes, I'm oversimplifying here, but we're talking functional and not acutal architecture.) The TwitterUI piece is what users of Twitter's own app on any given platform see: the buttons, the timeline, the sign-up process, etc. Basically the pieces that the user interacts with.

Behind that is the TwttrSDK. This contains all the elements that interact with Twitter's first-party API. This is what fetches all the data from Twitter's services (timeline, mentions, direct messages, profiles, etc) and what pushes data back into the platform (new tweets, images, analytic data, etc). The TwttrSDK is then published, either as open source code or a compiled binary (probably the later), and with each new version of the first-party Twitter app, a corresponding TwttrSDK is released as well.

Third-party developers can then take the TwttrSDK, with its standard interface components, integrate it into their own apps, build their own user interface on top of it, and produce that app. With each new release, Twitter gives developers, say two months, to release a version that supports these new features, otherwise their third-party app stops working. There are other requirements that I am sure would be imposed, such as no blocking of advertising, agreement to pass back data on which tweets were seen and for how long and likely a long list of other things, but that is just the price to play.

Third-party apps generally differentiate themselves on how they display data, what their user interface looks like and features that Twitter itself doesn't do, such as remembering where the user left off in the timeline stream when viewing across different devices. These third-parties can continue to make apps that meet the needs of customers who have uses not met by Twitter's own apps.

It isn't ever easy

What I'm recommending here isn't something that would be easy to do. In fact, it would take significant changes to how Twitter develops their own apps, something they would need to dedicate a substantial amount of engineering to, but they get a lot out of this as well. Those users who they claim as such a small percentage of their total user base, are now back in the fold while still being outside enough to continue to push the platform forward.

To sum it up, the Twitter app is a Honda Civic. Its serviceable, gets you from points A to B reliably, but isn't really anything flashy. There are customers out there who want an Acura NSX, which is more car than most people need, but they can afford it and it gives Honda (who owns Acura) a playground for keeping their brand fresh. Twitter can, and in my opinion should, do the same with their platform.