Picking Contributed Modules for Your Project

Posted Mar 28, 2011 // 4 comments

One of the core strengths of Drupal is the vast library of contributed modules that the community has added over the years.  You can design an awesome site using only contributed modules, and this is one of the reasons why Drupal usage has exploded in every sector of the market over the last few years.  In many cases, there's a contributed model that provides exactly what you need, and if there isn't Drupal provides a development toolkit that lets you build your own.  Often times building your own modules is not an option, though - even given all of the tools that Drupal provides, knowing the best way to build a complex module that plays well with the larger modular ecosystem is not a simple task, and fixed budgets don't provide a lot of room for R & D.  

In some cases, you don't have a choice - some enterprise clients will not certify custom modules unless they can independently assure code integrity and security, and they may require that there is a support and maintenance plan in place to ensure that they remain up to date and stable.  Ongoing support may not be an option, and in these cases it's safer to build using modules that are trusted. 

Evaluating Contributed Modules 

Picking modules is not always a straight-ahead process.  Not all modules are created equally, and it helps to have some general rules for evaluating them against each other.  This is important not only because it gives structure to your process, but also because it helps you answer client questions like "why did you pick this module?"  If your project is required to undergo independent security review, as is the case with many enterprise clients, having documented criteria for evaluating contributed modules cuts time and expense out of what can be a frustrating and time-consuming process. 

A good rule of thumb is that a contrib module should only be used if it is stable, supported, and secure.  How do you determine this?  Get familiar with the module project pages on Drupal.org - most everything you need to know can be found there. 

Stable Release 

Drupal designates module releases as developmental, alpha, beta, release candidate, and stable, with only the last of these considered to be 'application ready'.  Although a module might work without incident in the alpha, beta, or release candidate stages, it is only the official, stable release that is warranted by the developer to be ready for production use.  It can be assumed that a release candidate version is stable enough to test for purposes of testing a module for potential use, but the release schedule should be consulted to determine the likelihood that a stable version will be available for incorporation into the final product.   

Technical Support 

The degree to which a module is supported - meaning, the frequency at which the module is updated and the speed at which bugs are fixed - is a function of several different factors.  There is no single metric that can be used to determine whether or not a module is "well-supported", so each module will need to be evaluated independently and judgment reached by looking at the following factors:

• Maintainers:  Was this module built by a development shop, or by an individual developer?  A development shop might have the resources to sustain a maintenance effort where an individual might not, but this can't be assumed.
• Community support:  In some cases, members of the Drupal community will involve themselves in fixing bugs.  A module with outside developers invested in addressing issues can be assumed to be better supported, although many modules remain stable and well-supported under a single-developer model.
• Popularity:  Modules that are more heavily used can be assumed to be more stable, as a larger number of users will identify bugs more frequently.
• Frequency of release:  Modules that are frequently updated can be assumed to be more stable, although simpler modules might have fewer failure points and fewer bugs, leading to less frequent updates.   
• Version history:  Modules that have been updated from one major version of Drupal to the next have a history of support.

These major upgrades take time and resources, and happen only when the maintainers have the resources to devote to it, or when the community demands a stable upgrade and organizes the upgrade on their own.  That said, there may be modules that have been developed only recently, have not gone through a version upgrade, and which have a robust support system nonetheless.

• User base to issue ratio:  This is a less-than-perfect metric, but if a module has a relatively high number of users but few issues listed, it's likely that few of those users encountered bugs.
• Ratio of open to closed issues:  How long does it take the maintainers to fix issues?  Are there issues that have been open with no attention - not even a "thanks, we're looking into it" - for months?  Read through the issue queues - a low number of issues can indicate a stable module, but if the few issues that have been posted are rarely addressed you should wonder what would happen if a serious issue arose.  

Read through the issue queue, and take a look at issues both opened and closed.  Compare what you read there against the use case you have developed for the module: how likely is it that the use you put it to will result in you posting an issue back to the project?  Are people who are using the module in the way that you plan to having problems, or do most of the issues arise from what would be in your scenario edge cases?  

Even though this evaluation process is by its nature somewhat arbitrary, a defined evaluation process can still be established.  If you need to produce documentation detailing the contributed modules that you have selected, one options is to create a matrix that maps the modules against each of these variables and assigns a simple rating. 

Module Security 

The susceptibility of a module to malicious exploits is in many ways a function of the above issue of support.  Although Security issues are not posted to issue queues, the issue queue will indicate the responsiveness of developers to posted issues. Modules that are regularly updated and moved through versions are likelier to catch security issues and are going to be more secure than those that are not.   

Knowing what common points in modules are exploited can educate you on what potential security risks the modules you want to use might have.  Follow Drupal's security resources to keep you informed of security developments:

• Security alerts for contributed modules: http://drupal.org/security/contrib
• Drupal's Writing Secure Code pages highlights common points of vulnerability.  
• If you have a Drupal.org account you can sign up for the security alerts mailing list, or alternatively subscribe to the RSS feeds for the same. 

Evaluating Requirement Tradeoffs 

Evaluating a modules for use on your project is not simply a matter of determining if it is a 'good' module - you also have to decide if it is the 'right' module.  Often times you will either find a module that functionally seems right, but which is in, say, alpha release; or you find a module that is stable, secure, and supported, but which only partially meets the requirements.  How do you decide between two options of this sort? 

Client Application Requirements 

You do have leeway in how you interpret the release status.  Enterprise clients might require that modules have a stable release, but for other clients a beta release might be acceptable, assuming that the functions you need from the module are not currently spawning bugs into the module's issue queue.   

Relative Importance of a Given Task 

Every module included in an application is selected to fill a specific role, and the relative importance of these roles needs to be taken into account.  A module that is integral to the basic functions of the site should satisfy more of the above-described tests than one that fills a fairly limited role.  Modules that provide add-on functionality that is more of an enhancement than a necessary functional pre-requisite can be more easily removed if the module becomes abandoned by its developers. 

Fungibility of Requirements 

Don't lose sight of your client's big-picture business requirements.  A technical requirement for a site or application is not the end-all be-all; a technical requirement stands in for larger needs.  Each technical requirement is crafted towards satisfying the client's larger requirements, and often times, when faced with a tradeoff between functionality and a strong and secure application, they will be receptive to hearing about alternatives.  Don't just go to them with a message that a requirement can't be met because an appropriate module is not available; take a well-thought out alternative to them, and don't be afraid to talk them through the pros and cons of the approach.  

Planning your Project Right 

You can avoid some of these issues if you keep them in mind in the early stages of analysis and planning.  If you need to stick with contributed modules, don't be afraid to use Drupal 6 instead of 7.  Drupal 7 has cachet and many, many improvements to core, but it will take time for many of the most useful contributed modules to release stable versions for 7.  Drupal 6 will be supported for quite a while, and will remain a strong choice for the lifetime of most of the sites being built today. 

Keeping educated on what modules are available will put you at an advantage when negotiating scope with clients.  If you know a project is likely to require only contributed modules, then knowing what your options when you start the processes of defining feature and scope will help to forestall any discussion of featuresets that are not possible with this approach.