Responsible module maintainership
by Larry Garfield
Recently, there was a minor flap about a security hole found in one of the modules that's part of the Drupal install running whitehouse.gov. The actual issue itself was rather uninteresting (if you give someone an "administer X" permission they can do evil things to your site; um, duh), and the only reason it attracted attention at all was sensationalist reporting by some online news sources, but it did bring up one interesting and important detail that many Drupal folks forget: You really shouldn't be using pre-release modules in production.
Of course, that becomes a problem given the number of Drupal modules that are in a pre-release state forever. Which is, of course, the underlying problem: Too many module maintainers are not being responsible maintainers.
Part of the problem with the whitehouse.gov site is that it was using the Context module, which at the time was standing at RC3 state. That's "release candidate, 3rd version", meaning "almost done but not really released yet". Drupal's security team, as a policy, doesn't handle security issues for modules until they have an actual stable release. That meant when someone noticed the issue and reported it to the security team, they did what they said they would do: It's a minor issue in a pre-release version of a module, let's handle it in the issue queue like anything else.
What's that? You didn't realize that the security team doesn't deal with pre-release modules? That's right, if you are using a pre-release module the security team won't deal with it. They're already over-worked enough as it is with the thousands of modules with stable releases. Security issues in such modules get directed to the issue queue and are not handled through the usual security announcement process. So it seems like the safe thing to do is to just not use modules that don't have a stable release, right, at least not for high-end sites?
Well, that would be the natural response, and it would be the responsible response. Unfortunately, Context is far from the only popular module to not have a stable release yet. In fact, having an RC puts it ahead of a lot of modules. Nearly every site that we've built with Drupal 6 has includes at least one module that is, technically, in pre-release state, even though we know it's perfectly stable and usable. I'd wager that if you looked at the modules page of any Drupal site built in the past year you'll probably also find at least one module still listed as pre-release despite it being release-quality in practice.
Beta, by definition, means "this is feature complete but may still have bugs, let's find 'em." "Release candidate", similarly, means "I think this is done and ready to release, but let's do a final check first". That's what Drupal core uses, as does the rest of the software industry (except Google, who uses "beta" as an excuse to not provide support). Yet how many Drupal modules violate those definitions or ignore them entirely, endangering their users? Sadly quite a few.
There are modules that have had ten "beta" releases with no significant new development in over a year, yet are so essential that they've been installed on hundreds of thousands of sites and have even been integrated into Drupal 7 core. Even though modules like these are clearly production-worthy, they get no security monitoring from the community because their maintainers haven't bothered to call any of the releases "stable".
On the other side of the coin, there's another module that was doing serious feature additions for most of the Drupal 6 life-cycle despite being in an RC state for most of it. That's right, active feature additions in an RC. None of which were getting any attention from the security team despite it being a module that leverages Drupal's security system. And it's not even the only one that did so.
There's even one rather high-profile module that hasn't had a stable release in over a year, despite continuous active development. That module's maintainer recently told me quite directly "Hey, my -dev releases are pretty stable. I'm not going to tag another release until I get around to porting to Drupal 7."
There are many more, too. All of these modules are, by definition, self-declared as not ready for production. People are ignoring the risks of pre-release modules because they have to. The "stable" modules don't provide that functionality because it's already provided. That makes using would-be "unstable" modules mandatory to get anything significant done with Drupal. How is keeping your production-ready code from getting proper security monitoring and training people to ignore the very good warnings about using pre-release code being a responsible maintainer? It isn't.
It's time for us to stop being irresponsible.
I'll own up to one such module myself, Views Cycle, which is currently at beta4. No, it's not "done". There will be more work done to it, both bug fixes and new feature additions. There may even be API changes in the future. There are systems in place for handling that, which people know to expect. But it is in a state where people can use it, and over 1500 people are using it. And treating them as cheap beta testers without security attention is irresponsible. So, consider this a pledge that the next version of Views Cycle will be a 1.0 stable release, and then continued development from there will be released 1.1, 1.2, and so forth, as it's supposed to be.
If you maintain a module that is still in pre-release state, and people are actually using it in production, do the responsible thing. Follow a standard, accepted release system. Follow the only release system that the security team supports. Don't try to hide behind "well Google does it". If you're going to release code to the community, support it responsibly.
This is our community, and our code. We should be responsible members of the community.