Using a CPAN module (Buy) vs writing your own (Build) is a specific example of the broader Buy versus Build decision. Some rules of thumb:
- Build if it's your core business; Buy if not (e.g. buy, don't build, your computer keyboard ... unless you're in the computer keyboard business :). Buying CPAN DBI and XML modules, for example, looks good because it allows you to leverage the work of experts in fields that you are probably not expert in. Moreover, widely used CPAN modules tend to be robust and have fewer bugs than code you write yourself because they are tested by more users and in many different environments.
- Opportunity cost. Using a CPAN module usually takes less time than writing your own, giving you more opportunities to get your core business done.
- Cost vs Risk. Using CPAN modules seems "free" but there are hidden costs and risks. What if a CPAN module has a security vulnerability? What if the author abandons it? What if the author changes the supported perl versions/platforms? What if the author releases a really buggy version? How hard/expensive is it to write your own? Writing your own XML parser, for example, is much harder than your own File Slurper. How quickly can you isolate/troubleshoot a bug in 3rd party code? Can you fix it in an emergency? (e.g. in a large production system, you may not have time to wait for author to fix it).
- Dependencies vs Control. Writing your own saves you having to manage dependencies (e.g. Dependency hell) while giving you total control to tailor to your needs.
- Quality and Trust. How much trust do you place in the third party CPAN module? Is it good quality? (e.g. CPAN ratings, Kwalitee score, bug counts, how quickly are bugs fixed?). Does it contain gratuitous/unnecessary dependencies? (the ::Tiny CPAN modules were a reaction against modules that seemed to haul in half of CPAN as dependencies). How widely used is it? Widely used modules tend to be more robust and have fewer bugs than ones you write yourself because they are tested by more users in many different environments.
- Popularity. When you invest heavily in a 3rd party component, you want it to be popular and widely supported; you want to be able to ask for advice on using the module; you don't want it to die. If your CPAN module depends on a very popular CPAN module, there's a good chance that your module's users will already have this dependency installed.
For a CPAN module author,
every module you add as a dependency is a module that can restrict your module -- if one of your module's dependencies is Linux-only, for example,
then your module is now Linux-only; if another requires Perl 5.20+ so do you; if one of your dependencies has a bug, you also have that bug; if a new release of one of your dependencies fails, the likelihood of your release being unable to install increases; take care with dependencies having a different license to yours. Don't introduce dependencies lightly.
See also: w/Modules and w/o Modules
Updated: added Opportunity cost bullet point, DBI/XML example, note that widely used modules tend to have fewer bugs, and warning re module dependencies.
I've updated Writing Solid CPAN Modules with advice on this topic in a new "Dependencies" section.
