When a popular Drupal module is not maintained properly, it creates all kinds of problems: people can't upgrade their websites, they have to backport security fixes, etc. As a result, the Drupal community has a strong desire to make sure that important modules are always stable and up-to-date. In practice, however, this isn't always the case. Sometimes, important modules are slow to be upgraded, or have stopped being maintained altogether.

It is remarkable how many people think Drupal will never quite manage to realize its full potential unless we make sure that important modules continue to work. I don't necessarily share this belief. However, if some people think that this part of the Drupal development model is broken, we have to try and fix it.

Now, some people demand that we force developers to help fix and upgrade the most important modules in a timely manner. That is, of course, fundamentally flawed ...

You need to realize that if you created a Drupal module that thousands of people depend upon, you created a successful Open Source project. Successful Open Source projects need responsible maintainers in order to sustain. As the maintainer of your project you are in charge, and you have to take responsibility. Period.

We can't force volunteer developers with no particular interest in your module to help you maintain it, nor can we hold them to deadlines. Open Source is all about letting people scratch their your own itch and having good ol' fun. Clearly, there is no fun in being told to upgrade someone else's code by a specified time. Plus, assigning more programmers to a project running behind schedule will make it even later (The Mythical Man-Month).

This is an organizational problem. We can't solve it with a technical solution. So what to do instead?

Well, we have to accept and acknowledge the fact that a project the size of Drupal is always going to be a bit broken, and that command and control won't cultivate the Drupal wilderness. Drupal got built by people who chose to build it, not by people who were forced to. Rather than forcing people to do something, we need a culture that uses peer pressure to encourage responsible maintainership.

For starters, an important Drupal project should not depend on a single person, especially if that person is a busy one. If you are the author of a successful project, you have to delegate responsibility and provide leadership and structure for others to help you. Avoid being a bottleneck. Avoid being a single point of failure.

In order to make your project sustain, you have to make sure that it scales and that you build a team of passionate users and developers. You have to find, motivate, guide, and empower people to take on a role within your project. You have to help others help you.

Anything else is a failure of leadership. It doesn't mean that you are a bad person or that you lack leadership skills -- it might simply be the case that you are too busy or that you have no particular desire to support your project's growth -- but it is a failure of leadership nonetheless.

As a community, we have to make sure that we have the right people at the right place. The people who maintain popular Drupal modules should invest enough time and energy in these projects, and they have to make sure that there is enough programmer effort available to help fix and upgrade these modules in a timely manner.

And me? All I can do is help create the right environment by providing the tools required to build a successful community around your Drupal project, by providing enough time to upgrade your modules and by cultivating the right culture. What I absolutely must do, is debunk the myth that forcing hordes of volunteer developers to rescue you will provide a sustainable solution.


metzlerd (not verified):

I share this opinion. I would agree that the Drupal development process is not broken. Far from it. This is one of the better processes out there.

As a newer member, the Drupal development philosphy is still pretty fresh in my brain. I think its right to point out that some of the ways in which the development process is "less than perfect" are done so intentionally as a trade-off to provide an agile, innovative environment. Here's to more of the same!

(Am I evangelizing enough yet? :) )

ChrisKennedy (not verified):

