‘There’s a module for that’ is a common refrain in the Drupal community and rightly so. The size and variety of the contributed module space is a big positive for any project considering Drupal. However, always jumping straight to a contributed module may not be the panacea you’re hoping for.
So how do you decide whether to use that contributed module or build it yourself? Read on, rational reader.
Contributed Fixes: I’ve got a theory
Time for a quick recap of some of the benefits of open source software: you’ve got a whole community supporting each open source project. Code published publicly can be reviewed by thousands (or hundreds of thousands) of developers, making it more likely that bugs and security issues are found and fixed.
Now, this definitely happens with Drupal core. I know I end up spending a non-negligible amount of time looking through the internals of Drupal when trying to fix bugs (even when the cause is elsewhere) or trying to understand how parts of a system work. This stretches to the more popular contributed modules as well. The Views module reports over 8 million downloads and other people will have looked at the repository’s web interface. Even simpler modules like Menu Block and Page Title have over half a million downloads.
Can all Fixes be Trusted?
In theory, theory and practice are the same but in practice, things go bang. To start with, we can’t be sure that everyone who downloads the module has even looked at the code, never mind reviewed it in depth.
As we search for more niche modules to meet our needs this problem worsens. Less popular modules, such as Auto Assign Role (107k downloads) or Publish Button (47k downloads), can be very useful but fewer developers will have reviewed them and even fewer will have reviewed the current version. Therefore, the question becomes
Is it better to do a full review of this module or to build a custom solution?
If the module is simple and focussed around the task in hand, then a review might well be the more efficient choice. The added benefits of a community to answer questions and improvements from updates just sweeten the deal.
However, any functionality that you don’t require is just extra code to review and likely makes the code more complicated to understand. The extra integrations with Drupal and other modules (particularly custom modules) are high risk places for bugs that could come back to bite you later. Even if we ignore custom modules temporarily, the chances that the specific combination of modules (and versions with patches) on your site have been used together before shrinks with every module you add. As these modules touch more parts of the site it is increasingly likely they will conflict in some way.
Is it worth the additional risk for functionality you’re not using?
Unforeseen Issues: Don’t let the bedbugs bite
Oh fiddlesticks, the QA team have just reported a bug that you’ve traced to the contrib module. If this hasn’t been reported on the relevant issue queue, or if it has been reported but is unfixed, then you will have to dive into someone else’s code. Even if you did a thorough review of the module it may be structured strangely, not follow standards or just generally be more difficult to fix than a simpler custom module.
While I’m sure you would add a patch to the issue queue when you do find a solution there’s a chance it won’t get committed to the project or will sit in the purgatorial “Needs Review” status. This means the patch will need re-applying and, perhaps, re-rolling whenever the module is updated. While one module is a minor inconvenience, a number of modules with permanent patches can start to become time consuming to manage.
Choose your Modules Wisely: a hybrid theory
I realise this post has been quite negative and it might sound like I’m suggesting that you should never use contributed modules. To clarify, I am definitely not saying that. That would be silly...
In the majority of cases, it is absolutely the right decision to use a contributed module.
I’m simply saying that, sometimes, it’s worth considering whether to roll your own solution. As always, expertise lies in finding the right shade of grey for the specific circumstances of your current project (and there are far more than fifty).
