How to track which programmers contribute to a project
I’ve worked on projects with 8 or 9 programmers and the managers running the project had no idea which programmers were contributing what. I have often been surprised that some managers are willing to fly in the dark, regarding who is doing what. These tend to be managers with weak technical backgrounds, so perhaps they are unable to analyze the work at the appropriate level.
This analysis of who contributes to Linux seems full of information that managers would want to track about any project:
Beyond that, how one generates statistics from a patch stream is an
interesting question. How does one measure the productivity of
programmers? One possibility is to look at the number of changesets
merged. By that metric, this is the list of the most prolific contributors
to 2.6.20:
Developers with the most changesets Al Viro 241 4.8% Andrew Morton 92 1.8% Jiri Slaby 92 1.8% Adrian Bunk 87 1.7% Gerrit Renker 79 1.6% Josef Sipek 79 1.6% Avi Kivity 68 1.4% Tejun Heo 67 1.3% Patrick McHardy 63 1.3% Ralf Baechle 61 1.2% Randy Dunlap 59 1.2% Alan Cox 58 1.2% Mariusz Kozlowski 57 1.1% Andrew Victor 53 1.1% Paul Mundt 52 1.0% Stefan Richter 49 1.0% David S. Miller 48 1.0% Russell King 44 0.9% Benjamin Herrenschmidt 44 0.9% Akinobu Mita 43 0.9% Looking at patch counts rewards developers who put in large numbers of
small patches. Al Viro’s patches include a vast number of code annotations
(to enable better checking with sparse), include file fixups,
etc. Many of the changes are small – many do not affect the resulting
kernel executable at all – but there are a lot of them. Even so, as the
biggest contributor, Al generated less than 5% of the
total changesets added to the kernel. The top 20 contributors, all
together, generated 28% of the total changesets in 2.6.20.One could make the argument that a better way to look at the problem is by
the number of lines affected by a patch. In this way, a contributor’s
portion of the whole will not depend on whether it has been split into a
long series of small patches or not. On the other hand, simply renaming a
file can make it look like a developer has touched a large amount of code.
Be that as it may, by looking at lines changed (defined
as the greater of the number of lines added or removed by each individual
changeset), one gets a table like this:
Developers with the most changed lines Jeff Garzik 20712 6.0% Patrick McHardy 15024 4.3% Jiri Slaby 13917 4.0% Avi Kivity 11726 3.4% Andrew Victor 9710 2.8% Amit S. Kale 9537 2.7% Stephen Hemminger 9120 2.6% Geoff Levand 8396 2.4% Michael Chan 8307 2.4% Chris Zankel 8099 2.3% Mauro Carvalho Chehab 7390 2.1% Adrian Bunk 6138 1.8% Yoshinori Sato 5232 1.5% Al Viro 4981 1.4% Benjamin Herrenschmidt 4588 1.3% Thierry MERLE 4549 1.3% Dan Williams 4516 1.3% Jonathan Corbet 3924 1.1% Gerrit Renker 3857 1.1% Jiri Kosina 3805 1.1%