Recent Blog Posts

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

There seems to be a new pattern emerging in Drupal and I want to let you know that the Token module has joined the bandwagon with a "Token Starter Kit"

History of the Starter Kit in Drupal: Zen Theming

When the Zen project started it's goal was to be a really solid base HTML theme with tons of comments in the templates so that a new themer could take it, modify it, and end up with a great theme. Unfortunately, that second step of modifying it meant that people ran into all sorts of support issues that were hard to debug and they were in trouble when a new version of Zen came out - they weren't really running Zen any more.

How to use the Token Starter Kit

The Token Starter Kit is meant to be similarly easy for folks to use. The idea is that if you just open up the token module itself and start adding tokens then you are "hacking a contrib" (modifying it) and you will have to remember to make those changes again when you upgrade. Bad news. It's also not particularly simple to understand how the module works (it's got includes, and hooks, oh my!).

Enter the tokenSTARTER module. Just copy the tokenSTARTER .info and .module files to a new directory in your modules directory, rename them, and rename all the functions inside to match the filenames. This gives you a clean place to start adding in your own tokens. So, go for it. You'll see that it's quite simple and all you need are two hooks.

Documentation on Token API

There's also an API.txt file and README.txt file which explain how to write tokens in general. Lots of great advice in there.

I just attended a very interesting session at Drupalcon Paris called Paying for the plumbing. It's a panel involving Allie Micka (Advantage Labs), Angie Byron (Lullabot), Karen Stevenson (Lullabot and recently a freelancer), Tiffany Farriss (Palantir relatively new to Drupal but a long lived company), Eric Gunderson (Development Seed).

Some choice quotes on coordination and business of open source

After some introductions and Allie saying that she didn't want to hear the same old tired platitudes (which was a brilliant start to the session) we got into some discussion with the panel and the audience. Here are a few quotes and paraphrases of what people had to say.

Tiffany Farriss of Palantir gave the perspective that we should

Budget in 10% to every project for "patching."

I assume "patching" means communicating with the module maintainer and re-rolling the patch and making it awesome.

Which is a decent point, we do need to kind of just do this as part of our normal business, but that doesn't pay for the big things nor the "plumbing" but just for incremental improvements.

Further, Tiffany said:

Require all your code to be GPL and tell clients you're going to release it and announce it as best you can.

Which is a great point. Drupal.org requires all code hosted there to be licensed GPL Version 2 and later and if your client claims it isn't then there can be big problems for all involved.

Benjamin from Agaric Design Collective said:

We need better coordination tools.

Which is pretty true, and we have a decent tool at Projects Needing Financing. This points out what I think is the real problem of the whole collaboration idea: coordination.

The only way coordination on a feature works for us is when 2 of our customers want the same thing and we do all the work.

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.