contributions

Last week was the amazing Do It With Drupal conference and Angela Byron wanted some updated contributor statistics for her presentation. So, I analyzed the commit messages for Drupal core to find who has been helping out and once again the process and the data are getting better and better.

This time I'm using direct database information from the cvs commit log tables and using PHP to parse it which means that it's easier to create rules for fixing usernames or eliminating bad data. I also pulled in company information from groups.drupal.org to get a rough sense of which companies, as a group, are contributing the most to Drupal core. AND, thanks to Dreditor the commit messages are getting cleaner and include information about the person who has done reviews on patches.

Remember, none of this data is really perfectly accurate, but it gives us a tangible sense of what is going on.

Attached are a CSV file and an OpenOffice.org spreadsheet with the data. They show the uid of the user from groups.drupal.org, their name, their organization (if they specified one), the number of times they were mentioned as an author of a patch, the number of times they were mentioned as a reviewer of a patch, and the commit ID where they were mentioned. The commit ID is useful when chasing down bad data so that I can improve the parser. So, if you find a problem please let me know the CID value so I can improve the parser. There's a chance that this could eventually make it onto drupal.org itself, but I'd like to improve the process first to understand whether or not that makes sense.

Enough with the process - it's time to name names!

Top 10 patch contributors to Drupal 7 core

Drupal core is very secure by default, but you can unknowingly open vulnerabilities with insecure configuration. An example of this is how allowing anonymous, untrusted users to use any HTML tag in comments opens a cross-site scripting attack vector on your site.

I'd like to introduce the Security Review module for automatically checking for the existence of insecure configuration and maintaining a secure Drupal site. With the first release come the following checks:

• Insecure file system permissions
• Insecure input formats
• Dangerous code in nodes and comments
• Printed errors
• Private files directory not set outside the web root
• Dangerous allowed upload extensions
• Permissions granted to untrusted roles

Security Review also looks for the common attacks of SQL injection/system probing and brute-force login attempts.

The module reports the result of its checks as pass or fail and provides details on an accompanying page. Checks may not be 100% accurate on every system so they can be skipped from being run. I often skip the error reporting check while on a development instance of my site. The checks are explained in detail and where applicable there are links to online documentation.

Future plans for the module include popular contrib module checks and notification support. I encourage you to give the module a run on your sites and let me know what you think in the comments!

The code freeze for Drupal 7.x is looming large on the horizon. From that point on we will be limited in what kinds of changes we can get into Drupal core. For some the code freeze is a time of relief: it means we are down to bug fixes and the final release should be coming soon. For others it is a hard time - bug fixing isn't always as fun as adding new features.

So, as we head into feature freeze it seemed like a good time to run some statistics on who has been contributing the most to Drupal 7.x so far.

Contributors to Drupal 7.x. Through August 10th

Following on from previous times that I've run these stats, I've published documentation of the process to get the data on groups.drupal.org. This time I went straight to the commit messages stored in database tables on drupal.org This has the benefit of counting new files as well as old files (the last times I did this it only counted changes to existing files).

So, who are the top 10 people based on the number of times their name is in a commit message?

The total number of mentions is 3133, so those top 10 are responsible for roughly 33% of the code. On the flip side, people with 3 or fewer mentions are responsible for roughly 15% of the code. We still have a long tail of 222 people who are mentioned in only one message. We see a fairly typical "long tail" distribution: the people who are most involved do a lot of the work, but the people who only get mentioned a few times each are still responsible for a large number of commits when aggregated together.