How not to Manage the Risk of Perl as a Shipped Dependency

I'm a programmer. I understand Perl. I'm comfortable configuring, building, installing, patching, reporting bugs in, distributing, and depending on Perl. If there's a problem, I can report it. Sometimes I can fix it. I want to be able to depend on the fix for my problem and I want it soon and I want it available for everyone who depends on the code I wrote. There's my perspective.

Suppose instead that I were a mere distributor of Perl -- and not because my product depended on Perl in any way, but that I hope that users might be able to make products which depend on that Perl. My business isn't supporting Perl. I might occasionally report bugs and feature requests upstream. I might feed upstream patches once in a while, if I have a unique platform, but Perl and Perl support is less important to my business than many, many other things.

I'm not making this up; Nokia's Maemo deliberately ships Perl 5.8.4 and has no plans to upgrade.

I can understand their position, in some ways. They have every legal right to do this. Perl's Artistic License asserts no conditions on use (and few conditions on redistribution) for good reason.

Even so, I find the argument that it's risky to switch to a new version on its own unconvincing. The word risk alone is insufficient justification for an action or inaction. The important questions are "What are the risks?", "How likely are they?", "What consequences do they suggest?", and "How can we identify and ameliorate the risk conditions?"

Certifying and validating and demonstrating that an upgrade to a dependency works as expected and doesn't introduce new, serious problems for users. Sure, the existing version has hundreds of bugs that p5p have fixed in the past five years, but new versions of Perl may have other bugs.

The difference between does and may in that line of reasoning irritates me.

I don't have specific numbers for Nokia and Maemo. I'm not privy to private communication between company, project, and specific Perl 5 developers. I don't want to single anyone out for good or bad behavior here. I chastise in general terms. I could be wrong about specifics; as such, I welcome specific corrections.

Users will find bugs. Users will find problems. Users will report some. Users won't report others. These are truisms.

A distributed version of Perl, especially a version of Perl distributed to users via a conduit such as Maemo, reaches more and different people than a source release of Perl 5.11 intended for developers. The more people who use Perl in different ways on different platforms, the more likely they are to find different bugs.

We know that Perl 5.8.9 has many bug fixes over Perl 5.8.4. Anyone who cares to delve into the RT queue and commit log for Perl 5 can give a count of exactly how many. (Start by reading the Perl 5.8.x delta documentation for hints about the most interesting bug fixes.)

We don't know if and how many new or re-opened bugs Perl 5.8.9 has over Perl 5.8.4. We believe that number is zero. We hope that number is small. Without feedback, we don't know.

I can understand that upgrading dependencies in a distribution -- dependencies not necessarily intrinsic to the core product -- requires testing. It requires deliberate thought about risk and benefit. It also ought to require attention to upstream's release cycle and support policy and backwards compatibility.

Picking an arbitrary release on a branch created explicitly for bug fixes, maintaining backwards compatibility with all prior branch releases, and containing an extensive test suite devoted to identify and diagnose any failures -- especially when there have been five subsequent releases on that branch (and two other stable releases since then) and that branch itself has explicitly disclaimed future support for almost a year -- well, that's one way to avoid risk. (It's also a good way to avoid performance improvements, memory use improvements, Unicode bug fixes, huge regular expression performance improvements, and more in 5.10.x. You might also wonder how many CPAN distributions want to support anything older than Perl 5.8.8. Note that if Perl 5 had had yearly major releases starting in 2004, we'd be discussing the difference between Perl 5.8.4 and Perl 5.18.x.)

Pegging a five year old Perl 5 release is well within the letter of the license as well, but I think it stretches the boundaries of the spirit of working with a free software community.