The cross-country drive has become a ritual for me, it signals a major shift in my life, usually for the better.
Anyway, thinking about what Twitter may announce next week, I recalled that when the Google was getting ready to announce what everyone thought was their Twitter-killer, I wrote a piece outlining the product that I thought would be a good answer to Twitter. Instead Google shipped the disappointing in-so-many-ways Buzz.
Now, let’s try that experiment in reverse. Suppose Twitter wants to make their offering much more competitive and at the same time much more attractive to developers. Sure, as Fred Wilson telegraphed, some developers are going to get rolled over, esp those who camped out on the natural evolutionary path of the platform vendor. But there are lots of things Twitter Corp can do to create more opportunities for developers, ones that expand the scope of the platform and make it possible for a thousand flowers to bloom, a thousand valuable non-trivial flowers.
The largest single thing Twitter could do is open tweet-level metadata. If I want to write an app for dogs who tweet, let me add a “field" to a tweet called isDog, a boolean, that tells me that the author of the tweet is a dog. That way the dog food company who has a Twitter presence can learn that the tweet is from a dog, from the guy who’s developing a special Twitter client just for dogs, even though Twitter itself has no knowledge of the special needs of dogs. We can also add a field for breed and age (in dog years of course). Coat type. Toy preference. A link to his or her owner. Are there children in the household?
There’s plenty of prior art. Two examples I can think of are Apple’s Resource Manager and Amazon’s SimpleDB. There are probably many others. (I should mention that Frontier’s object database, the core structure around which it’s built is also prior art. It’s also open source. Feel free to use the ideas.)
There are some nice things that fall out of this architecture, if Twitter should choose to do it.
1. No more need for URL-shortening. The URL becomes just another piece of metadata attached to a tweet. If you need to shorten it on its way out through an SMS gateway, go for it. (Even though I’ve said it explicitly, I’m sure I’ll have it “explained" to me that because of SMS, the URLs must be shortened for everyone, even if we don’t use SMS. Pure nonsense. These guys should take an introductory course in Computer Science.)
2. You can attach a picture to every tweet, and still link to an article. Just make “thumb" or something like that a default bit of metadata. (An aside, why not use the conventions of XML to define the metadata. All the elements of the core namespace are reserved for Twitter. If you want to extend it, create a namespace and have a party. Please no meta-meta-language though, just let a little chaos reign. It must at some level.)
3. You can also support long and short-form tweets. The 140 characters can act as a synopsis for the longer text that’s included in the tweet. This would give people the feature they’re always asking for in RSS feeds — full text.
4. A developer like Disqus could implement a full threaded discussion system for every tweet, and thereby give Twitter a way to compete with Facebook and if Google ever gets its act together, Buzz.
Now of course all the developer opportunities created by open metadata just open the door for more tears in 2014 when Twitter forecloses on the developers who figured out where the gold was in those APIs. But my friends the developers, that’s how it always is when you develop for a corporate-owned platform. You have to make peace with that reality before you write your first line of code.
PS: The iMac that I usually write on is all packed up, I’m writing this at the kitchen table amid all kinds of boxes with my Asus 1005HA netbook. It’s pretty good, but it’s not as comfortable as my desktop. Please allow for that in your critique of this story. Thanks!