This whole thread brings up several points that management needs to examine before accepting/rejecting a module:


1. Does the management and/or engineer suffer from NIH (Not Invented Here) syndrome. This is a very real, and sometimes fatal, affliction where the perons involved will not accept a module/component/device/etc merely because it was not invented by their company/department/team. I saw this a fair amount at IBM, and I've heard that Motorola is notorious for it. This is often a matter of pride, sometimes a matter of distrust (which is a variant on pride), and occasionally a legal matter. Accepting a component not developed by your people/department/company can lead to support availability issues, etc, that may play a factor.
2. Are there practical ramifications to not accepting a module? It may indeed make *your* life easier, but what are the licensing requirements? Will it place your company in an undesirable position? If it's an Open Source module, and you are not a Open Source embracing company, this places you in violation. Developing your own component (and let's use this to cover just about anything we need, large or small, software or hardware) keeps your proprietary knowledge just that. Information may want to be free, but the shareholders don't always see it that way.
3. What are the long term support issues in the module? If you have a problem, will your people be able to figure it out? If it's a closed source component, and the company goes out of business, will you be seriously up a creek? (Obviously, the Open Sourcers will start going nuts right about here, but I'm taking this just a little past the Perl module discussion). Do you have rights to the source, if said company goes out of business?
4. What's the reliability of the component in question. We (Perl developers) have this tendency to trust CPAN modules. "Oh, they've been out there, they're debugged". Well, that's just utter nonsense. Some of those modules have only been out there since yesterday, some are so little used as to have no history, there are seemingly endless updates for others. Yet, we trust them. Now, if you've got the source, sure, you can fix them if you find the bug. If you're smart enough, anyway. How many of you think you could really fix something in Parse::RecDescent? What's the security, for certain modules? Do you *really* want to trust an enterprise financial package's core security functionality to a module with no history? (And you Open Source nuts, calm down. Just having the source doesn't mean you can see/find/fix/understand any/all the security holes. Security holes can be more than just an 'if' statement looking for a checking account number. Sometimes it's a race condition, or other trickier, less obvious beast.

While I readily agree that some of these examples are slightly outlandish, they are very very real. They represent concerns that *real* companies (that know what they heck they're doing) have. Open Source obviates a few of these, but doesn't necessarily fix the legal issues.

It's for reasons like these that companies would rather pay you 8 times what it's worth for you to write it. At that point, the company owns it. Assuming you're a half decent programmer, and you're programming for what you're paid, and not for job security, the company now owns that technology, free and clear (you weren't stealing that idea, were you?). Free and clear doesn't just mean licensing issues, either. It means they own the technology, which adds value to the company. A company that is built on a product that they don't own all the components of, or don't understand the technology of, is pretty worthless (unless you've got a management team that are consumate scam artists. Been there, seen that).

Anyways, I hope this has provided some enlightenment as to why companies can't always go to 'Free Wheel Depot'. Free is not always Free, nor always Best. And Dog help anyone who gets me started why companies shouldn't hire consultants most of the time... (Even though I am one! I love to consult, I hate consultants!)

--Chris

e-mail jcwren

JCWren raises some seriously good points in his post, and has given me a money-making idea that I offer free to the community... why not form a commercial Perl module certification service?

CPAN testers do what they can to make sure that a module passes its own tests on different platforms, but there's little checking on what those tests are all about. Not a criticism-- people have jobs to do.

So here's an opportunity for someone to make some extra cash. Start a company that verifies and supports Perl modules for a price. If you discover bugs, fix 'em and give the author your changes, and the whole community benefits. Paranoid bosses can feel better with some corporate support they're paying for.

On the other hand, I've worked for some fairly large companies-- HP and 3Com-- and the divisions that I worked for had no problem with the use of CPAN modules, so long as I was willing to vouch for them and fix any problems myself. (Thank god I rarely had to do that...) If one explains this to one's boss, one's boss might get entranced with the wish to play like the big kids play. (On the other hand, "because this guy on perlmonks said this is what they do" is unlikely to carry much weight, but hey...)

stephen

Seriously though, I think this comes from one of three things:

1. Micro-managing boss that doesn't know enough I can't think of anything to do here.
2. Acceptable boss who has a wrong idea In this case it's merely a matter of gathering enough evidence to support your position. Any ideas of what form such evidence would take?
3. Actual portability concerns Some modules are built on C code that _isn't_ portable. So either you need to prove that your module IS portable, or concede defeat.

" This is the kind of thread that will generate tons of useless "get a new boss" posts. I hereby declare that I will -- any such posts unless they provide a creative way of getting rid of the current boss :) (Special rules: No voltages in excess of 220V, no items considered "military-grade weapons" in the respective country)"

