Blog Entries

October 2014
M T W T F S S
« May    
 12345
6789101112
13141516171819
20212223242526
2728293031  

KDE PIM 2009 Overview

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.

Be Sociable, Share!

6 comments to KDE PIM 2009 Overview

  • Markus

    Correct me if I’m wrong, but as I understand it, KMail’s current code base is kinda messy and that it needs to be re-engineered to be easier (a task for the Akonadi port).
    So in order to make contributions from newcomers easier, people with experience with working with the code, need to simplify it first.

    That said: Even after achieving easier maintainability, it’s not surprising that people who are paid to work fulltime on KMail have the highest commit count.

    • Paul Adams

      I will not make any comment on the quality of the KMail codebase…

      The focus of my blog post was to see how we could measure the reliance of a project on an individual; a current contributor. This does not relate in any way to how easy or not it is for new contributors to join. You are correct, of course, in identifying this as being something that it long-term important for the success of a project.

      Your point about the impact of the business world in a projects, for me, raises an interesting question… “Is the business responsible (in some way) for securing the survival of a project if a key contributor that they employ to work on the project is run over by a bus?” In this particular issue, however, you are wrong; the identified individual is not employed full-time to work on KMail.

  • Volker Krause

    Very interesting data, as usual :)
    What parts of the code exactly did you measure? I assume trunk/KDE/kdepim? For the full picture you’d probably need to include kdepimlibs as well as the enterprise3, enterprise4 and akonadi-ports branches. There is active development going on in all those and especially akonadi-ports might explain the down-turn end of the year you mentioned (trunk was frozen there for new development and entirely moved to the branch instead).

    • Paul Adams

      Yes, this was just /trunk/KDE/kdepim. I will aggregate the data from the various sources and blog again at a later time. Additionally I might plot the activity of each branch on the same time-line to see how they compare.

  • Morris

    No! tmcguire, be very careful!!

  • Which exact tools did you use to create the graphics here? Are they available?