The last couple of weeks have been Apple's.  

Next week, barring some unforseeable disruption, belongs to Twitter.  

And it's already started. First, Fred Wilson telegraphs that there are changes coming in the relationship between developers and the platform vendor. Then, yesterday -- late Friday afternoon (the deadest time of the work week in the tech blogosphere) Twitter announces they are acquiring the leading Twitter client on the iPhone, Tweetie. 

So what does this mean for Twitter client developers? 

First, there are other platforms that have excellent Twitter clients. And there are different types of clients, aimed at different kinds of users. Tweetie is unusual in that it aims for simplicity and elegance, where most of the others are designed for people who push Twitter to its limits. It could be that Twitter will acquire clients on other platforms, or designed for different users, but I don't actually think they will. I think Tweetie will be it in the client area, at least for a while. Instead of acquiring products on other platforms, I'd bet they'll hire expertise, and port the Tweetie code base to Android, Macintosh, iPad, Windows, maybe even Flash (I hope so, someone has to challenge Apple). The reason -- maintainability and cost. It's a lot easier and cheaper to upgrade one cross-platform codebase than it is to synchronize upgrades across multiple codebases.  

So now there's Tweetdeck, Twitterific, Twitroid, Brizzly, etc. Would you, if you were them, just roll it up and send flowers to the Tweetie guys and go back to consulting or working at Starbucks? Or would you try to make a go of it in an environment where you compete with the platform vendor? I hope at least some of them try to make a go of it. And the reality is that they were always competing with the platform vendor whether or not they chose to recognize it. Nothing new there other than awareness. 

I'd wait to see what else Twitter announces this week. If they announce the metadata-rich platform that I outlined in yesterday's post, and I expect they will do this (my post was not a complete shot in the dark), then you have a chance of producing a more specialized product aimed at a narrower niche, using the new status properties to tag messages invisibly with information about their origin (following the example of the dog-who-tweets outlined in that piece).  

The scary part is if Twitter announces the metadata capability but doesn't ship it. And you know what -- I bet they do that too. There's zero cost to them to announce it if they don't have to ship it immediately. In fact, they never have to ship it. But it has the effect of forestalling a similar effort by client developers, which I would get ready to do, no matter what Twitter does this week. 

The way you start is by offering an option to save your users' tweets to a public server in RSS 2.0. You're not exposing any data that isn't already public in their tweetstream. And you're providing a backup. You're also providing a way for other Twitter clients to find your users' stream without going through Twitter. This means you can upgrade the stream on your own schedule, without having to wait for Twitter. All this requires is that you cooperate with your competitors, the ones who, like you, did not get bought by Twitter. This has always been a tall order, but it's what you will have to do to chart the new waters. (And if you go first you don't have to cooperate, unless a big competitor decides later to be incompatible, in which case I recommend you capitulate and go with their way.) 

I advised doing this, privately, to various client vendors over the last couple of years, but all of them held out hope that they would be the one that Twitter would buy. They may still hope for that, but everyone should admit that the chances are much slimmer now. Whatever you do will be answered by Twitter, so you have to make your stuff work better, and offer features they aren't offering, and independence to your users that they don't offer. You want to segment the market, as Fred even encourages you to do in his post, yet retain compatibility. It's hard but it's possible. 

Why do I know so much about this? Because this exact advice would have served the Macintosh app developers in the early 90s before the web swept up our whole world and (thankfully) turned it upside-down. We were stuck in an unworkable relationship, all of us, with the platform vendor. If the developers had discounted the chances of being the favorite of the platform vendor and emphasized working with each other as equals, we might have had a chance. But as long as each of us was betting that we could be the Number One Wife, we had no chance. Same thing here, but now Twitter has made a choice, and that makes moving on easy, where it wasn't before.  

PS: Another example, Microsoft went with PowerPoint instead of my product in 1987.