What is "Support" Anyway?

I keep no secret of the fact that I'd like to see an annual major release of Perl. Several people disagree about my identification of limits in a proposed Perl 5 support policy. Some people believe that without an eight-to-ten year support policy, Perl is doomed to irrelevance.

I think that's nuts.

I also think plenty of the disagreement is because none of us knows what "support" really means.

I Made It; You Can Use It

The word "support" may have several implications. This list is not exhaustive, but it is exhausting. Perl 5 "support" may mean:

• Configuration and installation assistance. This may include downloading instructions, an address to report odd bugs during configuration, troubleshooting assistance for compilation (and cross-compilation) problems, or even a local or remote consultant installing the Perl core on a machine.
• Access to a bug tracker, to report problems and search for workarounds and similar discussions.
• Feature requests, where users can ask for modifications and set a priority on their delivery.
• Consulting services, whether maintaining existing programs or creating new programs.
• Training services.
• Patches and bugfixes, often delivered on a set schedule (whether measured from the date of reporting a security flaw or major bug or on a regular basis).
• Upgrading assistance, especially when migrating between major versions which are not entirely backwards- or forward-compatible.
• Binary compatibility, often as a consequence of upgrades, patches, and bugfixes.
• Indemnification, if the project infringes on copyrights, patents, trademarks, or trade secrets of other parties.
• Stability, in that things might not ever improve, but they won't change.

I may have missed some categories; please feel free to add to this list in the comments.

If it Breaks, You Get Both Pieces

How many of these categories of support does p5p provide right now?

Patches and bugfixes seem obvious, but there are limits. As everyone knows, there is no set schedule for Perl releases. If you reported a bug in Perl 5.10-on 19 December 2007 and someone fixed it that day, your only option is to maintain a patched version of Perl for the past 17 months. (It's nice that you have that option, but 17 months is a while.)

There are several venues to get configuration, installation, and usage support. The voluminous core test suite is a reasonably cheap and easy way to provide this level of support. It's not free, but it's improved p5p's ability to ensure that Perl behaves appropriately on as many platforms as possible.

Training and consulting services are outside of p5p's mission. Some developers work for companies as internal consultants. Others are independent trainers. No single entity supports Perl to this degree.

Perl 5 has a public bugtracker, and the p5p mailing list serves as a place to request (and recommend (and occasionally submit patches for)) new features. Again, the lack of a formal business entity to act as a clearinghouse for these types of support may not please some businesses, but this type of support does exist.

Indemnification is difficult, at best. The Perl Foundation may provide some degree of assistance -- it manages the copyright on Perl 5, for example -- but like most other community-developed FLOSS projects, there's little money to take on legal cases for users.

Binary compatibility exists as a convention. There's no written support policy, just a rough agreement that minor releases (the 5.8.x series, for example) maintain binary compatibility. An XS extension compiled for Perl 5.8.1 ought to behave the same way with Perl 5.8.9.

Stability is an illusion, thanks to the DarkPAN problem. John Napiorkowski's Darkpan => CPAN Service? suggests an intriguing business idea which could alleviate this problem by aggregating DarkPAN code. (There's modest income in making CPAN -- and the CPAN Testers Service -- available to businesses.)

Setting aside the DarkPAN, there's no official specification for Perl 5. There's a test suite and the core documentation and tens of thousands of modules on the CPAN -- but even fixing a bug has the potential to break existing code. No specification covers every edge case. No test suite exercises all potential paths and uses. No platform nor problem is perfectly predictable.

Thus p5p provides very few of these categories of support now. Why then is there such resistence to proposed changes?

When Support Means Never Having to Maintain Your Software

I suspect that the "p5p should support all Perl releases for at least five years or no one will ever use Perl again in business!" brigade really means that Perl is plumbing. It's a series of pipes in your walls that you don't think about until someone says "You're not drinking lead, are you?" or it freezes outside and you forgot to close one faucet and open another. You only notice when something goes wrong; you don't notice when something goes right.

After all, it doesn't matter if your uninsulated PVC water pipe runs through your uninsulated attic if it almost never drops below 33 degrees.

It doesn't matter that a handful of changes can double the speed of the regular expression engine, close a few dozen bugs, reduce its memory usage, and make some patterns that would never complete work -- at least if it's more important that some DarkPAN code may have poked into the guts of the regex engine inappropriately and no one knows how to maintain that code anymore, and it absolutely has to just work with every major version of Perl released in the next several years.

It doesn't matter that rearranging a few struct members in internal data structures reduces Perl's memory footprint dramatically and offers a modest speedup for mod_perl and SpamAssassin, because there's never been any encapsulation at the XS layer, and it would be a real shame if someone accidentally upgraded a box that contains code that relies on the old behavior and there aren't any tests or maintainers for that critical business function.

It doesn't matter that Moose makes so much boilerplate OO code go away, because someone, somewhere might have defined a custom class function with the (&) prototype and uses it as a bare word somewhere.

It doesn't matter that Perl is a pretty decent cross-platform system administration language by now, because the most common way to install Perl modules is still the first idea anyone had in 1994 -- using regular expressions and string concatenation to attempt to write cross-platform shell files (invoking Perl itself when those platforms don't support Unixisms such as touch and rm -rf) which require the presence of a Make utility (often not shipped with non-Unix platforms).

It doesn't matter that foundational core modules such as Test::Builder suffer maintainability problems because they have to work around long-deprecated features such as Perl 5.005 threads (thankfully, that's recently changed) under the theory that someone writing new code in 2009 with the most modern version of Perl the year 1999 had to offer obviously needs the ability to install the most recent version of a core module released in 2009.

It doesn't matter that the two-argument form of the open builtin is insecure and difficult to use safely, because three-arg open has only been around for nine years, so it might not be stable enough to rely on, and it's very, very difficult to migrate existing code to work around well-known security flaws.

Maybe I'm a very poor businessman, but I like when software gets easier to maintain and cheaper to write and safer and simpler over time.