OK, so let's say that your Boss is named Bill...and the unlucky coder's name is redmist. In that case, redmist sneaks into the office and takes the UPS that he just "procured" from the salt factory (BTW, the UPS is filled with salt), and DROP IT ON HIS POINTY LITTLE HEAD!!! Then grab a cup of coffee and the insurance money and rip out his heart so he can see how black it is before he dies...then shrivel it up and keep it as a souvenir. Then, send it to college, for that extra bit of torture.

redmist
redmist.dyndns.org
email::redmist

---


Thanks to neshura, and Ozymandias for being my imagineers.

The important thing to remember about modules is CGI, LWP, DBI, and the XML::Parser. Unless your first name is, say, Lincoln, Gisle, Tim or Alligator, or Larry, you're not likely to sit down and write a module with that much functionality and quality from scratch. (These people tend to have the kinds of jobs where they don't have to fight over installing a module or two.)

There are a handful of very important modules that do their jobs so well and so completely that not using them is not only costly in terms of time and labour, but even hazardous from a security standpoint.

I think most managers who fall under the category you describe just don't realize how tricky it is to read an RFC and implement it in a useable and workable way. They wouldn't ask you to write a web server, why would they ask you to write your own code for handling CGI?

• Specifications
• Design
• Implementation
• Debugging
• QA

If you like this post, vote up lhoward's post instead. He's the stimulus behind this.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

To expand on lhoward's points, consider some of the basics in developing a large project: Specifications
Design
Implementation
Debugging
QA
Don't forget "Time". I think one of Perl's strongest points is the fact that solutions can be rapidly developed, programmed and implemented, which is critical in the business world.
I think if you can present Perl as a tool for the business world to stand alongside VB and java that you might have some luck.
I also think people tend to forget that agendas between management and their employers tend to differ slightly, and that if you present the problem and solution in their language, and discuss how it meets their requirements that you stand a better shot then if you were to 'get technical' or use an abundance of technically oriented facts and figures to back up your argument.

But see, I consider Perl modules to be extensions of the language environment itself. A company choosing to develop in Perl isn't going to balk at the fact that they have no IP interest in the Perl language itself. Same with the modules. Perl modules are typically written with some very flexible licensing. You can generally distribute Perl modules with your script under most any license, and if the distribution of a module is impeded by the fact that you're trying to sell your script, all you have to do is provide instructions (or a properly built package so that CPAN can extract the dependencies on its own).

At that point, the only thing to complain about is the fact that this huge project has turned from a 2-month, multi-10-thousand-line application to a 3-day Perl script, making extensive use of pre-written modules. Some companies intent on making a bundle from such an application are going to get iffy about it when they find out the resulting script is only a few hundred lines.

Note: Code samples are for conceptual use only and generally are not meant to be cut/pasted into a production application. Always 'use strict', have a thorough understanding of the code you use, and check the return values of functions and handle errors according to your needs. - Fastolfe

But see, I consder Perl modules to be extensions of the language environment itself.

Fine. I agree with you. But guess what? The manager who objects probably doesn't, or s/he'd allow you to use the module, yes? You'll be more persuasive if you set aside your own viewpoint for a moment and try to address the manager's concerns in ways that make sense to the manager.

For (too) many organizations, it doesn't matter that Perl's licensing is flexible and that modules are easy to install. Using modules save programmers lots of time, but represent additional work for someone, and that costs $$$. Your argument will be more effective if you take the time to find out (or estimate) that cost and then show how much more money is saved by using the module anyway (a cost-benefit analysis). Trying to argue that the manager is looking at it "incorrectly," or that there aren't any associated costs, is just more likely to make him/her stop listening.

I have done this in the past numerous times, including convincing the IT department of the investment banking arm of a large German bank to use Perl as the main scripting tool for Unix and NT platforms.

First, if the problems you work about are not important to someone on the business side, you will probably loose. You normally need someone from the business side fighting on your side.

Second, the first thing is to prove that the module you want to use solves the problem. Create a prototype, or a "tracer bullet" if you want to use the code in the future. Do this in a time slice where nobody can say you are wasting your time on useless things.

Third, convince the people that have the business problem that you can solve it. A running demo or prototype usually gets the point across very fast.

Now, go to your boss, pointing out that you have solved an important business problem. Tell him how you did it, and supply the things you need to make a new tool acceptable in your work environment. Usually, this means providing a support address. Easy for Perl. There are several companies that offer support. Provide a reference to those. If any conflicts arise on this level, raise the odds by confronting your boss with the business people. Usually, they don't care about IT internal stuff like Perl modules etc., and will be happy about the solution you demonstrated to them. In the typical company, your boss will lose, since the business is the owner of the money in the end.

