You might be able to get "commercial support" for perl (note the lowercase letters), but who ever is supplying the support, it's not "their product". The have far less influence when it comes to adding features or when updates do come out. (Of course, you could branch, but do you really want to go there?).

If you have a program written in C; its compiled with SUN's commercial compiler, and it has problems after applying a patch from SUN - you can call SUN (if you have the right contract). But if your program is written in Perl, and it has problems after applying the patch - then what? Rolling back the patch might not be solution, and it's far less likely SUN will come with a fix for you.

I've been a developer, and I've been a sysadmin. As a developer I know the sentiments of wanting to use whatever fancies me. As a sysadmin, I know the frustration of developers (and managers) blaming the admin if their favourite tool doesn't work on the production platform (noone ever blames their favourite tool (or themselves), it's always something else).

Does anybody have any other suggestions for a rebuttal?

Abigail

Afterthought: Here at the GIANT company that I work with Perl isn't a "standard" either. As soon as I got here I started loading modules into my home folder and using it as a utility to munge stuff. It saved me a bunch of time even if I couldn't use it for "production" code. It's funny when I get the hangdog looks from developers: "How'd ya do that?" "I just wipped up a lil' Perl script." "Oh... I don't know nuttin' bout Perl.". Thank god HP-UX has it installed by default.

It seemed like the place was hopeless until I just found out that they were going to go to CVS. The person in charge of the decision's been with the company for 25 years and just didn't trust open source. After years of hearing developers begging for it he just went and changed his mind. The times they are a changin'.

()-()
 \"/
  `                                                     

The C language has no support, but C compilers do. SQL has no support, but Oracle does. I don't think you'll win the argument that way.

Demonstrating the quality of support Perl has and the support available for purchase from ActiveState would be enough to convince any reasonable person. However, support is almost certainly an excuse, rather than the real reason, so winning that argument may be useless. Of course, if you can get your employer to give some money to ActiveState, by all means do it. ActiveState pays people to improve Perl for us, so it would be nice to keep them in business.

I truly wish you the best, if you can hang on to that job and use Perl in your own spare time, then do so - if you really have to use Perl - seek another employer (but don't just quit!).

jeffa

If something happens with software that is supported by a vendor, you can certainly call for support, but what is the likilihood of actually obtaining effective support, and what is that support going to cost? Do you really believe that we would get any attention out of Sun if we were to run into a problem with Java?

With Perl, we're not locked into a specific vendor for support, and the community from which we can get prompt attention is very large.

Do you really believe that we would get any attention out of Sun if we were to r un into a problem with Java?

Well, I haven't done anything with Java, so I wouldn't be able to answer that. But I can answer some other questions.

• Have you gotten any help from HP when facing NIS problems at 5 am on a Sunday morning?

  Yes

• Have you gotten any help from Netapps when facing occasional crashes?

  Kernel patch was supplied within a week after submitting a core dump.

• Have you gotten any help from Sybase when facing database problems?

  On numerous accounts; many problems were fixed right away or I was called back within 4 hours by a specialist.

• Have you ever got any help from SUN?

  More often than I want to remember.

With Perl, we're not locked into a specific vendor for support, and the community from which we can get prompt attention is very large.

Perl 5.6.0 was released more than 2 years ago. Perl 5.6.1, its first and only maintainance release was more than a year later (and more than a year ago). Perl 5.8.0 will be here soon, but hasn't yet arrived yet.

Releases of open source software isn't always as speedy as we like to claim it is.

(And no, this should not be taken as a sneer into the direction of Jarkko, or p5p - not at all).

Abigail

Perl 5.6.0 was released more than 2 years ago. Perl 5.6.1, its first and only maintainance release was more than a year later (and more than a year ago). Perl 5.8.0 will be here soon, but hasn't yet arrived yet.

Releases of open source software isn't always as speedy as we like to claim it is.

Open Source has the luxury of releasing when it's ready, or at least readier than much commercial software. My experience with Open Source is mostly the Perl and Apache. With those, I haven't seen the need for frequent releases.

I've managed projects in the past that mixed Open Source software with commercial software, including a project that had 100KLOC of Perl. We built 5.6, and then 5.6.1 ourselves, from source. In the year and a half I was with that project, we had no problems with Perl that we couldn't solve easily ourselves, and no problems with Apache that required going out of house for support. It just worked. I can't say the same for IIS, or various incarnations of Microsoft database access libraries. It takes them lots of releases to shake bugs out.

I've been in many situations that required throwing "incident support" money at vendors within days of installing their products. We reported bugs to Microsoft that took months to fix, if that (the one that corrupted NT filesystems did get fairly prompt attention).

I went through this a couple of years ago with my employer. So before going before our product approval committee I called around and searched our servers for all Perl scripts currently in use (unofficially at that time). When they saw how many scripts (and how long) Perl had been used in critical points in applications and system administration they realized they had to approve Perl else essentially stop production on several applications

On the support issue I don't recommend referring to the P5EE group that ignatz referred to just yet. This is still very much at a discussion point and could very well backfire if you brought it to their attention right now. The Active State issue is compelling for management, however, after they saw how long Perl was being utilized without support that argument disapeared. You might want to point out that there is no one to support any .bat or .ksh scripts in your Enterprise either. If they still push the issue offer to start an internal Open Source/Perl support group! (I'm still working on this).

And don't forget that Perl is shipped standard with Solaris -- showing Sun's adoption seems to pull some weight as well.