Home > Archive >  2009 >  December >  1

We need: An open source Twitter shell

Tuesday, December 01, 2009 by Dave Winer.

It would do more or less exactly what the twitter.com website does. Same prefs, same commands, same user experience. Think Apache for the Twitter user interface. 

In my explorations of a hypothetical decentralized Twitter, at first I thought the clients would be where decentralization would happen. But, lately I've come to realize that it probably won't happen there because as the market has evolved they've become too dependent on Twitter Corp, and are unlikely to do anything that might threaten a friendly relationship with the company.  

I saw this first-hand in the Mac software market in the early 90s. Even when it would have been in the interests of developers to work with each other, each of them tried to do special deals with Apple. Of course no one really got those deals, so we all went down. But it's human nature to think you're special and if you play nice with the platform vendor, they'll play nice with you. And the platform vendor may totally mean to be nice, but they can't help acting in their own self-interest and that almost always is at the expense of the developers.  

So if the commercial developers can't or won't break free of the platform vendor, let's create an open source client that can be repurposed in as many different ways as we, as individuals want. Some of us may want to do deals with Twitter Corp, and that's fine -- but others may wish to embark on paths that are independent of Twitter. They wouldn't try to guess what would make the platform vendor happy, and instead follow the grain of the Internet, or go where the users want to go, or some users, or to scratch their own itch. Some may want to be part of the Cathedral and others part of the Bazaar. :-) 

I'm not even 100 percent sure what I'm asking for, but I'll know it when I see it. Probably a JavaScript framework that comes with a Twitter timeline object. So displaying a timeline is automatic as are the user interactions. So any kind of client, one written in any language -- Python, Perl, Java, JavaScript, PHP, C, etc -- could store data in it. It wouldn't know anything about the Twitter API. It would be up to the applications to put data in the structure.  

It would do more or less exactly what the twitter.com website does. Same prefs, same commands, same user experience. Think Apache for the Twitter user interface. It would, of course, be programmable through a user scripting language.  

Having this one component would let a thousand flowers bloom in exactly the place where we need them to bloom. The key thing is to find out what would happen if we could take a path that was not designed to please the platform vendor. Note I carefully did not say "to piss off the platform vendor." I really do mean to chart courses that are independent of the vendor.  

What would be even cooler is if one of the client vendors decided to release their code under the GPL. Or, even better would be if Twitter Corp did it. That would be hugely disruptive and would likely lead to some very serious innovation. :-)