An Interview with Evan Prodromou, the Developer Behind the Open Source Twitter Clone : Page 2

The author of Laconica, an open source tool that lets anyone set up their own Twitter clone, discusses the technical challenges of microblogging and why it's not a fad.

by Howard Wen

Nov 19, 2008

Page 2 of 2

HW: How similar is Laconica's technology to Twitter's?

EP: Let me say that I only know what is public information about Twitter. I don't know anything about their internal source code or anything like that.

Superficially, I've tried to track very closely the same kind of functionality that Twitter has. So my intention is to have someone who's very familiar with Twitter's function set be able to set up their own Laconica instance and be like, "I've been using Twitter for a while. I know how to add a friend. I know how to send direct messages. I know that I can get RSS feeds, etc.."

Also, early on, we cloned the Twitter API function-for-function. Twitter has a published API that they use, and there have been a number of desktop, web, and mobile clients that use this API. Because we cloned an identical API, that means third-party developers can simply change a few constants in their code and their code will work just as well with Identi.ca as it does with Twitter. In fact, it sometimes works a little better.

HW: How different is Laconica from Twitter?

EP: Under the covers, [Laconica] looks very different:

As far as I know, and again this is mostly hearsay, Twitter is implemented as a Ruby on Rails application [on] the web side. It also uses a number of off-line queue processing demons. So if you post a message on Twitter through the web site, the message goes into a queue, and the off-line processing demons, which I think are also written in Ruby, also process it. And they say, "This message goes to this person... this message might go out over IM... this message needs to go out over the web... this one's going to get stored here... this one gets sent there."

I believe they use a queuing manager called Starling, which, again, is written in Ruby. That is about the extent of my knowledge of the Twitter architecture.

Laconica's architecture is a little bit different because we have different requirements. The principal difference in our environment is that I wanted to make sure that our software can be installed practically anywhere. You can install [Laconica] on a PHP and MySQL server, and it should work fine.

However, at the higher end, we have to support a big system like Identi.ca. At that level, we need to have a very similar architecture to the one that Twitter has, so requirements are to scale. When people talk about scaling, they usually talk about getting bigger. For Laconica, we need to cover the scale from the very small implementation to very big implementations.

HW: What are the challenges when it comes to developing or setting up a microblogging system?

EP: People expect this kind of system to have a utility-like reliability. If I'm sending out a message to all my friends, I would like to have that message go through quickly, efficiently, reliably. So it raises the level of requirements for getting real-time (or close to real-time) communication, and having everything working on lots of different protocols.

Each time that your number of messages and your number of actual communication message-sending points go up by squared as you get end users, your scale goes up very quickly. Your scale goes up very quickly end squared against end. You need to cover a lot of different channels; there's lots of different protocols that you need to be working with.

HW: As a developer, what do you find technically interesting about microblogging?

EP: One of the things that's been interesting for me is developing software for multiple protocols and multiple ways of speaking over the internet, mobile devices and routing. The success of our projects is going to depend on routing over as many channels as we possibly can.

Another thing I've found very interesting is the necessity for reliability. We need to be getting fast, quick service to people on a fairly large volume of messages. I'm learning a lot about building messaging architectures, trying to keep up with how our system is growing.

Fortunately for me, the open source community and open source development community have been forthcoming. Lots of people have been participating in our project. Rasmus Lerdorf did a code review on the software and came up with a lot of suggestions and ideas.

HW: What do you foresee will be the future of microblogging? Basically, is it just a fad, or will it evolve into something truly useful?

EP: I don't know of many communication systems that have grown to this kind of popularity without eventually becoming fairly important. These kinds of markets grow for a reason and they meet a need that people have. There's somewhere around 110 microblogging services out there, not counting about 100 Laconica instances. So I don't think those services are serving a need that's illusory. I think there's something real there.

The fact that it turns communication into a worldwide conversation very quickly is really powerful and really forceful. You see in the conversations around the U.S. elections, the way that people respond to emergencies like the earthquake in California a few weeks ago, that there's something here that people are looking for.

Where will it go in the future? I think we'll probably see even more sharing of structured data, things like images, video, [and] audio. It'll become a bit more like micro-podcasting or micro-videocasting. You might take a quick video, send it out to all your friends, and it gets to them wherever they are.

There's also a good case to be made for using microblogging in [the] enterprise. When people in different departments in a company need to know what each is doing, it's a great way to keep people up-to-date. I think corporate microblogging is going to become a big part of what people do in their company.

So I don't think it's just a fad. It's going to be ubiquitous, and, if we're careful and smart, we can make it into a protocol that everyone can use, that lots of different vendors can support and implement, and that we can build on top of, instead of having competing services.