I’ve been thinking a lot lately about the fate of one of the better-known blogging technologies: TrackBack.

First introduced by Six Apart in 2002, TrackBack has had the life of a hothouse flower: in just three short years it sprouted, bloomed, and (for all intents and purposes) died.

“Died?” you ask. Yep, as far as I’m concerned TrackBack is dead — killed by spammers who have made it more trouble than it’s worth to keep it around. So much TrackBack traffic comes from spammers these days that it can overwhelm your server; I actually got a nastygram from my ISP a couple of months ago about how much CPU usage TrackBack was responsible for on my box, which was part of the reason why most of my blogs no longer support TrackBack. It just wasn’t worth the trouble of keeping it around.

But can we learn something from the fate of TrackBack to make future social software innovations more successful? I think so. To understand how, let’s examine the life of TrackBack in a little play I call TrackBack: A Tragedy in Three Acts.

So what lessons can we take from Ben and Mena’s unfortunate experience, to improve future social software offerings?

1. You should assume that systems on the public network will be abused. This is a lesson as old as the Internet, but every programmer seems to have to learn it for him/herself: if you make a system available to the public, people will abuse it. It’s a simple function of the size of the audience: given a large enough group of people (like, say, the population of the Internet), and a sufficient degree of anonymity, people will start pushing the envelope to see what they can get away with. This is the Greater Internet Fuckwad Theory in action, kids, and it ain’t pretty. Don’t believe me? Ask the US Postal Service what happened when they partnered with Stamps.com last year to let people create their own postage using any images they liked. I’ll say it again: put a system on the public network and people will try to abuse it.
2. Systems that don’t think about security up front end up paying for it down the road. Because of the fundamentally insecure architecture of TrackBack and the basic truth of the Greater Internet Fuckwad Theory, a host of workarounds have sprung up to deal with the resulting mess. The most popular is MT-Blacklist, a plugin for 6A’s Movable Type software which lets you create a blacklist of URLs and automatically block pings containing them. However, this solution falls prey to the standard problem with blacklists: it’s completely reactive (you’re always a step behind the spammers) and doesn’t scale well (eventually your blacklist swells to a huge size and becomes unwieldy to parse and manage). Does it work? Yeah, kind of — but it’s a huge amount of effort to make up for not putting in a little effort up front to ask “Could people abuse this? How? How can we close those use cases?” (Note: I’m not saying you should spend four years planning out your code before you write it — we don’t need any more architecture astronauts. A little thinking about abuse and security up front can help you close of the vast majority of potential exploits at little cost, though.)
3. When your technology is open to abuse, silence is deadly. You might think that 6A, as the authors of the spec, would have made notice of the deep problems with TrackBack and been on top of finding solutions. Such is not the case: the official TrackBack blog hasn’t been updated in nearly a year, and their Professional Network lumps TrackBack spam in with comment spam and advises use of tools like MT-Blacklist for both. The result is a perception that no fix is coming, which leads people to abandon ship rather than wait for a fix they think will never come.

Three lessons: assume the worst, plan for security, and communicate with the community that uses your tool. Hopefully the ultimate fruit of TrackBack is that it encourages more developers to learn these lessons, before they find themselves chasing exploits like Ben and Mena.