Josh Waihi

Director of Product Management

Josh has over 10 years experience working with large scale Drupal inside some of the world's largest enterprises, governments and sporting events. High-end performance is Josh's wheelhouse from digital publishing in viral environments to sporting moments such as Grand Slam finals, Olympic coverage and even the SuperBowl. At Acquia, Josh is a leader in the Technical Account Management practice where we help some of our biggest clients achieve success with ambitious digital experiences built on Drupal and the Acquia Platform.

Evaluating Drupal Community Modules

July 31, 2022
13 minute read

When looking to use a module from the Drupal community there are a number of factors to consider, beyond its functional use, that determine suitable quality and support for your organisation to use.

When you deploy a Drupal site into production, who is responsible for maintaining it? How long will that site live for? These types of questions shape the risk tolerances of the project. E.g. Lower Drupal competencies means you need greater community support and more stable modules.

All modules on Drupal.org are open source and fall under the GPLv2 open source license. They are free to download and use at your own risk. Each project has its own set of maintainers and a sub-community that uses the module, interacts through issues and contributes bug fixes and feature enhancements.

Understanding the quality of the module, the volume of the community around it, the activity of that community and the module’s stability establishes the risk involved in using the module.

Let's walk through some evaluation criteria and look at a real community module, Feeds, as an example.

Community or Custom

In scenarios where functionality is not provided by the community or represents a too higher risk for your organisation to use, the alternatives are

To descope the desired functionality. Perhaps find a project where the functionality would suit and submit a feature request. This approach reduces the most cost and risk.
To fund further development of an existing module to an acceptable level of risk.
To develop and contribute a new module to the community in hopes of community contribution towards maintenance and enhancement.
To develop the functionality bespoke and do not contribute the functionality back to the community.

Each approach has different levels of cost, effort and risk involved. In particular, bespoke code (last option) always has the highest cost, effort and risk; as no risks, efforts or costs are shared with a community.

When the functionality must be provided, existing an existing module is typically the best approach. It will reduce development time and allow you to share maintenance costs with a wider community.

Module selection criteria

Consider this criteria when evaluating a project in the Drupal community. You'll need to decide where are the right thresholds for your organisation, based on the level of risk you want to accept for the added functional value a module provides.

Number of commits by maintainers

The number of commits to the project are an indicator of both maintainer activity and project maturity.

High volumes of commits shows the maintainers are historically active on the project and have matured the project. This indicates the module might be more stable or have greater functional capability.
Low volumes of commits indicates the module is new or minimally maintained and possibly contains a narrower set of functionality.

Low commits is not a disqualifying factor. If the project has an active maintainer or high download numbers (usage indicator) then you may still choose to use the module because it has the promise of community support.

To see the number of commits, you'll need to view the source code project page. For example, let's look at the Feeds module. On the right hand sidebar of the project page (towards the bottom) you'll see a Source code link. Click the link to be taken to the source code project page where you'll see the number of commits on the repository.

The older the project is, the more commits it will likely have. The Feeds module has been around for 13 years which puts Feeds rate of change at an average of 135 commits per year. Thats pretty good for a Drupal community project. Not many reach that level of activity. Feeds is also a comprehensive project with a lot of functionality. For modules with narrower function sets, you could expect much lower rates of change.

The time since the last commit

Community projects can experience high activity from maintainers when those maintainers needed the module but have since become less active in the project’s development and maintenance.

Commits made in the last month indicate an active maintainer
Commits made in the last 3 or more months suggest a less active maintainer and less active community using the project.

The less active the community around the project, the harder it will be to get community support for bug fixes or enhancements.

Using a module with a low activity community, you can expect slower release cycles. You will more likely have to provide your own support and fix your own bugs (and upload fixes/patches to the project issue queue).

The more complex the module is, the greater the risk to a low activity community.

Looking at the Feeds module source code project page again, we can see the last commit date of the active branch:

The number of sites using the module

Community maintainers have full control over the release stability of their projects which can make the versioning of a release an unreliable indicator of stability. Instead, we can use the number of sites reporting the use of this module as an indicator of exposure, to diverse use cases. Combined with the amount of open issues in the issue queue, this can give you an idea of its real stability.

The more sites this module has been exposed to increases the likelihood that the module will work as prescribed for your use case.

Drupal.org provides usage information from its Update module that resides in Drupal core. When that module is enabled, it reports to Drupal.org which modules are being used. View this information from the project page on Drupal.org.

