Bit.ly launches today 

First, go read Marshall Kirkpatrick's awesome writeup of bit.ly.

I was part of the team that defined the product, the development was done at Betaworks in NY (where I am right now), the team led by John Borthwick, and a bunch of ex-AOLers. Betaworks is also an investor in Summize.

Here's the official blog post.

The idea of bit.ly is that a lot more could be done with url-shorteners. I found I needed to develop my own for the NewsJunk project. They asked what it would take for me to use bit.ly, I said: data. I need to know how many clicks each pointer got and where the clicks came from.

They gave me that, and thumbnails, permanent caching of the pages I'm pointing to (goodbye linkrot) and a lot of smart stuff going on behind the scenes that we're not ready to talk about yet. (Though we told Marshall and he explained.) Here's the info page for this post.

And, most important, an XML/JSON interface, so I can process all that data with my own programs. Here's the XML readout for the shortened link to this post.

I'm a minority shareholder in this project, so know that I have a considerable interest in its success. Of course I think it's a great service, and I hope you give it a try.

Over on ReadWriteWeb, Allen Stern asks if there's a way to make money, and there is. We'll hopefully be ready to talk about it in a couple of weeks.

Which way will Twitter go? 

Biz Stone posted yesterday about the status of services connected to Twitter via their XMPP gateway. We knew about Summize, suspected that FriendFeed had a deal, and learned that there are two others.

We'd like to see Twitter connect their full output to anyone who wants it, but without directly saying so, Stone implies that there are technical reasons they can't.

I am not an expert on XMPP so I have to defer to others who are. They say it would be possible for Summize to allow anyone to subscribe to the flow they receive from Twitter, and this would be transparent to Twitter.

Gnip, a company whose founders I interviewed last week, asked for this arrangement, and even thought Summize was willing to provide them with the flow, Twitter said no.

This is a clear indication that it is an economic issue, not a technical one.

I wrote yesterday that identi.ca changes things, offering a public utility model to compete with Twitter's company-owned model. It is built around the assumption that anyone can hook into the stream of any server, allowing a "federation" where being a citizen of one community means that you're a citizen of every community.

It seems then, long-term, there are three options for Twitter.

1. Open up their XMPP interface to all interested service providers, with the help of the community, so that it has no impact on the scaling of their servers. I'm almost 100 percent sure the developers would rally around such an idea, and help Twitter get this going.

2. Wait, and support the same federation protocol as identi.ca, allowing Twitter users to participate in that community, on equal terms.

3. Build AOL-like barriers around their service, to force users to connect to Twitter users only through their software.

Obviously, from the way I've written it, you can tell that I think #3 is not really an option, not if they want to learn from the experience of instant messaging.

It seems to me that blogging, which came after IM, set the precedent for Twitter-like services, and while the compatibility between blogging services isn't perfect, it's pretty good. Because of RSS (and RDF and Atom), and the two blogging APIs (Blogger and Metaweblog) you have fairly good interop. I wish it had come out better, but it's still early for Twitter-like services, compatibility could still, theoretically, be perfect.

I hope that Ev, Jack and Biz remember this, and build a business we can all respect, not built on locking users in.