Blog Entries

December 2017
M T W T F S S
« May    
 123
45678910
11121314151617
18192021222324
25262728293031

Is Being Troubled Just ‘The Norm’?

In my previous post I showed off a new approach to detecting troubled projects based upon both developers and the artifacts they are responsible for.  As we saw in KMail, there was one contributor who was responsible for the majority of the commits, bu not the artifacts. Modularity in the community gave indication that the code is probably nicely modularised, too.

OK, so is KMail special or do we see this more often. Is trouble, normal? Since I was asked about KOffice, I have now repeated these visualisations for KWord.

So, KWord is strongly dependent upon one particular contributor for the commits. Don’t forget there could be many reasons for this (mostly process related), or it might be indicative of a project in trouble. If we look at the artifact modularisation…

… we see that while the community/artifacts appear to be nicely modularised, the principle contributor is not only making the most commits, but is also responsible for a sizable chunk of the codebase.

A project in trouble? Just as with KMail, who knows? Only the KWord community really knows.

Be Sociable, Share!

16 comments to Is Being Troubled Just ‘The Norm’?

  • Wouldn’t the contributor responsible for the ‘main’ function (i.e. initialising the various modules, windows, etc. ) be a ‘pinch-point’ ?

    • Paul Adams

      Quite possibly, but I currently do not investigate any deeper than the actual artifact level… So no evaluation of who is responsible for certain functions.

  • Diederik

    > A project in trouble? Just as with KMail, who knows? Only the KWord community really knows.

    So a lot of speculation, but what is the conclusion?

    • Paul Adams

      None so far. You are seeing this research unfurl as quickly as I am doing it… Not very.

      At this stage I am simply looking into projects reliant on one contributor as this is potentially indicative of “being in trouble”. How we can actually determine of a project is in trouble is a much longer-term issue and I am really only just beginning to scratch the surface.

  • Hello. Could you tell me what are you using to make these graphs? I have a project in GIT repository and I would like to create a graph for it.

    Thanks in advance!

    • Paul Adams

      I have my own set of tools which I use to parse SVN logs (soon to be made available as Free Software). These tools give me various types of output, one of which is DOT graph descriptions. I then simply use neato to layout the graphs and Image Magik to resize them to something sensible for inclusion in a blog.

  • Jos

    Can you explain what you plot and how you obtained the plots? Without explanation or method to reproduce the plots, I see no value in these pictures.

    • Paul Adams

      You need to go follow the link in this post to my earlier work. The earlier posts give a full explanation of what I am doing.

  • I love what you are doing…

    Love the ideas of the graphs once you release the code i can see other places where this could work nicely..

    I would like to see what is happening in Kopete, since i have just started working on it and the module im concentrating on to start with had missed out on some love and attention for a while.

    Working in a business which is all numbers, Production per day, Approvals, and other items, some reports show one thing but you must always take all numbers with a grain of salt.. Single reports with out the overall picture may be very deceiving..

    As you say that person may be committing lots, but it could be a New Language added, with 100 Commits..

    But these graphs allow the administrator to dig deeper into the product and see if there are problems or just normal part of a products live cycle.

    The biggest problem is finding someone to look at this type of stuff then finding a new person..

    I joined only really because my wife on windows kept saying does yours do this.. I never worried about kopete futher than the basic function of send and receive txt.. Her niggling made me get off my butt to actually help out and make the product what it should be..

    • Paul Adams

      I’m glad you like my work…

      You are absolutely right in that these only make complete sense in the right hands. Deep understanding of the project being studied is required. The same applies for any metric-based assessment of software development… or anything for that matter! :)

  • The developer turnover graph on http://svnsearch.org/svnsearch/repos/KDE/search?path=trunk%2Fkoffice is cool as well — it shows that there is quite a lot of continuity in koffice as a whole.

  • Tom

    Hi,

    FWIW: I also mailed a patch to the koffice mailing list. Yes it got added, by zander, so indeed he committed it, but it was not really his patch. Of course there is no way of knowing what is actually his work and what he committed(maybe after cleaning up) that is actually work of other people. So I wouldn’t really worry?

  • The previous post had a quickly done image of all of koffice, this one of just the kword subdir. I think the balance lies a bit more in between.
    The kword dir is a bit like looking at konqueror commits and forgetting about the khtml commits. KWord itself is 17KLoc, and is essentially just the canvas. Not even text editing is done in there. So, yes, this is largely a one man affair. And thats probably not too big a deal as its not that much code.
    Your splitting of KOffice has to be done with a bit more finesse to get numbers that don’t confuse. For instance there is the koffice/plugins/textshape which has almost 13KLoc (see, almost the same size as the kword dir :) and then there is libs/kotext and libs/flake which are pretty important too. Then plugins/variables, plugins/paragraphtool and plugins/textediting are almost-core-projects. Maybe you can combine those dirs and call it ‘kword’ and re-do the graph :)

    I’m hoping it doesn’t look like such a project in trouble anymore then.