The idea is floating around that Twitter will allow users to edit their tweets, possibly for a limited period of time. I agree with the desire for this feature, but it won’t work. Once a tweet is published, copies of it are delivered in real-time to thousands of data collection scripts capturing tweets with the streaming API. These copies are then put into thousands of databases, in some cases with the goal of permanent storage. It is impossible for Twitter to force changes to these stored copies of tweets once are delivered by the API.

This problem is apparent right now when tweets are deleted. Old copies remain all over the Web. In theory, the Twitter Terms of Service requires developers to remove deleted tweets from their own tweet storage. The streaming API even sends out a signal to alert developers of deleted tweets, so they can be removed. In practice, this issue is ignored, and deleted tweets remain permanently available at sites like Topsy.com.

Keeping track of changes due to editing tweets will be even more difficult. The edit may be allowed on Twitter.com, but then a mechanism must be added to the streaming API to notify all consumers of this stream that an edit has been made. Even if API users wanted to update their own databases to reflect the edits, pushing through these changes to an entire tweet collection system will require major rewrites. The contents of each tweet such as tags, @mentions and URLs are spread throughout complex data structures with the expectation that they are written once and never change. I see it as highly unlikely that these rewrites will be made. So unlikely that it just won’t happen as a general rule.

Twitter can try to allow edits to tweets, but the results will just be a mess, with multiple copies of each tweet popping up from different sources.

We converted the Twitter API Engagement Programming book to Kindle version last week, and it is now available in Amazon stores all over the world. If you don’t own a Kindle, Amazon provides a free reader app for Windows, Mac, and all major mobile devices: iPad, iPhone, Android, etc.
http://www.amazon.com/gp/feature.html?docId=1000493771

This is the first Kindle book I’ve produced, and the process has given me lots of ideas for new projects. I’m going to work on the native iPad format also, but for now the Kindle reader works fine on an iPad.

You can download the kindle version of the book on the main Amazon.com site at:
http://www.amazon.com/dp/B00G3OCA0K

Or you can go to the kindle store in your local Amazon site and search for “Twitter API Engagement”.

The print version of the book will remain on the Amazon.com store only for now, but you can have it shipped from there to anywhere in the world.

To say that the relationship between Twitter’s management and its API developer community has been rocky over the last couple of years would be an understatement, so it isn’t surprising that some developers and tech bloggers have speculated that after the Twitter IPO access to the API will be removed or severely restricted. I can understand the fear developers feel about the API’s future, but my view is that Twitter’s IPO and many of its actions leading up to this event prove that the API will remain open and free.

1. Twitter has explicitly stated in its prospectus that the API and its developers are a key part of its product offerings. There are 6 mentions of the API in this document and they all clearly promote it as a core value to its users. Here is one example:

The value we create for our users is enhanced by our platform partners, which include publishers, media outlets and developers. These platform partners have integrated with Twitter through an API that we provide which allows them to contribute their content to our platform, distribute Twitter content across their properties and use Twitter content and tools to enhance their websites and applications.

Removing access to the API after declaring it an integral part of their product offerings would leave Twitter open to a shareholder suit for misleading the public.

2. The release of the 1.1 version of the API in the first half of 2013 was clearly timed to coincide with the IPO. Twitter must have known they were aiming for an IPO this fall when they planned this new API, and wanted to get what could have been a messy launch of this new version out of the way first. This tells me that the API is meant to last long after the IPO. Otherwise Twitter could have saved itself a lot of work by just sticking with the old API until it was killed.

3. Keeping the API publicly available is a significant cost in staff and servers. Since one of the criticisms of the IPO is Twitter’s continued losses, it would have been better to kill the API before the IPO, and then project greater future profits due to lower infrastructure costs. Twitter didn’t follow this path, proving that they are willing to absorb the costs of the API as part of their necessary technology.

4. Investors hate uncertainty even more than development clients. One of the missteps Twitter has made in the past with the API has been creating high levels of uncertainty by announcing that changes would be coming in the API, but then waiting months to reveal the details. I have lost more clients during these periods of uncertainty than at any other time in my working with the API. The stock market will not allow that type of behavior. Whatever Twitter does with the API next, they must do it in a much crisper fashion, or the market will teach them to do it that way.

5. If there is a compelling case for the API surviving long-term, what about the possibility of Twitter deciding to charge for access? That is always a possibility, but the downside is that developer access to the API must then become a profit center. Once you go public, every action is either a profit or a loss, unless you make it an intangible. There is no attempt in the prospectus to tie API access directly to a financial benefit. It is described as a qualitative benefit without any direct financial gain. This is much safer than trying to transition to a paid API model, and then have reporters and analysts constantly asking for proof that it is pulling its own weight. Even the advertising API is presented as a way to sell more ads, not as a way to sell the technology of the API.

In full disclosure my income is dependent on the continued availability of the Twitter API. I have been a full-time API developer for 5 years, and I just launched my first book in a planned series on Twitter API programming. If I thought there was any chance of the API being closed to developers, I wouldn’t be making this new commitment.