What Criteria Should You Use to Evaluate Drupal Modules for a Project? Here's a Top 5

7,093 modules currently available for Drupal 8 only... Now, assuming that you've already made your selection, that you've put together a “pile” of potential module-candidates for your project: how do you evaluate those Drupal modules? How do you narrow down that list to the truly valuable and perfectly suitable ones for your own project?

How do you assess their value/quality? Their level of stability and security? How do you determine whether they're fit for your own project's needs? 

What criteria should you be using? 

Note: it's a no-brainer that all criteria are of no value when they're not set against real-world use cases.

For instance, small size businesses favor well-vetted modules, while larger teams will be more confident to give promising, yet still under-development modules a chance. The latter have the right amount of experience, expertise in Drupal development and... resources to contribute with patches if needed.

Now, here are my promised 5 most important criteria to use when you need to evaluate Drupal modules. And to assess whether they're the perfect fit and added value for your project:

 

1. Security

There is a straightforward method for you to quantify the security of a “module candidate”:

Just check whether the module's receiving security coverage. That's the signal you need.

For, if the module's maintainer has opted for his/her project to go under the Drupal's security team “surveillance”, you have a guarantee that the module's being regularly checked for any security vulnerabilities...

 

2. Reach

In other words: how many sites are currently using this module?

How to Evaluate Drupal Modules: Project Information

And do keep in mind the “X sites report using this module” data is more relevant than the no. of downloads...

Has a community been built around this module? Is the number of installation “impressive” enough? Also, what patterns can you spot when analyzing this data over time? Is there a tendency of growth or not quite?

 

3. Assess Risk When You Evaluate Drupal Modules for Your Project

Rich functionality ships with higher risks.

Do keep that in mind when you evaluate Drupal modules for your project! 

In other words, if the module that you're analyzing provides a simple “add a block to a page” feature, it presents far less critical risks for your website. But, if the evaluated module comes packed with powerful functionality and a more complex codebase, you can be sure that the potential risks lurking in there are higher.

For instance, such a robust, feature-rich module could pose problems (e.g. data loss) once you've removed it from your website.

 

4. Issue Queue

Or “currency”, if you wish...

How to Evaluate Drupal Modules: Issue Queue

And here, the gravity of reported bugs is equally “worrisome” as the lack of activity around the logged issues.

Let me explain: you should be equally cautious about a module that has piled up a high volume of security issues as with a Drupal project with no recent commits — patches or other updates — whatsoever.

 

5. Overall Activity

Frequent and recent commits are one of the best indicators of quality and stability to look for when you evaluate Drupal modules for your projects.

How to Evaluate Drupal Modules: Commits

Have any code updates been uploaded recently? Any stable releases? For no (or poor) commit activity on that Drupal project page is a strong enough signal that... the module's been “abandoned” by its maintainer and might pose risks to your own project.

And that when/if trouble strikes... you'll find no support in there.

 

Bonus: The 3-Step Evaluation Process 

And, though I've promised you 5 useful criteria to consider when you evaluate Drupal modules for your projects, here's a “bonus” for you. An evergreen and always-efficient approach developed by the OSTraining team: the DMV method.

Documentation & Maintainers & Versions (or Project Information).

Consider these 3 key aspects when trying to assess the quality, stability, and security of your module candidates:

  • Documentation: always read the docs; information like what a module does, what's the level of support that you'd get, what the main security/compatibility issues are... is right there, in the documentation
  • Maintainers (or reputation): look through their history as Drupal contributors. What other critical contributions have they made? 
  • Versions: needless to add that you can't force fit a Drupal 7 module into a... Drupal 8 project...

The END!

These are the 5 useful criteria (plus an additional bulletproof technique) to include into your methodology as you're trying to determine whether a module is fit and valuable enough for your Drupal project...

Are there other critical aspects that you usually focus on?

Image by TeroVesalainen from Pixabay