Removing Arbitrary Barriers to Participation

It is time for the Drupal community to catch up the rest of the open source world and drop the module review process from

I woke up this morning to see this series of tweets from Steve Burge.

Drupal Review ProcessWhat prevented me from falling back to sleep at 6am when I read this comment was not Steve, who resigned himself to biting the bullet and following the process, but the dozens, hundreds, who knows thousands of people who immediately gave up faced with this daunting process.

The message we are sending to new contributors who want to give away their hard earned contributions is that our review process, our existing modules, and our coding standards are more valuable than their hard work.

You can get reviewed and approved to sell your module or theme in a paid marketplace like Codecanyon far more quickly than you can be approved to give it away on will often perform its initial manual reviews within 24 hours of a plugin being submitted.

There have been some great incremental improvements at automating the initial reviews, and getting reviewees to help review each other, but it still takes months for people who follow every line of the process to get approved, no matter who reviews their code. I really don't want to diminish the amount of passion thought and genuine hard work Klausi and others have put into this process, but I'd love to free them up to focus on other parts of Drupal. I spent an hour and a half reading through the 186 comment on That proposal does not go far enough. It is time for drastic changes not more glacial improvements.

By looking at the example set by NPM, Composer, and other modern open source plugin repositories it should be evident that we have very little to fear in opening up our process. The only barrier these systems pose to making code contributions widely available is a confirmed e-mail address. History has shown that they have suffered very little damage to their reputation as a result of the quality of the code or security vulnerabilities that get published as a result.

Code Quality

Everyone who builds Drupal sites for a living has seen horrible code quality and experienced critical production bugs from both highly popular as well as fringe contributed modules with very few users. Having built Drupal sites since Drupal 4.7 when almost no restrictions were in place to posting contrib code, I have not noticed any significant change to the frequency and severity of these types of issues. Very few contrib modules have test suites which would be the only real solution to help solving recursions and tests are not a required part of the current review process. Github has proven that in a fully open system the best contributions will still float to the top with nothing more than a star, the number of forks and Google's relevancy algorithms as your guide. Wordpress can provide speedy reviews by only focusing its efforts on issues related to privacy, security, and spam and not getting into the losing game of trying to define what "good code" is.


The Drupal security team will only respond to issues in a module with a published full release. If there is any time for code to receive a security review it should be at the time a module release is published, and this same standard should apply to all projects on not just new contributions from eager newcomers. The security team is doing very little, if any, active searching for security issues. They rely on the wider community to find and share those issues with them through the proper channels.  Its possible opening the floodgates would increase the number of published security releases, but we shouldn't let this potential public relations problem stop us. The number of vulnerabilities will stay exactly the same, the only thing that will change is the number of exposed vulnerabilities that would have otherwise sat undetected in a hosted sandbox. If good security reviews is the main concern behind dropping the approval process, then security should become the only aspect we review new contributions for.


Sandboxes are an arbitrary division that marks some code as 'ready for public consumption' and other code as not. This distinction can be very useful when authors don't have any intention of making their project production-ready, but the decision of when to make this transition should be the authors alone. Right now we assume all contributions outside of the vetted maintainers are suspect and all contributions from vetted maintainers are good. We should deal with spam and abuse after it happens instead of treating every new contributor like a suspected abuser.


If anything the fork ecosystem of Github has proven that duplication is extremely healthy for open source code. People will collaborate if they think a piece of software is good, and they will start over if they think it isn't. Grunt was a hugely popular project solving a real need for frontend developers. Gulp was a rewrite that essentially solved the same problems, and has now become the de-facto standard.

Lets join the rest of the open source world and open the floodgates to contributions from anybody and everybody. I think we will be pleasantly surprised with the results.