Tr.im to be Community-Owned | Hacker News Reader

Tr.im to be Community-Owned

blog.tr.im

63 pointspeter12334 comments

Disclosure: I built, own and operate Cligs, one of the URL shorteners that was part of the 301works founding announcement last Friday.

First off, I don't know what happened between bit.ly/Betworks and tri.m. But I do take offence that 301works is a bit.ly publicity stunt.

See, I care most about the Cligs users. To me, 301works is a backup in case something bad happens to Cligs. The backup is operated by an independent (read not bit.ly) service, namely Gnip. I and others insisted on having an independent entity run it for obvious reasons.

Each URL shortener specifies the terms of transfering the data to Gnip. It can be anything from what I call "the dead man's will" option of simply locking away the data to be released on the termination of service, all the way to having a completely open data policy that the URL shortener basically says to the world "do as you please".

So, at the absolute worst, it's an offsite backup service. In reality, it's much more useful than a mere backup service. For example, if we get the details right, the Gnip API could power a URL-expanding service that takes some load off the URL shorteners' servers; this is just a basic example.

I've been talking about such a service with other owners of URL shorteners for a few months, and so there is nothing new about it. We just worked hard now given the anxiety we were seeing from our users. A lot of people worked hard to make it work in a good way, sometimes working at odd hours, to make sure that no one gets the short end of the stick.

So please, don't call 301works a bit.ly publicity stunt. It's not.

If anyone wants to talk about this more, email me: my first name (first 6 letters of my HN username) at cli.gs.

While 301works might not be just a bit.ly stunt, it certainly was disproportionately important to bitly not to have a glaring example of the negative effects of URL shorteners staring people in the face -- they encourage link rot and offer the potential for lots of it. The potential for shorteners to disappear and break lots of links is certainly a massive flaw in their business model.

This whole link rot is massively over stated. Most short urls are used on Twitter. Who is reading old Tweets on Twitter? Almost nobody since Twitter is about now, not yesterday.

By the time you switch over to some 301works archive the links will have lost 99% of their relevancy.

I used to agree with you, but I think that both people and companies have an interest in preserving the conversation. Not every, or even most, conversations, but certainly some.

In which case you should be using your own shortener if you want to preserve your own links. Or if you're a company scanning other links then you should be resolving the short urls as you receive the entries.

There's something I don't quite get about the 301works idea - don't they need the domain in order to do anything?

Let's say I run a shortener, and it's quite popular. For whatever reason, it goes bankrupt. I can give all the redirect info to 301works, but unless I also give them the domain then what's accomplished? A hijacker could still buy the domain and send all the shortened links out there to his AdWords page. 301works would know that /hjk87 goes to cnn.com, but when they hit a link to shortener.com/hjk87 it's still hijacked by the guy who controls the domain, no?

Or is the premise that if I have to terminate my service, I give both the data and the domain to 301works - in which case how is it different from just saying "give us what small assets you have left, now that you've shit down your service"?

Is just me or do they guys come off as being entirely childish over the "twitter/bit.ly walled garden"?

Everything I've seen them post about tr.im lately has a half-dozen whining comments about twitter/bit.ly.

If their product has no value outside of Twitter, then what exactly did you expect? If tr.im is a valud URL shortener with some value to it, then it should be able to stand on its own outside of any other 3rd party service. TinyURL has been around for more than a decade, long before Twitter was even a programmers wet dream.

i believe their point is that twitter has an open API and encourages app development on top of its platform everywhere it can, but it simultaneously will pick a golden app that creates a huge barrier of entry to the next "good idea" in that area.

kind of a silly thing to do, and something i'd complain about a bit if it caused a company of mine to go under.

But if Twitter decided to implement their own redirection service, there would be no problem, right ? As in, would you still consider that as an innovation barrier ?

