Epic FailI just got home from a two week trip. While disconnected, I had a sudden brain fart. I saw Twitter reinvented as a distributed system and provided free as open source. This morning I woke up to find the ‘Twitter Fail Whale’ in full effect. Twitter is, once again, overloaded with users. This is so common, that the Fail Whale is now a t-shirt! I believe it’s time to re-think Twitter.

Twitter is not the only service of it’s kind. Birghtkite bumped the concept up a notch by adding imagery and positioning. Meanwhile, Plurk found a creative new way to display a user’s timeline. It’s great to see innovation; but this brings us to the same problem that service like Ping.FM, HelloTxt, and Socialthing were created to help us manage – too dann many segregated service providers!!! And as the alternative providers become increasingly popular, they too will suffer the same ‘single point of failure’ issue that hinder Twitter today.

This post is a call for change. I think we can learn a valuable lesson from another Internet technology. You may have heard of it: E-mail.

As an E-mail user, I can send a message from any service provider and feel fairly confident that it will be received by the intended party – regardless of what service provider they use. E-mail works across platforms because there exist a standard protocol allowing different systems to communicate with each other and work together.

Furthermore, I can choose to become a provider myself. I can download any of a variety of open source E-mail servers and install them on my own server. Because the service is tied to a domain name, I can give my service an identity that’s associated with my personal, company, or organizational branding. As an added bonus, in the event that I want to modify how my server works, I have full access to the source code to my software and a wide variety of documentation on how E-mail works.

Now, apply these concepts to Twitter. The same way Hotmail, Gmail, and Yahoo Mail offer E-mail services – Twitter, Brightkite, and Plurk can still continue to provide their services to the public as they always have. However, with a standard set of communication protocols, users on one system could potentially interact with users on another.

Furthermore, with an open standard, developers would be free to create their own Twitter server software and distribute it online – allowing anyone to run their own service. This distributed model will resolve the biggest problem Twitter has today – service blackouts due to overloaded servers.

Most of all, as a community driven effort, anyone can contribute ideas and innovations. I believe this is the only way to truly take the concept of what Twitter is and turn it into a standard means of digital communication.

One Response to “A Call For A Distributed And Open Twitter Service”

  1. Your thoughts on this are really, genuinely interesting.

    Have you followed Dave Winer and his comments on this? He posts in Twitter + Friendfeed and his web site is at http://scripting.com. He’s brought this topic up, but mostly from a higher, conceptual level (at least in most of what I’ve read) The thought of a common protocol, and maybe use of DNS is a pragmatic, real-world approach. If it’s not the perfect solution, it really sounds like valid starting point. An open, extensible protocol doing this *might* even replace or even include SMTP, I think. The security missing from SMTP could start to creep into place from this new medium.

    This is not in my particular field, but one I understand reasonably well. The one thing I see that would need to be added to the mix would be redundancy in the path. By this I mean that you and I may be on separate services, lets say I’m on Identi.ca and you are on Twitter.com. If either one goes down, the best solution would queue up messages for later posting (for the micro blog bit of the service) and still send the message to followers/friends etc. A multiple service/server back end could be a tough nut. We wouldn’t want looping messages, and we wouldn’t want to put an undo burden on alternate services. The looping message issue, though, would be solved easily if the protocol mimicked SMTP and NOT DB replication between separate entities.

    Thank for the interesting post!
    Robert (http://twitter.com/meta_robert)

Leave a Reply