“The future is already here — it’s just not evenly distributed.”
— William Gibson
I was reminded of that quote this week when I received a support request for a Perl CGI script I helped write about twenty-five years ago.
If you’re a software developer, your immediate reaction is probably the same as mine was.
“A Perl CGI script? In 2026?”
But the more I thought about it, the more I realised that my surprise said more about me than it did about the person who sent the email.
We assume everyone lives where we do
If you spend your days reading Hacker News, watching conference talks and experimenting with AI coding tools, it’s easy to believe that everyone is building applications in containers, deploying them to cloud platforms and arguing about which JavaScript framework will replace the current JavaScript framework.
That’s our world. It isn’t everyone else’s.
One of the hardest lessons for any software engineer is accepting that we are not our users.
We spend our time talking to other software engineers, reading software engineering blogs and attending software engineering conferences. It’s easy to conclude that the whole world is moving at the same pace.
It isn’t.
Most businesses don’t think in terms of technology at all. They think in terms of problems. The website is there to answer customers’ questions when the office is closed. If it does that reliably, they’re happy.
Most businesses don’t employ software engineers. They employ accountants, manufacturers, retailers, charities, estate agents and consultants. Their website isn’t their product. It’s simply another business expense, somewhere between the telephone system and the office printer.
They’re not interested in Kubernetes. They don’t care whether their site is hosted on Cloud Run or a Raspberry Pi in someone’s garage. They certainly aren’t waking up each morning wondering whether they should migrate to the latest web framework.
They just want the website to keep doing what it’s done for years.
A support request from another era
The email came from the CEO of a small European company.
Their contact form had suddenly stopped working and, after a little digging, they’d discovered that the software processing it was NMS FormMail, part of the NMS project that I helped run around the turn of the millennium. They wanted to know whether I could help.
The diagnosis took about two minutes.
When the form was submitted, the browser displayed the Perl source code instead of executing it. That meant the program wasn’t failing. It wasn’t even running. The web server was simply serving the CGI script as a text file.
I suggested that the hosting company had almost certainly migrated them to a new server where Perl CGI was no longer enabled.
A few hours later they replied.
That was exactly what had happened.
The software wasn’t the problem
There’s an important lesson here.
Nothing in the software had broken.
The contact form had apparently been working happily for years. The Perl compiler hadn’t suddenly forgotten how to execute CGI programs. NMS hadn’t developed a bug after twenty-five years.
The thing that had changed was the hosting environment.
Twenty years ago, almost every budget Linux web host proudly advertised support for Perl CGI. Today, very few do. There simply isn’t enough demand to justify it. The overwhelming majority of customers want WordPress, PHP or a managed website builder, and hosting companies naturally invest in the technologies that almost all of their customers actually use.
Supporting Perl CGI today means maintaining packages that very few customers need, testing an increasingly niche platform and employing engineers with knowledge that has become correspondingly rare. That’s difficult to justify when you’re selling hosting for a few pounds a month.
The platform quietly disappeared.
Legacy software isn’t necessarily bad software
Software developers often talk about “legacy software” as though it’s automatically a problem.
Sometimes it is. But very often, legacy software is simply software that solved a problem so well nobody felt the need to replace it.
Think about the economics.
Suppose you’d phoned this company every year for the last twenty years and offered to modernise their website for £2,000.
Why would they have said yes? The website worked. The contact form worked. Customers could get in touch. There were no new features they needed.
From the business’s perspective, spending thousands of pounds to replace something that wasn’t causing a problem would have been irrational.
From my perspective, the website looked like a museum exhibit. From theirs, it looked like a website.
That’s the difference between software engineers and users. We see technology. They see outcomes.
That’s why we’re often so bad at predicting what people will actually adopt. We assume they’ll make technical decisions for technical reasons. In reality, most businesses make technology decisions for economic reasons.
Good engineering has a context
One part of the story particularly amused me.
The customer mentioned that they’d actually migrated to NMS in 2023.
Think about that for a moment.
NMS was created around 2000 as a modern replacement for Matt’s Script Archive. More than twenty years later, somebody was still upgrading to it.
That tells us something about the extraordinary lifespan of web software.
It also reminded me that engineering decisions only make sense in the context of their time.
One of the improvements NMS made over Matt’s original scripts was to use CGI.pm wherever possible. Back then, that was exactly what experienced Perl programmers recommended. CGI.pm was part of the standard Perl distribution, thoroughly tested and far preferable to everyone writing their own CGI parameter parser.
Today, CGI.pm isn’t installed by default with Perl. It still exists, but as a separate package. Ironically, if you somehow found a web host that still supported Perl CGI, there’s a reasonable chance that Matt’s original scripts would run immediately while NMS would first complain that CGI.pm wasn’t installed.
That doesn’t mean we made the wrong decision. It means the world changed.
The future really is here
William Gibson’s quote is often used when talking about AI, robotics or autonomous vehicles.
I think it’s even more applicable to enterprise software.
The future is here.
It’s just that it exists alongside Visual Basic applications, Microsoft Access databases, COBOL systems, Classic ASP websites and, until last week, a Perl CGI script quietly sitting in a cgi-bin directory somewhere in Europe.
Those systems aren’t still around because people love them.
They’re still around because they continue to solve the problem they were built to solve.
Software engineers tend to imagine technology replacing technology. Businesses replace technology only when the old technology stops delivering value or the ecosystem around it moves on.
That’s exactly what happened here. The Perl program didn’t fail. The web simply stopped expecting it to exist.
Looking back
Looking back, the email was a useful reminder.
Software engineers spend our careers chasing the future. We get excited by new languages, new frameworks and new deployment models. That’s part of the job.
But most of the world isn’t chasing the future.
Most of the world simply wants yesterday’s software to carry on working tomorrow.
That’s why William Gibson’s observation resonates so strongly. The future really is here. It’s just concentrated in places like conference talks, GitHub repositories and startup incubators.
Elsewhere, quietly and without anyone really noticing, there are still Perl CGI scripts processing contact forms, COBOL programs paying pensions and Microsoft Access databases running small businesses.
They aren’t there because people are afraid of change.
They’re there because, until something around them changes, they continue to solve the problem.
As software engineers, it’s worth remembering that we are not our users. The technologies we’re excited about today won’t become mainstream simply because they’re better. They’ll become mainstream when replacing yesterday’s solution makes economic sense.
Previously
As I previewed this post, I saw that the “related articles” section had found the 2024 article “The Present Isn’t Evenly Distributed Either.” I think my opinions on this have become more nuanced. Previously, I wrote “The present isn’t evenly distributed”, and now I’m adding, “…because the economics aren’t evenly distributed either”.
