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:
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...
In other words: how many sites are currently using this module?
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.
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...
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.
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...
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?