I know a lot of the innovation for url redirection services should be looked for in the data mining area, and you need lots of data for data mining. But these tr.im posts all give me the impression they feel like they're entitled to a share of the traffic Twitter generates. They're not, and never will be. Twitter is entitled to decide what they do with their traffic. They could've implemented their own redirection service, they didn't, and decided to go for a single url redirection service. Perhaps precisely to keep the innovation going in that area (url redirection is Bitly's core business, thus they will take the data more seriously), while on the other hand keep the service reliable and predictable.

If your entire business depends upon the grace of a single company, and you don't do anything to break your business out of that, you've just got a bad business model which is destined to give you a lot of headaches, and even will make you fail. And yes, I'm looking at you too, AppStore developers. Quit whining already!

Not sure why people are saying the whole business was based on tr.im. Was pretty clear in the articles I read that tr.im was a side project for Nambu.

Seems that Nambu acknowledged pretty clearly that URL shortening isn't a business.

are you making the argument that no one should be building twitter apps, facebook apps, iphone apps, blackberry apps, windows apps, etc.?

after all, they're basing their existence upon the grace of a single company

His argument doesn't appear to be "don't build", it appears to be "tread cautiously". If your business model depends on filling an obvious hole in someone else's product, you need to be wary of the idea that the first-party will fill that hole. Joel Spolsky outlines this well in the Stack Overflow podcast, though he's usually talking about plug-in ecosystems.

And yes, people making iPhone apps or Facebook apps need to be careful of this. If Facebook decided to build in a friend-ranking feature, the company that makes that Compare People app is hosed. If Apple decides it wants to add ebooks to the iTunes Store, then a lot of iPhone apps are in trouble.

Heck, any recent news about App Store shenanigans should make people nervous about their app existing only with Apple's permission. If Apple doesn't like your app (for any reason), it won't get approved. And if Apple decides to pull your app, you're paying for the refunds (and Apple's keeping it's cut of the sales).

i suppose my point is that building an application based on a website's provided APIs and services shouldn't be considered "filling and obvious hole". if you don't want your developers to do something, tell them not to or disallow them from doing it.

it is of course a company's prerogative to implement new functionality and features, but if you're essentially killing off a large swath of applications that you asked/allowed to be developed, its a bit of a dick move and worthy of at least a little whining. imo.

Using someone's APIs may not be considered "filling an obvious hole", but it's not unreasonable to assume that a website that focuses on extremely short messages is going to be looking into ways to make that limitation less burdensome, and lengthy hyperlinks are an obvious target.

Indeed, anyone using Twitter for more than like 4 tweets is going to realize, "Gee, it's a pain in the ass that the URL in my tweet takes up half the room, I wish I could shorten it". In that light, a URL shortener is an obvious feature for Twitter to implement, since it's so simple (like what, 2 SQL tables and 30 lines of code?). Similarly, something like cut-and-paste was a likely future iPhone feature, so someone spending months designing an app where cut-and-paste was a major feature was all but begging to get steamrollered by Apple.

By contrast, someone who does something like a Twitter match-making service (matching Twitter accounts based on the hashtags or links they tweet) isn't fulfilling an obvious future Twitter feature, and thus is probably safe from being squished by Twitter.

so is it also the job of the third party developer to be able to read the mind of the application developer?

i'm not saying that a url shortener isn't trivial/obvious, but where exactly is the line that defines trivial and elegant? obvious and innovative?

That line is right between "Twitter copies" and "Twitter buys".

Yes, it is the third party developer's job. It's his job to look at the marketplace for the product he's creating before he spends too much time developing it, and analyze what the current and potential future competition look like. If it's likely you're going to be competing against someone with an insurmountable advantage (the first party), you need to think long and hard about investing resources into that product.

I don't think elegant and innovative is the line here. An idea can be elegant and innovative and something the first party never thought of, but unless it's patentable, you risk first party competition.

Again, I'm not saying first party competition is necessarily death, but it's definitely a challenge.

there's a big difference between having competition for a niche and having the provider of the service remove your niche completely.

what do you do with the other table?

I kinda figured that you'd sort of shove date/time, link URL, browser info, and referrer in there to collect the data. So it's probably more like 50 lines of code. Whatever.

sorry, I forgot the smiley face after my comment.

Perhaps Twitter should have created their own shortening service, or bought one out (they didn't actually acquire bitly did they?), if only to lessen the intensity of the complaints. It does make sense for them to want a single service, it simplifies things for them and their users. The problem with url shorteners is making your product stand out. Any stable scalable shortener is basically the same as any other. Tr.im's situation is unfortunate, but both logical and predictable.

Childish is almost insulting to children. They're still insisting that twitter somehow deprived them of a business. Oh and that bit.ly's offer of actual cash is a 'publicity stunt'.

$10k for the tr.im domain alone is an offer that would be obviously turned down. Total publicity stunt by bit.ly.

In other words, they couldn't get the money they wanted, so they petulantly shut down the service. When they got push-back from doing that, they came up with this scheme.

If they actually can get this model up and running with everyone in the world being able to see their data, I'll be curious how that goes, especially as I'm not familiar with what sort of data they keep. Do they track the IPs of people who use tr.im links?

I don't see how that's a publicity stunt. It's an offer that seems to take into account "We want out of this business, we're losing money, and we don't think this is at all monetizable". If I straight-up say "I'm desperate and need cash and think this is a piece of junk, and it's costing me money just to hold onto it", then I can expect low-ball offers.

Economically speaking, if it's a choice between shutting down and being bought out, anything more than a dollar is a good deal. Yeah, it's a dick move and it's taking advantage of someone, but it's not a publicity stunt.

To understand the situation a bit better you should listen to this Podcast that covered the story behind it which is quite a bit different than what is being spun in TechCrunch.

http://techzinglive.com/?p=101

How is it a publicity stunt, especially since bit.ly did not make this offer in public? tr.im got into a business that they were unable to monetize, made a tremendous fuss about it. How exactly is this bit of shamelessness somebody else's publicity stunt?

Finally someone said it, tr.im comes off as a bunch of whiners. Also, it takes balls accusing someone of a publicity stunt when the only reason anyone cares about tr.im right now is because they pulled the best publicitiy stunt of 2009 ("Were shutting down....Nope, just kidding!")

And even that was ripped off from tshirthell: http://www.tshirthell.com/hello.php

This seems interesting:

tr.im will offer all link-map data associated with tr.im URLs to anyone that wants it in real-time. This will involve a variety of time-based snapshots of aggregated destination URLs, the number of tr.im URLs created for any given destination URL, and aggregate click data. ... tr.im will begin publishing all statistics and information related to it usage. Its operating cash flow, redirects, URL creation counts — everything — so that the community can have confidence it is on solid footing.

I wonder what business models might be affected if this becomes popular...

Seems that bit.ly has a fair bit to lose given that similar data to what they're claiming is so valuable is now going to be open to anyone.

Wouldn't want to be a bit.ly investor today. Well, I wouldn't want to be a short url investor any day :)

What does "community-owned" mean, exactly?

hah, what makes you think this guarantees anything?

a noble ambition but one with no vision.

Reply on news.ycombinator.com