Note: using other people's modules does not relieve you from the obligation to understand what they do, and how they do it. A part of point two (prototype) above is investigating if the module really solves your problem. It won't do you any good to propose solutions that break down in the face of real world concerns like security, stability, maintainability, and so on. E.g., if you are the only one that understands the code, then you have a problem anyway.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Your theory breaks down about the time you have to compile a module. Many Windows machines do not have MSVC, or Cygwin, installed. In fact, short of developers, I would imagine that could be constrained to 'most'.

Far less likely is a Unix machine without a compiler. While it's unusual, in my experience, it's not unheard of.

Another flaw in that whole argument is deployment. I don't about ActiveStates latest versions (I'm running 5.005_03), but there's no pretty installer method that allows the IT 'droid to walk up to a machine, run an installer, and *poof*, the application with all the required pieces are installed. While Redhat has RPMs, and BSD has their thing (I don't know about it), Windows has Install Shield. However, Install Shield does not lend itself well to installing Perl applications, especially ones that require module compiliation.

In theory, I think you can compile the modules once on the developers machine, and distribute the .O files. I've never tried this, as I've never deployed a non-server based Perl application. But, nonetheless, deploying an application is a major pain in the rear-end.

What Perl needs is a friendly multi-platform installer (read: Linux, Windows, Mac). Some kind of facility for a integrated target compiler, or a way to optionally precompile the binaries for each platform, and install according to the platform being run on. What would would be really slick is a tiny Perl app that runs as an executable, that reads meta-instructions from the distribution file, and basically boot straps up to a full blown uninstalled version of Perl in the distribution file. This would allow a complete non-dependancy on any installed software on the target machine. I'm imagining something like PkUnZip or an RPM type package that has been generated for all platforms.

You could optionally reduce the distribution file size by making it a requirement that Perl and/or certain modules be already installed. But, with todays 'net bandwidth, and density of CDROMs, who cares if the distribution file is 600K or 600Mb, if you can do a bare-OS up install?

It's my contention that a mechanism like that would *really* make Perl take off, particularly on Windows and Mac OS machines.

(And I don't want to hear any "Windows is better than Linux/Linux is better than Windows" crap. Perl needs to transcend OS-centric views in life, and be truly cross-platform, not be an invoker of religeous wars.

--Chris

e-mail jcwren

In our environment, we have two classes of machines (well, typically 3 or more, but I'm generalizing): development and production. On a development machine, I would expect a compiler and all of the tools I would need to build an application, including all of the necessary modules. On a production machine, we, for example, have no compilers. The machine is locked down and designed only to accept content originating from the development machine. We can get in to fix things, but new binaries or code must come pre-written and ready for use.

Since Perl modules must be built on target platforms, this makes things difficult for us. We have to either resort to a manual installation or just hope that the module doesn't use any non-Perl code and that it can simply be copied to a target directory.

What I would like to see Perl have is not only a way to package modules (or at least dependency information so that the modules can be fetched a la CPAN at application install time), but a way to roll out a set of modules to a production server from a development one.

Note: Code samples are for conceptual use only and generally are not meant to be cut/pasted into a production application. Always 'use strict', have a thorough understanding of the code you use, and check the return values of functions and handle errors according to your needs. - Fastolfe

ActiveState distribute binary versions of a selection of modules, most of the common ones - but not all of them - which they keep reasonably up to date. It's a relatively simple matter to install them (there's a perl script who's name I've forgotten, which downloads the packages and installs them). If you've actually purchased ActiveState you get a nice GUI which does the same thing as the script.

This would certainly be easier to use than RPM's (who wants to find the RPM's themself?!). And is also easier than using CPAN directly since the user/admin doesn't have to download the package, configure it then compile it.

In reply to the latter part of you message, perhaps take a page from Debian's book and have servers which automatically compile the packages on the server. Then when you install the package it also works out all the dependencies and installs those packages as well (and their dependencies etc).

I do see a major problem with this approach though, there are modules which you want to configure for each machine (location of libraries which it depends upon) which vary. This could be fixed by adding shared librarys to LD_LIBRARY_PATH or /etc/ld.so.conf.

If we could make some nice automated compilation/installation system that would be really neat. I think it's possible too...

Perhaps your management would feel ok about you creating where appropiate, some of your own modules... Then use that directory.

Don't do this if it would be subject to being fired :-) (unless you want another perl job of which there are many to choose from in my neck of the woods)

#!/usr/bin/perl

use lib "/InhouseModuleDir";
[download]

Perhaps after you have been using them in dev/test and they've been shown to be "ok". You can get them put in their normal place?

My other line of reasoning was: "this freeware has been around since 1996 which means it has had over 1 million independent installations and tests in many environments. Thus, it has had lots of time to receive and fix bug reports.

Still it doesn't mean that everything is working the way you think. You never know, and if you are certain your own code works right, you should still check the mentioned modules...

Jouke Visser, Perl 'Adept'