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?Ask your manager how many support contracts they have, and what the experience is when calling for support. If they had prompt and good support from the vendors (or never had to call them), it isn't good for you. But if it turns out vendor support wasn't useful, you make a much stronger case.
Abigail
In reply to Re: Enterprise Perl?
by Abigail-II
in thread Enterprise Perl?
by meetraz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |