The Long Life of WWW::Shorten Reading Time: 7 minutes Or: how a ...

2026-10-16T03:12:15Z

The Long Life of WWW::Shorten

Reading Time: 7 minutes
Or: how a dead email address sent me digging through 24 years of Perl history.
A few months ago, the Perl community received some news. The PAUSE administrators were turning off the email forwarding service that had, for many years, allowed CPAN authors to receive email at addresses like DAVECROSS@cpan.org.
This wasn’t entirely unexpected. The service was a relic of an earlier internet, when having a convenient, permanent email address associated with your CPAN identity seemed like a useful idea. But it had become increasingly difficult to maintain, and the time had come to switch it off.
Earlier this week, Olaf posted a reminder that the service was really dead now. Which galvanised me into action.
I hadn’t used my CPAN email address for years. But I knew that it was probably still lurking in the documentation of some of my older modules.
So I spent an hour or so grepping through my Git repositories to find references that needed updating.
I found four distributions that needed attention.
XML::Feed — A module for reading and writing RSS and Atom feeds. This is still useful software, and I imagine it has a reasonable number of users.
Ogg::Vorbis::Header — A module for manipulating metadata in Ogg Vorbis audio files. I’m not entirely sure how many people still use Ogg Vorbis, let alone want to manipulate its metadata using Perl. This module also contains some Inline::C code, which is well outside my comfort zone. Getting it to compile on my current Fedora installation involved fixing a C type mismatch that had apparently been lurking in the code for years.
QMail::QueueHandler — Years ago, I looked at the code for qmHandle, a utility for managing qmail mail queues, and was sufficiently horrified that I rewrote it in what passed for modern Perl at the time. I wonder how many people still run qmail.
WWW::Shorten — And this is where things got interesting.
The first three were relatively straightforward maintenance tasks. But when I looked at WWW::Shorten, I realised I was opening a door that I’d deliberately closed ten years ago.
To explain why, we need to go back to 2002.
When URLs were too long
In the early 2000s, URLs could be a real nuisance.
A simple page might have a reasonably short address, but links generated by content management systems, search engines and online shops could contain enormous query strings. Sending one of those links in an email could be awkward. Email clients sometimes wrapped long URLs across multiple lines, breaking them in the process.
And this was before Twitter existed. The original motivation for URL shortening had nothing to do with squeezing links into 140-character tweets.
The solution was simple enough. A URL-shortening service would accept a long URL, store it in a database, and return a much shorter one. When someone visited the short URL, the service would redirect them to the original destination.
One of the early services offering this functionality was MakeAShorterLink (usually abbreviated to MASL).
I first encountered it in 2002. Alex Page had written some Perl code using LWP to interact with the service, probably posting it on PerlMonks. I borrowed his approach and wrapped it up as a CPAN module called WWW::MakeAShorterLink.
It was a simple module. You gave it a URL, and it returned a shorter one.
I called the function makeashorterlink().
Almost immediately after the first release appeared on CPAN, Simon Batistoni spotted something I’d missed. If we could turn a long URL into a short one, surely we should also be able to do the reverse—take a shortened URL and retrieve the original destination.
And, of course, there was only one possible name for that function.
makealongerlink().
I added it, and the module now had two functions with names that described exactly what they did, while also being slightly ridiculous.
What I didn’t know at the time was that those names would survive for the next quarter of a century.
Because another Perl programmer, Iain Truskett, immediately saw a bigger opportunity.
I’d written a module specifically for one shortening service. But there were already several services doing much the same thing, and there would almost certainly be more.
What we really needed was a generic interface to URL-shortening services, with separate adapters for each provider.
And that, of course, was exactly the sort of problem that Perl’s module system was good at solving.
Enter WWW::Shorten
Iain created WWW::Shorten in 2002, very soon after I released WWW::MakeAShorterLink.
Instead of having a completely separate interface for every shortening service, WWW::Shorten provided a common API. You could select the service you wanted to use, and the module would handle the details.
My original MakeAShorterLink module became one of the first adapters in the new distribution.
The interface was pleasingly simple:
use WWW::Shorten 'TinyURL';
my $short = makeashorterlink($long_url);
my $long = makealongerlink($short);
And if you wanted to use a different service, you could change the adapter.
The two function names survived the transition from my original module to Iain’s generic interface. They’re still the names used throughout the WWW::Shorten ecosystem today.
It’s a much better design than my original module. Iain had recognised the abstraction almost immediately.
Over the following months, he added support for more services. Other people contributed adapters, bug fixes and improvements. By early 2003, the distribution supported a growing collection of URL shorteners, many of which I’d never heard of.
Looking back through the change history now is like reading a directory of forgotten internet startups.
Iain was a prolific and enthusiastic member of the Perl community. He was also someone whose work I admired.
Sadly, Iain died in 2003.
In 2004, I took over maintenance of WWW::Shorten. It seemed like the right thing to do. I had a connection to the project’s origins, I understood what it was trying to achieve, and I wanted to ensure that Iain’s work continued to be useful.
For the next twelve years, the distribution was one of the many CPAN projects I maintained.
The URL-shortening boom
Something interesting happened while WWW::Shorten was growing.
URL shortening became a business.
In 2002, the idea had been a useful little convenience. But as the web grew, and particularly as social media became popular, the demand for short URLs increased enormously.
TinyURL launched in 2002. Bitly followed in 2008. Google’s goo.gl service appeared in 2009.
There were dozens of others.
Some offered custom aliases. Some provided statistics showing how many people had clicked a link. Some targeted particular communities or use cases. Others seemed to exist largely because somebody had found a suitably short domain name.
For a while, it seemed that everyone wanted to run a URL-shortening service.
And WWW::Shorten accumulated adapters for many of them.
The problem with writing software that provides a common interface to third-party services is that you’re dependent on those services continuing to exist.
And many of them didn’t.
A graveyard of URL shorteners
Look at the current WWW::Shorten documentation, and you’ll find a deprecation notice listing eight services whose endpoints no longer work.
Among them are LinkToolbot, Linkz, Metamark, TinyClick, Tinylink, Qurl and Qwer.
And, rather poignantly, MakeAShorterLink — the service that started my involvement in the whole thing.
The adapter for MakeAShorterLink now does nothing useful. Its documentation explains that the service became inactive, so calling the module simply produces an error.
It’s a strange feeling to see a piece of software that you wrote almost a quarter of a century ago preserved as a compatibility layer for a service that no longer exists.
The other defunct adapters tell similar stories.
Some of these services disappeared quietly. Others were acquired, rebranded or superseded. Some simply stopped responding.
The WWW::Shorten distribution has become something of a museum of the early URL-shortening industry.
There’s even a promise in the documentation that the deprecated adapters will be removed when version 3.100 is released.
The latest release is 3.094, published in March 2021.
That promised clear-out has been waiting for over five years.
What happened to URL shortening?
Of course, URL shortening hasn’t disappeared completely.
Bitly and TinyURL are still around. Plenty of businesses use shortened links for marketing campaigns, analytics and branded URLs.
But the industry has changed.
Originally, the attraction was simply making long URLs shorter. Today, the commercial value is more likely to come from tracking clicks, managing campaigns and using branded domains.
And some of the original reasons for shortening URLs have become less important.
Modern email clients generally handle long URLs without difficulty. Messaging applications often display links as rich previews. Twitter (now X) introduced its own URL-wrapping system, reducing the need for users to shorten links themselves.
There’s also a downside to shortened URLs that wasn’t always appreciated in the early days: they hide the destination. A short link can be a useful convenience, but it can also conceal a malicious website. And every shortened URL introduces another dependency. If the shortening service disappears, the link may stop working.
Perhaps the surprising thing isn’t that so many shortening services have disappeared.
Perhaps it’s that some have survived for so long.
Handing over the keys
By 2016, I’d been maintaining WWW::Shorten for twelve years. I wasn’t using it myself, and I had plenty of other projects demanding my attention. So I was pleased when Chase Whitener offered to take over maintenance. I handed him the distribution and moved on.
That was ten years ago.
Chase continued working on it, and the most recent release appeared in March 2021. But there hasn’t been another release since then.
Which brings us back to October 2026.
I found my obsolete CPAN email address in the distribution and considered making a quick update.
But CPAN maintenance permissions have a way of turning small favours into long-term commitments.
If I make a new release, I’m potentially putting myself back in the position of being responsible for WWW::Shorten.
And I really don’t want to do that.
It’s not that I have anything against the module. I’m rather fond of it, in fact. It represents a small but interesting part of Perl’s history, and it reminds me of Iain and the earlier days of CPAN.
But I’ve already spent twelve years maintaining it. I deliberately handed it over a decade ago.
I don’t particularly want to spend the next decade fielding bug reports about obsolete URL-shortening services.
So I’ve decided not to make the release.
The obsolete email address can stay where it is.
When should open-source software retire?
There’s a broader question here.
We tend to assume that open-source projects should continue indefinitely. If someone finds a bug, someone should fix it. If a dependency changes, someone should update the code. If a new version of Perl breaks something, someone should make it work again.
But who is that someone?
Often, it’s a volunteer who wrote the original code decades ago, or inherited it from someone else, and has long since stopped using it.
And maintaining old software isn’t free. Even a trivial change involves checking out the repository, understanding the build system, running tests, updating metadata and making a release.
Sometimes, as with Ogg::Vorbis::Header, a simple documentation update turns into debugging C code that hasn’t been touched in years.
None of this is necessarily difficult. But it all takes time.
I don’t think every CPAN distribution needs to be actively maintained forever.
Sometimes software has served its purpose. Sometimes the services it supported have disappeared. Sometimes the world has moved on.
That doesn’t mean the software was a failure.
WWW::Shorten was a good idea in 2002. Iain designed a useful abstraction, and a number of people contributed to making it work. For many years, it provided a convenient interface to a rapidly changing collection of web services.
It did exactly what it was supposed to do.
And perhaps that’s enough.
Twenty-four years after I wrote WWW::MakeAShorterLink, I’m still rather pleased that it led to something bigger.
I’m just not volunteering to maintain that something bigger again.
A final twist
While researching this article, I visited makeashorterlink.com for the first time in years.
To my surprise, the domain still works. It now displays a TinyURL-branded page inviting visitors to sign up for a custom URL-shortening domain.
It turns out that TinyURL was being discussed as a possible successor to MakeAShorterLink as far back as 2011.
So perhaps the original service hasn’t entirely disappeared after all. Its old interface is gone, but its domain has found a new life with one of its former competitors.
Twenty-four years later, apparently we’re still making shorter links.
The post The Long Life of WWW::Shorten first appeared on Perl Hacks.

https://perlhacks.com/2026/10/the-long-life-of-wwwshorten/

Nostr notes by Dave Cross (Unofficial)

The Long Life of WWW::Shorten Reading Time: 7 minutes Or: how a ...