Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

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.


In reply to Re: Criteria for when to use a cpan module (Buy vs Build) by eyepopslikeamosquito
in thread Criteria for when to use a cpan module by nysus

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (5)
As of 2024-03-29 07:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found