I agree, and I will highlight two information issues with technical solutions: one for Drupal users and one for Drupal contributors. I believe both will be aided drastically by the excellent "project health" feature proposal (#79550) for Project.module, with the solution being the calculation and display of various quality metrics (woo performance measurement) as you/webchick/et al. have suggested.

Drupal Users - it is difficult for Drupal users to evaluate the responsibility level of the maintainer (or project health), especially for non-technical users. Showing the number of "active" maintainers, commits per month, recently fixed vs. open bugs in a small table will help significantly. SourceForge is a good comparison with their display of project activity as a simple percentage. But ultimately users should be able to avoid modules with "irresponsible" maintainers, which will mitigate the problem. Project ratings (#77976) will also help.

Drupal Contributors - it is difficult for Drupal contributors to gauge the popularity of their project and the extent to which their responsibleness will impact the Drupal community ("You need to realize that if you created a Drupal module that thousands of people depend upon..." - how would you know?). Currently they can estimate it via submission of issues from users, personal emails, etc. but this is not ideal. Showing number of downloads and the number of installations (via drupal.module) will clearly help, as will a display of module-wide dependencies (via the .meta files - #76549). Adding a "project subscribers" feature (ala Organic Groups, etc.) would show the number of users actively interested in releases.

More General Areas

There are other areas to improve and management literature (esp. nonprofit and volunteer, imo) can be informative (Ellis - "From the Top Down", etc.). Many, if not all, have already been pointed out.

  • Training - API and handbook documentation (up to date!), mentoring & development support, conferences & workshops, vod/podcasts, volunteer management training for drupal leadership, API stabilization
  • Rewards - thank-yous, awards banquets (webified as appropriate), media coverage (including internal media), job references and letters of recommendation, academic credit, stipends, social events
  • Funding (a dependency for other solutions) - paid & dedicated development director, grant writing, corporate sponsorships, microdonations, capital campaigns, board of directors, bounties system for drupal.org, patch to project-issues that allows specification of a monetary value to an issue (from the developer and/or the reporter)
  • Management - dedicated (and ideally paid) volunteer manager, volunteer management training, volunteer tracking
  • Recruitment - Project support for "orphaned" module flag, Project support for "need maintainers" module flag, automatic orphaning of inactive modules with bugs open X months and no commits in X months, recruitment drives (with specific goals), referral tracking for recruiters, targeted recruitment
  • Retention - sabatticals, assignment rotation, individual feedback on quality, surveys/focus groups/interviews

Clearly there are a variety of technical and non-technical areas for improvement for Drupal, and responsibility goes to individual maintainers, Drupal leadership, and the community at large. Many of these topics are potential case-study projects for undergraduate and graduate students in management, nonprofits, marketing, fundraising, engineering, computer sciences, and other areas.

Overall, if maintainer responsibility is deemed an important issue then a strategy for improvement must be formulated, implemented, and evaluated over time. In fact, it may be best for the Drupal project to shift some amount of leadership attention from technical issues to non-technical issues, though I have no idea if this would be optimal.

Of course, "to suggest is to volunteer," and I will try to improve and increase my own contributions to Drupal, which have only recently begun.

bohemicus (not verified):

As someone who is a user of Drupal rather than an active developer, I agree completely with your thoughts on project management in general. What you say is true for most contributed modules including such stars as Views. But there are certain modules without which Drupal functionality would be very incomplete (I could hardly imagine offering it to my users without TinyMCE). It might be worth considering another layer of essential modules which would be always upgraded with each new version of core (image and links management come to mind). That way it would be easier to evict certain modules from core (poll and aggregator are great but somewhat random compared to some modules that are not in core).

Another important point made in the discussion here is the stability of the API. I think the cutting edge philosophy adopted by Drupal has helped make it what it is now but as the popularity of Drupal rightly increases it might be worth considering some reasonable level of backward compatibility and/or upgrade paths. (Here I am reminded of the difference between Apple and Microsoft. Apple offers some backward compatibility it will cut users off in the face of major inovations while Microsoft has tied itself in knots to allow you to run Windows 3.1 apps in XP and this resulted in an inferior product.) This is on my mind a lot now that I'm considering making a web app I had made into a Drupal module.

ChrisKennedy (not verified):

Exactly, API changes are very rapid in Drupal and force module contributors to incur significant maintenance costs if they want to stay "responsible" and update their modules for future releases. From what I have seen there appears to be a conscious effort to provide little backwards compatibility to past APIs, which is why being a maintainer can consist primarily of API updates rather than active development. If Drupal wants to forge ahead and ignore backwards compatibility it can innovate more rapidly, but don't be surprised about volunteer maintainers not sticking to the schedule.

For the observers out there, an extensive thread discussing this and other related topics can be found here.


We always made sure that responsible maintainers had time to upgrade their modules.

The Drupal 4.7 code freeze lasted 9 months. Road bumps aside, maintainers had plenty of time to upgrade their modules to Drupal 4.7.

What happened is that many maintainers were too busy with consulting/client work, and it turned out that they didn't had anyone to help them ...

The current release cycle will have a 3 month development period, followed by a code freeze of at least 2 months (and longer if necessary).

Upgrading from Drupal 4.6 to Drupal 4.7 was a monstrous task because all of the form handling code had to be rewritten. Saying that this was an API change is somewhat of an understatement: the changes forced many developers to rewrite their modules from scratch.

Bill Grant (not verified):

I think one thing that's made it somewhat hard (based on my minimal experience developing modules) for developers to keep up is some of the lack of backward compatibility. Why is it that most modules need to follow manual steps to remain compliant? It seems to me if there were ways to maintain prior release modules, then older modules would still work in newer releases of the core. Perhaps one way to do that would be to have modules specifically for backward compatability mode. So if you are going to take a method out of core in version 4.7, put that method in a separate module called compat_4_7.module...

Curious what others thoughts are on this...

Nancy Wichmann (not verified):

Life changes are an important part of thos equation as well. I used to have plenty of time to maintain all my modules. After my mother's death and having to re-establish myself financially, I find that my time is greatly diminished.

It's not that I don't want to be a "responsible maintainer." There seem to be few, if any, others who are willing (and qualified) to step up and help out with my modules.

If it were possible, I'd prefer to be a full-time maintainer. However, the reality is that life takes money and maintaining these modules makes me no money. Perhaps the DA can look into ways to help in this regard.

Anonymous (not verified):

Yeah well I have to say my only regret with Drupal so far is that many modules maintainers are "maintaining" a huge number of modules, they don't even have the time to answer patches. I'll stay anonymous as this is not meant to point to those people, but rather suggest there's maybe an issue here... The modules maintaining race ? Sorry for the rant, maybe it's because of the summer too.