There is a saying that “a whole is greater than the sum of its parts”.

However, often communities such as Drupal can get so tied up with (albeit healthy) internal competition and rivalry that the bigger picture and the outside world are forgotten.

A great example of this is the reoccurring discussion about duplicate modules.

Whilst I admit there is a place for it, I think often it distracts us from a bigger and better goal.

New Drupal users will be gained externally

I would like this article to persuade you as a reader (if you are a user or developer of Drupal) that you will benefit as Drupal grows.

Increased usage of Drupal brings more people that will write code, more exposure that tests features to their limits, and more opportunities for the resulting improvements to be contributed back so that your projects benefit from them in the future.

The resulting halo brings more users to modules that you use, meaning that these benefits are tangible for you.

Does this sound good to you?!

However, growth does not come by winning users between one module and another.

Growth comes because a user who may not have used Drupal for their project comes to your module.

As an example, as a maintainer of the Project Management Module, I don't wish to position it as a competitor to Case Tracker, ERPAL, or Project*.

Instead, I want potential users to know that there are robust project management and ticket tracking solutions based on Drupal, and for them to choose the most appropriate solution for their situation.

An example

I would like to highlight and complement the Drupal Commerce modules for doing this really well.

Unrelated to how technically good they are, they are seen outside of the Drupal community as a strong competitor in the e-commerce space.

These modules help draw new users to Drupal.

To illustrate this, recently I was helping a friend design an online store, and received from his payment provider a list of the supported software packages. Drupal Commerce was on the list.

Potential users do not think “what modules are available for Drupal?” They think “which solution will best fit my needs?”

Drupal Commerce is not competing with Ubercart, or any of the payment provider specific modules, but is actively encouraging new users to Drupal.

Even if you don’t use e-commerce functionality, this benefits you too.

Practicing External Competition

Now that I’ve built the case for competing externally and drawn out one set of modules that does this particularly well, it is time to consider how you too can practice external competition.

I don’t think I’ve got a golden ticket for this, but there are three steps that are commonly used and I think are worth noting:

1. Create a standalone project homepage

Whilst Drupal.org has great infrastructure for hosted contributed modules, if you are looking for a module on Drupal.org, you have probably already chosen Drupal as your CMS.

Having a separate website allows the text to be more focussed on a different target audience - those who are not currently using Drupal. Plus, you could draw out that your module is build on top of a popular, robust CMS as an additional feature. The site could promote Drupal as much as your module.

These sites may help inspire you: Drupal Commerce, Aegir, ERPAL, or Project Management.

2. Build a distribution

New users often want to try something out quickly, and may not have the time (or skills) to configure for a proper test.

For these situations, a distribution that packages your module, all dependencies and add-ons that improve the experience is very helpful.

Take a lesson from Commerce Kickstart and give the option for demo content too.

Even developers may use a distribution to learn about your module, before using your module directly for a specific project.

3. Rewrite your Drupal.org project page

Few of the project descriptions on Drupal.org project pages are designed with a new user in mind.

If you are a maintainer - look at yours now.

Does the description explain the point of the module, simply and clearly...?

...Or does the text dive straight in with a description of which databases your module is compatible with?

Each project page will be unique, but they are worth a critical review (for projects that could be used externally, rather than utilities).

Perhaps one day the Drupal.org project page will have more structured fields, I think this will help a lot too.

What do you think?

Please join in the discussion in the comments.

Category: WebsitesTags: DrupalDrupal PlanetcompetitionMaintaining an Open Source Module