Tim Marman's Loosely Coupled

Browse by Tags

• Business
• Programming
• Rants
• Software Development
• Startup
• Technology

• Revisiting (and rethinking) the Twitter “Pay to Listen” business model

  Personally, I thought Charlie was spot on when he said that Sermo’s “Pay to Listen” business model might be the answer for Twitter and similar services. This was before the acquisition of Summize, which Allen thought was a short-sighted move . When Summize presented at the NY Tech meetup , they spoke about very large aspirations to track the real-time conversational Web, not just Twitter. If Twitter acquires the service, that goes bye-bye. As I said in comments , this makes more sense if “their monetization strategy is with analytics and reporting as Charlie has suggested in the past. In that case, Summize's technology is more than just a fix for the search and replies - it's the engine by which Twitter can make their money.” Recent chaos allegedly caused by the the new Twitter anti-spam bot gives me even more reason to suspect that this is the model. First, let me start off by saying that I don’t really see spam as a problem with Twitter. In fact, that’s the whole point of the... Posted Jul 27 2008, 12:46 PM by Tim with | with no comments Filed under: Business, Startup, Twitter

• The Challenges of Scaling Twitter's Follower Model

  I wrote previously that Twitter's architecture is not scalable for real-time messaging . Indeed, the Twitter development team talked about this recently . Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency's sake, Twitter was built with technologies and practices that are more appropriate to a content management system. Over the last year and a half we've tried to make our system behave like a messaging system as much as possible, but that's introduced a great deal of complexity and unpredictability. Dare Obasanjo recently looked at the issues and implications and suggested that it's not the technical architecture to blame, but perhaps rather the logical model. If Twitter was simply a micro-content publishing tool with push notifications for SMS and IM then the team wouldn't be faulted for designing it as a Content Management System (CMS). In that case you'd just need three data structures... Posted May 26 2008, 12:57 PM by Tim with | with 1 comment(s) Filed under: Software Development, Rants, Programming, Twitter

• Twitter's problems are the result of architecture, XMPP may be the answer

  The problem with scaling Twitter is not the choice of framework, but the choice of architecture. In other words, abandoning Ruby On Rails probably isn't going to solve all of their problems. At the same time, I'm not sure that decentralization is necessary and comes with its own set of challenges. The real problem is that the polling model of the Twitter API doesn't scale for real-time communications. As it is today, many Twitter clients will poll (by default) every 3-5 minutes to see if there was an update. Not only are they not really participating in real-time, they are generating an enormous number of requests that - even while each payload is small - generate a lot of overhead in aggregate just in checking and responding. As I've suggested in the past , a better solution would be to move the "real-time" API around the Jabber/XMPP client instead of HTTP. The good news is that Twitter already has an IM presence so it's easy enough for third-party clients... Posted May 05 2008, 08:24 PM by Tim with | with 2 comment(s) Filed under: Technology, Software Development, Programming, Twitter