So what did 2009 look like for KDE PIM development? First off, commits and committers per day:
It is good to see that activity is generally sustained throughout the year. What is slightly odd (?) is there is an apparent downturn in the commits and committers towards the end of the year, starting in November. Perhaps this is too early a downturn to blame on Christmas and it is certainly strange given the approach of the KDE SC 4.4 release.
If we look at who committed, week-by-week, a reliance on certain individuals by KDE PIM is revealed:
Now, this particular visualization does not reveal too much, but certainly a couple of key issues. In addition to the reliance on key individuals (the visualization is sparse) there is also a significant number of contributors who only commit in one week. What is good to see is that there is a steady stream of new contributors throughout the year, even if they are not retained.
Recently Aaron Seigo blogged about the need to identify when a Free Software project was in trouble. One particular way in which a Free Software project might be in “trouble” is if it becomes too reliant on an individual contributor. Measuring how dependent a project is on an individual contributor is a complex task. However, it is possible to reduce this issue to a few metrics which we can measure and evaluate.
For example, if a contributor is responsible for many of a project’s commits it might be the case that the project is too dependent on that contributor. So I have devised a very basic approach to visualizing just such a dependence. The approach is simple:
- Create a graph in which nodes are svn accounts and edges show that those accounts have committed to the same artifact the edge weight is the number of unique artifacts shared by the accounts;
- Count the overall number of commits during a given period and count the number of commits made by each individual contributor;
- Color the nodes according the % of the overall commits that contributor has made… the redder the node, the greater the % of commits that node is responsible for.
- Layout the graph following the Kamada-Kawai algorithm, making the higher-weighted edges shorter.
The result of following this approach for KDE PIM in 2009 provides the following result:
So, we can see form this that there are a couple of KDE PIM contributors who are colored distinctly redder than others, indicating a higher dependence on them. KDE PIM is a suite of applications, if we go one level lower and look at an individual application (KMail in this case), we get something like this:
So in KMail we see a strong dependence on the project on a particular contributor. This might indicate this project is trouble. Certainly if that contributor were to be run over by a bus, the project will loose a significant source of momentum.
So this is only a start. Any suggestions as to how this approach might be improved are more than welcome.