Risk is the possibility of incurring loss. It’s not the loss itself. Everything has risk. It’s haphazard planning and design that claims there is no risk. Good planning involves identifying risk and mitigating it. If you can’t identify risks, you’re aren’t planning well. You can never eliminate risk. You can only mitigate it. Good planning is in the mitigation aspects.

But you aren’t trying to remove all risk. You evaluate risk, decide what you are willing to accept given your resources, and get on with your life.

If you say that using code from people you don’t control, don’t pay, and don’t know, is risk-free, then you are just ignoring reality. If you work long enough as a programmer, read enough Perlmonks, or use enough modules, you’ll recognize loss. For instance, I took over the Crypt::Rijndael module to make it work, so I get the reports of people who encrypted important things with the broken version and now can’t decrypt them, even though it passed the tests when they installed it. CGI.pm is a big risk because it likes to change features and it comes with perl. Upgrading perl upgrades your CGI.pm. I could go on and on with examples from my real experiences.

If everyone knew everything about Perl, CPAN, and modules, they could evaluate the risks and mitigate them, but if you’ve been around long enough, you know that’s not the case. People don’t know everything, so people make decisions based on imperfect knowledge. That’s risk.

Furthermore, despite open source being open, how many people really read all of the code they download? When’s the last time you went through third party code line by line? Or checked its test coverage? Do you do this every time you install something? Everything that you don’t evaluate completely is risk.

The code can represent some risk, but it’s not the only thing in the ecosystem. CPAN isn’t code. It’s an archive network with tools that do things, and sometimes you don’t want some of things things it does. How often do you try a dry run before you install any module and then completely evaluate what every dependency is going to do to everything going on in the system? I just lost a day because the new TAP::Harness didn’t play well with some modules I tried to install.

Do you use Perl? Look at CERT sometime. Using Perl represents risk, just like everything else does.

The common use of Perl is to share a central modules directory. That can be a bad idea, but remember that most people don’t know that. There’s a reason that’s different in Perl 6. When the sysadmin updates a module for some other user, you get the update too. I’ve consulted in plenty of situations where this turned out to be the problem.

As for abandoning a module, you lose all of the time since you starting using it and when you could have been working on your own implementation. You end up spending more resources to get to the same place in one of those situations. That’s just basic economics.

Don’t fall into the trap of thinking that there is zero risk. That’s just ignoring reality and what you already know. Any consultant who can’t tell you the risks should be fired immediately because they aren’t doing their job to give you the best information and look out for your interests. If they can’t see the risks, they don’t have the experience to advise other people.