Last updated 23 March 2016.

The Drupal community follows the ethos collaboration rather than competition. Too often new modules are contributed that do nothing new; instead, they only do it in a different way. We are then stuck with two modules that offer nearly similar functionality, but neither do it well enough. This leads to confusion, clutter, and a lot of inefficiency.

So please consider the following guidelines or ideas:

  • Develop and use one central API. Do not introduce new .incs, .modules, or other files with APIs, if there are modules that have these already.
  • Consult other developers of modules in your domain when you plan to add features, or plan to add a module. Try to agree on features, to avoid overlapping. Nothing is more confusing for a user when he has, for example a Spam Queue for comments, and a completely different one for trackbacks, which does not respect the options you set for comments. Even worse, but certainly not unheard of, is that module Foo breaks module Bar, because they want to do the same, or want to use the same database tables.
  • Do not try to duplicate functionality because "you don't really like how it's done there". That only adds clutter. Work to improve an existing module rather than introduce yet another random module, as that leads to confusion and frustration for the development, support and end user communities.

Respecting these guidelines will help you and the community get better. Only then will we be able to "stand on the shoulders of giants" as they say in Open Source Land. If you keep reinventing wheels, you will be stuck with lots of incompatible and half finished wheels. When you use someone else's existing wheel, and build a car on top of it, you can actually get somewhere.

Contributed Module Ideas Group

When a developer has an idea for a module, they are often not the only one with that idea. The Contributed Module Ideas Group aims to:

  • Reduce module duplication. We can prevent two independent developers from writing separate, duplicate modules.
  • Increase developer collaboration. We can get interested developers working together at an early stage of development.
  • Improve module quality. Others can shape and improve the ideas, leading to a better module from the beginning (or, at the least, a better road map for future development.)

Before submitting a new module idea, please do a little research and search for an existing module with the same functionality.

How to find a co-maintainer

If you'd like to find a co-maintainer for your project, follow the steps listed in these guidelines.

Document how your module makes a difference

If your efforts to work with an existing project fails, and you still want to go ahead and develop your own module, you need - at least - to make sure users need to be informed about possible functional overlap. This should be done on your project's project page in a section with the heading "Similar projects and how they are different". Make sure you:

  1. acknowledges the existence of similar projects; and
  2. briefly explain how they are different.


David Latapie’s picture


This is a very good advice — WordPress and Firefox (to name just a few) face a similar issue. Too much of something is not a good thing.

I think the current unstructured plethora of module is counter-productive and gives a feeling of amateurism. DrupalModule is great, but a more fundamental (read's) solution would be better.

How about dealing with existing crutch? For instance, Liquid is dead for all intents and purpose, but it still available (which is OK) without any notice.

I think that a basic set of meta keyword shall be used for every modules (including old ones, which makes it a loooong task). That may be some OWL stuff, Node Relationships….

  • similar-to (with the none keyword when not deprecated)
  • deprecated-by (with the none keyword when not deprecated, which doesn't mean it works well, just that there is nothing better). Any value other than none shall generate a corresponding deprecates entry in the right module
  • deprecates (with the none keyword when does not deprecate any module). Any value other than none shall generate a corresponding deprecated-by entry in the right module
  • external-requirements with a boolean value. For instance, ApacheSolr is great but has an external requirement (external requirement being defined as "everything else than what it required to run a default Drupal")

What do you think of it?

dreamdust’s picture

A simpler solution would be to allow users to flag modules as dead: If the module hasn't had commits in X number of days/months, and had X number of flags, the module would be marked "Inactive."

samualminor’s picture

I agree with you dreamdust because there are many modules with same uses and functions. I think what the best thing to do is to maintain only those ones that guarantee functionality and smooth-flow work. That flagging is dead is I think a good idea.

ericprado’s picture

I think some developers should stop copying the work of others. Instead, they can just improve one's project, I think it is more better, because I am one of those users who got confused which modules to use. It saves time and energy when you know for the fact that this module can serve and fit your needs well.