In an earlier post (The PM makes Project Management “work”), I discussed the common feature between agile and waterfall project management methodologies.

I proposed that it was the presence of the project manager that ensures that the correct tasks are completed in the best order, not something special about the process or methodology that is chosen.

NB: Readers reading via the Planet Drupal aggregator may not have seen this post as it was not specific to Drupal or Open Source.

Open Source communities are different!

In Open Source, the motivation of being involved can be the freedom to "scratch your own itch” or to work out of interest rather than necessity.

Whilst there may be a central decision maker controlling acceptance of code, there is no one that can force an individual to dedicate their time to the project, or to a specific task on the project.

Furthermore, if the central decision makers and community disagree, there is nothing to stop contributors forking the project and continuing along a different path.

In this article, I propose that Open Source still needs a project manager role, but the role needs to take a very different approach of “Nudges”.

Does Open Source need Project Management?

Competition affects open source products as much as proprietary ones.

With a commercial company selling proprietary products, if time and innovation is not channelled efficiently then costs will exceed revenues and the company will fail.

In the same way, if time and innovation in an open source community is not channelled efficiently then burnout in the community will occur because development needs will outweigh the (voluntary) time available, and the product will not stay relevant against open source or proprietary competitors.

Drupal has seen a number of key contributors burn out and stop contributing (at all or as much) – it is a situation that really happens.

Project Management is just one factor that helps that efficiency to ensure that needs and time remain in proportion.

But it is also an essential one.

What is a “nudge”?!

In the introduction, I proposed that a better methodology is based around “nudges” – where a “nudge” is a means of changing others’ behaviour without removing their ability to make their own choice.

There is a great book on the topic (itself called “Nudge”).

It explains how “nudges” are used around the world and gives a real insight into the way that humans make choices based on the options that they perceive.

This probably sounds counter intuitive to you, so let me give a couple of examples from the book:

• Good defaults: In the UK, employers are now legally bound to enrol new employees in a pension scheme. The employee is allowed to opt out with no penalty, but most employees do not. By changing the default, people are saving more with no loss of choice.
• Comparative contrast: Companies often show a comparison of prices and features between different products that they sell (for example, website hosting packages). Research shows that you are more likely to purchase a product if there is a more expensive alternative, simply because it makes your choice appear like a saving!

How could a “nudge” help Drupal?

Of course, open source software development is a million miles away from designing pension schemes or product pricing!

But I believe the principle can be used to set up a project for success (i.e. to help keep a project in line with the project manager’s desired direction without alienating developers).

The reason it can work is that developers can feel welcome to “scratch their own itch”, whilst project managers (maintainers) can provide the guidance on the direction.

This may sound new, but part of it is no different to good user experience (UX). Make it easy for developers to contribute, and it is more likely that they will.

In Drupal core, a lot of this happens through the Drupal 8 Iniatives. As priorities are explicitly stated, there is less fear, uncertainty and doubt (FUD) about which changes may be accepted.

There is a wider range of openness in contrib, and I am hoping that more awareness of how a “nudge” could affect choices can really boost the way that the community works together.

Actions to think about for Drupal contrib

I maintain some Drupal contributed modules, and would always like to encourage more contributions from elsewhere in the community.

Here’s some of what I try to do (I’m not saying this is the best way):

• A live demonstration website so that potential users can try the functionality without needing to download and install the module.
• Quick initial responses to any issue (I aim for the same day), even if it is just a holding response on whether I agree or disagree with a proposed approach.
• A public roadmap, so that a developer has some ideas if they want to contribute but don’t know where to start.
• Well styled and commented (as judged by the Coder and Coder Tough Love modules) code, and a developer resources website containing the Doxygen output (via the API module).

If you are a contrib maintainer, what are you doing to make it easy for people to choose to contribute, and to “nudge” them into helping the whole project advance?

Do you think my list helps? What would you add / remove?

Category: WebsitesTags: Drupal PlanetnudgeMaintaining an Open Source ModuleOpen Sourceux