Re: Criteria for when to use a cpan module (Buy vs Build)

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.

Comment on Re: Criteria for when to use a cpan module (Buy vs Build)

Replies are listed 'Best First'.
Re^2: Criteria for when to use a cpan module by DrWhy (Chaplain) on Feb 02, 2019 at 07:54 UTC
Another point to consider is the extra pain that you might have to deal with when you upgrade support to a new platform. I just finished upgrading our large and complex Perl-based internal production system to run under a newer version of Linux which comes with a newer Perl and other newer library versions. We use a large number of CPAN modules, and there were three CPAN suites that had to be 'fixed'. BerkeleyDB had to be recompiled to match the older libdb we use for our binaries (couldn't use the vanilla libdb that came with the new version of Linux). IO::All and IPC::Run started producing warnings due to being older versions. I ended up installing the latest version of IPC::Run and that worked fine -- luckily the interface hadn't changed in a way that broke our code that uses it. The issue with IO::All turned out to be a bug(ish) that didn't produce warnings under older versions of perl, but does in the version we upgraded too. Since that was actually a bug, even against the older version of perl (which we also still need to support), I elected to fix the bug in place, which means that I didn't have to upgrade IO::All and risk having to update our code to adapt to any changes in a newer IO::All. --DrWhy "If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."	[reply]
Re^3: Criteria for when to use a cpan module (Titus Winters Talk) by eyepopslikeamosquito (Archbishop) on Feb 02, 2019 at 11:26 UTC
I just finished upgrading our large and complex Perl-based internal production system to run under a newer version of Linux which comes with a newer Perl and other newer library versions. Yes, we face a similar problem across many different Unix flavours. We don't use the system Perl on any platform though, always build our own Perl from C sources. But yes it's a big and hairy problem which is why we're gonna do it early in the release cycle to allow plenty of time for flushing out obscure bugs. Unfortunately, we've got pretty poor test coverage on much of our code, so we'll need to do quite a bit of manual testing. BTW, I was flabbergasted to hear Titus Winters in C++ as a Live at Head Language claim that Google have a single C++ code repository, shared across the whole company, containing mega millions of lines of code and that they always "Live at Head", meaning that everyone is always using the latest version of all code ... so they never do "upgrades"! As you might expect, to pull this off, you need strong discipline and excellent test coverage, combined with very sophisticated automated tools. Some points from Titus Winters talk: Programming ("Hey, I got my thing to work!") vs Engineering ("What happens when my code needs to live a long time?"). Engineering is Programming integrated over time. SemVer proved inadequate at google (it over-simplifies and over-constrains). SemVer summary: given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes; MINOR version when you add functionality in a backwards compatible manner; PATCH version when you make backwards compatible bug fixes (additional labels for pre-release and build metadata are available as extensions). Mentions the dreaded diamond dependency and that dependency graphs grow quadratically. Titus Winters is the founder of Abseil and chair for Library Evolution Working Group (design for the C++ standard library). Update 2023: See also: Re: Rosetta Test: Long List is Long - Abseil	[reply]