Above is the project information for the Feeds module. Here you can see it's been used on over 98k of websites. So that level of usage is a great indicator of suitability for a diverse set of applications and stability - that it has such great adoption.

The stability of project releases

Maintainers will release versions of their projects based on where they feel the stability and supportability lies. There are some general definitions but beware that community maintainers will still vary on their definitions:

Release	Description
dev	Is a release of the latest changes on the release branch. E.g. 1.x-dev will contain the latest commits on the 1.x branch.
alpha	Alpha releases are tagged snapshot points in the release branch. They are considered unstable and untested in production applications. They’re also not considered to be supported by the maintainer or the Drupal security team. Alpha releases do not promise any form of upgrade path. The maintainer may diverge from an alpha release and not maintain an upgrade path. The purpose of alpha releases are for those interested in using the module to contribute through diverse feedback and code contribution. In some cases alpha modules can be stable enough to be used in production applications but their supportability remains a high risk.
beta	Beta modules lock down APIs in the project and do look to provide upgrade paths to a stable release. Beta modules still have no support from the maintainer or Drupal security team.
rc	RC stands for Release Candidate. At this point the maintainers are very comfortable with the module stability but are seeking further testing to firm up a .0 release. Often the last RC release on a release branch will also become the .0 release (e.g. 1.0 or 2.0).
stable	A stable release means the maintainers desire to main the module and the Drupal security team can provide security coverage over it.

Most community projects don't reach a stable release point yet still have active communities and high adoption. Thats often because the functionality they offer is of greater value than the risk associated with using the module.

Lets look again at the current releases for Feeds module

Despite being 13 years old and available since Drupal 8, the Feeds module is still only in a beta release state. However, the project experiences high community engagement and has active maintainers. Since it is in beta, there is no security coverage provided by the Drupal Security Team.

When security coverage is not available, using a community module is often still preferential as it may offer a stable release in future where security coverage will then be provided. Alternatively, creating new or closed source replacements come at greater cost and still without security coverage.

Open issues, closed issues and open bugs

These metrics provide two key indicators

How well developed the project is, indicated by the number of issues logged
How active the maintainers are, indicated by the number of issues resolved or closed.

High site usage coupled with low volumes of issues logged indicate high stability of the project. Anticipate ticket volumes to grow with the number of sites using the module. So think of the number of tickets in proportion to the number of sites using the module.

Here is the issue stats for the Feeds module:

The Feeds module has 833 open issues (81% have been closed). 30% of those are bug reports. Keeping in mind there are 98k+ of sites using this module, that means there is a reported open bug in around 0.26% of instances. That translates to a very stable module even though it doesn't have a stable release!

These numbers above are looking at the project in aggregate across its 13 years of life. The current 3.0-beta usage and specific issues in the queue may better reflect its beta status. But when evaluating a module, you want to evaluate its impact on your future so its historical performance can be a useful indicator of that and in this context, the Feeds module would be quite reliable to use.

Drupal compatibility

Does the module support the latest version of Drupal? Will it support the next version of Drupal? Choosing modules with future compatibility helps you access the upgrade path sooner and reduces your risk of being on an end-of-life, unsupported version of Drupal core.

For example, if you're on Drupal 9 and Drupal 10 is available, then Drupal 10 compatibility is important even though you're not on it yet. Every module you use, that doesn't have Drupal 10 compatibility (in this scenario) presents a risk to your upgrade path.

Historically, the Drupal community has run upgrade bots that issue upgrade patches to help maintains upgrade to the next version of Drupal. You can look for these issues in the issue queue to see how the project is approaching compatibility of the next major version of Drupal (at the time of this writing, the next version is Drupal 10). As an example, here is the issue for the Feeds module.

Depending on where Drupal core is in its development cycle, determining future compatibility of a community module may vary. But the higher the module utilisation and the more active the community, the better chances you'll have of securing a community provided upgrade path.

Conclusion

With open source software, you ultimately mange risk through good ownership over the source code you use. You can reduce your costs by leveraging community functionality and support. Look for Drupal modules with high adoption and strong community and maintainers over release version stability indicators.

As projects mature over time, you may be open to less stable modules in the beginning of project development and contribute towards their stability as your project matures (this often happens organically through UAT/QA bug fixing efforts).

Organisations have varying levels of Drupal development capability and risk tolerance which means there is no one-size fits all approach.