The present isn’t evenly distributed either

The future is already here – it’s just not very evenly distributed
– William Gibson

The quotation above was used by Tim O’Reilly a lot around the time that Web 2.0 got going. Over recent months, I’ve had a few experiences that have made it clear to me that even the present isn’t particularly evenly distributed either. It’s always easy to find people still using technologies that we would consider archaic (and not in a rustic or hipster way).

We’ve known for twenty years that CGI is a bad idea. It’s almost ten years since CGI.pm was removed from Perl core. Surely, all of us are using something modern for web development these days.

Well, apparently not. CGI is alive and well and living on the fringes of the Perl community. I’ve come across it being used in some quite surprising places over the last year or so. I’m going to obfuscate some details in the following descriptions to, hopefully, prevent you (or, worse, the people involved) from recognising the companies involved.

• I did some work for a spectacularly big (and I mean huge) consultancy company. They wanted to decommission some old servers – which involved moving some Perl CGI programs that no-one had looked at for about fifteen years. These programs were, of course, running vital bits of the business. Anyone who had ever edited them had left the company at least ten years earlier. They wanted to do it as quickly as possible and change as little of the code as possible. The code was incompatible with even vaguely modern versions of Perl, so much of the work involved installing old versions of Perl (along with Apache and even mod_perl) on new hardware running up-to-date operating systems.
• I picked up two or three freelancing gigs on Fiverr. And for the first time in years, I found myself working with low-end, rented, shared servers. At least one of them was one of those situations where you don’t have root access and are extremely hampered by the lack of software.
• A couple of weeks ago, I got an email to my SourceForge email address asking for help with nms Formmail (some readers may be young enough that they haven’t heard of Matt’s Script Archive or the London Perl Mongers rewrite of those programs into what we called “modern Perl” twenty years ago). The email asked if our Formmail supported anti-spam measures like SPF, DMARC and DKIM. It was nostalgic to recall how different the web was back in the days when every web site had a mail form, a guest book and a hit counter. I see that SourceForge have removed the nms web site. I doubt I’ll ever get the time to work out what happened to it.  [Update: I was wrong about that. It’s been so long since I’ve looked at the nms project that I had forgotten the URL. The web site is still there in all its early-2000s car-crash web design glory.]
• The following day I saw a question on Stack Overflow about a “classic mailing script”. And, yes, it was nms Formmail again. This user had moved their web site to a new server and it had stopped working. We never got the error log content that we asked them for, but the user confirmed my suspicion that the new web server had a newer version of Perl – one that was released after CGI.pm was removed. The nms project had (for obvious reasons) made heavy use of the module and its removal from core Perl has rendered the nms programs unusable on cheap servers where the sysadmin has no knowledge of or interest in installing any Perl modules that aren’t part of the standard package. Sadly, this means that Matt Wright’s original versions (that were never updated to use CGI.pm) still work in environments where the nms versions are useless.

None of this should be taken as an argument that the nms project was wrong to use CGI.pm or that the Perl 5 Porters were wrong to remove it from the Perl standard library. I still support both decisions. I just found it a bit jarring to be reminded that while we’re all using PSGI or Mojolicious to write microservices in Perl that serve REST APIs that are developed and deployed in Docker containers, there are still people out there who are struggling to FTP code that was written in 1997 onto low-end shared hosting.

I think this state of affairs has two causes. Firstly (like the first client I mentioned above) some systems were set up when CGI was still in common use – and things haven’t changed since. These people get a sudden shock when they are forced to move to a more modern server for some reason. And then there are people like my Fiverr clients who install Perl CGI programs because that’s what they have always done and they don’t know that there is an alternative approach. Part of the problem there is, presumably, that Perl has meant badly-written CGI programs for a large proportion of the web’s existence and means anyone searching for information on this subject is likely to find pages and pages of advice telling them how to install CGI programs before they discover anything about PSGI or Docker. And I think there might be a solution to that problem (or, at least, a way to nudge the web in the right direction).

Over last weekend I was cataloguing subdomains (I know how to have fun!) and I found a web site that I had forgotten about. I had obviously been contemplating a very similar situation back in 2016.

The site is called Perl Web Advice. The intention was (is?) that it would be a definitive source of good advice about how to develop and deploy web applications written in Perl. I had only made tiny inroads into the task before something else apparently seemed more fun and the project was abandoned.

But there’s the start of a framework for the site. And, this week, I’ve given it a GitHub Actions workflow so it gets republished automatically whenever changes are pushed to the repo. I’ve even set up a Dockerfile to make it easy to use the static site generator that I’ve used for it. So perhaps the idea has merit. Once there’s a bit more useful content there I could see if I can remember any of my SEO knowledge and get it appearing in results where people are looking for advice on this topic.

I would, of course, be happy to consider contributions from other people. What do you think? Would you like to help me save people from the hell of CGI deployments?