The power of a CMS built in Drupal is that it gives control of site content creation and manipulation to the marketing team responsible for managing it. This reduces their dependency on developers and puts them in the driver’s seat for updating, creating, and optimizing their website. This also frees up development time to build out new and/or maintain custom functionality. And honestly, developers prefer to code than deal with content integration while clients love having the autonomy to manage content on their website at any given moment.

Clients would rather be paying for developers to do actual development than address tasks that could be handled by themselves or their content managers. This strategy is a win-win for (1) empowering clients to update their content whenever they want, (2) allowing the developers focus on custom development tasks, and (3) making website maintenance more cost effective.

This leads us to another (and perhaps the most) cost effective feature that using Drupal provides: not every aspect of a build requires custom development. Since Drupal is an open source platform, there is an is an extensive library of (free!) modules created and maintained by a very strong developer community.

This is an advantage over the pay-for-code model, which has companies selling software instead of developers contributing software. More often than not, they want to sell software from their website so the company can control where the money is flowing and to track SEO and web related data. This doesn’t mean that these companies are necessarily controlling schemers, but this method leads to a scattered distribution of modules that are all for the same core piece of software.

The nice thing about Drupal.org contributed modules is that they have a vetting process and transparent standards. But part of the challenge presented to the clients, is that since there are so many modules out there, it isn’t always easy to know which ones to choose. Because of this it’s important to have a list of standards when evaluating modules.

Basic way to evaluate a Drupal module

• Popularity/number of installs. It’s always a good sign when a module is widely used.
• Making sure the module is actively maintained. This indicates that bugs are being fixed and new features are being added. This can be important because once the module is installed we become "invested" in it--how it works, how to train clients, how easy it is to upgrade, etc.This is usually more important for newer or complex modules. Many modules are "stable" and don't require new features or bug fixes. Service modules that communicate with an API usually don't need to be actively updated (unless a new API is released).

In-depth evaluation of a Drupal module

In order of importance, this is what we recommend evaluating when assessing a module for your website:

Downloads: Module is fully released (e.g. 7.x-2.1 NOT 7.x-2.1-beta, 7.x-2.1-alpha, and never t 7.x-2.1-dev). Every now and then we'll use a 7.x-2.1-beta if it’s tried and true and A LOT of people are using it (e.g. https://www.drupal.org/project/draggableviews used to be in beta and was still was widely used for a long time), but this is rare and not recommended.

Project Information:

• Maintenance status is "Actively maintained"
• Development status is "Under active development"
• Number of Installs exceeds a few thousand. There isn’t an exact number for this, but you also don’t want to necessarily be a guinea pig especially if it’s a feature-rich module.

Maintainers: Up at the top right of the module page, look at the Maintainers list and the last commits. If the last commit was two years ago, that raises some red flags. On the other hand, if all the above passes our standards and the last commit was awhile ago, it just might mean they built a totally rad, stable, simple, and problem-free module.

Reputation: If the module is lightweight and doesn't get its hands in everything, it scores some major points. If it's a beast with octopus arms getting its tentacles into everything, use it with caution and only use if absolutely necessary. Uninstalling those suckers can be painful and they can leave behind some remnants and residue, especially if they have database dependencies with user profiles, other modules, etc.

Still not sure: after evaluating a module and it’s still questionable as to whether we should use it or build our own custom version, we’ll inquire internally to see if anyone on our staff has positive/negative feelings towards it OR has a better alternative.

Drupal module vs API

Another scenario you might run into is choosing between a Drupal module and a third-party application and API. An example of this is that while there is a Drupal module for Instagram, there isn't one for Olapic. Moreover, if you are already using Olapic, our development team would have to create a custom module to connect to the Olapic API and pull down images that way.

Drupal Module Evaluation Recap

When evaluating your next Drupal module ask these key questions:

• What is the version? As a general rule, only use versions that are fully released.
• How popular is it? Look at the number of downloads and installs.
• What are the known issues and bug counts? If it has a lot of critical and major bugs against it, you likely will want to look for alternatives.
• Is it actively maintained? Look at contributors and last updated dates.

The golden rule is that the module should provide greater functionality in a shorter development time than what can be developed in the same or similar amount of time from scratch by a developer.

If you have any questions on evaluating Drupal modules please feel free to contact us directly or connect with us on social. And remember, always make sure to install and test these modules on a development or staging environment before taking it live!