In the last few days, just before GUADEC, have appeared a very replied post about GNOME Decadence. Trying to provide a guide about life cycle of a project I've thought about the year that the software is mainly written could be good for taking into account its status.

I've written a quick and dirty script that gets the LOCs written by year and I've obtained that mark for XSP project from Mono repository.

In the output for XSP we can take account that the software grow very fast from 2002 to 2005, having in 20003 the top number of changed lines in this period. It seems that in 2006 the software was mature enough to get off the focus on it and the changes decreased a lot. Later, in 2007, there were a lot of changes and it's an strange situation because the number of changed lines in this year was near the sum of the number of changed lines of the other years... If in 2008 the number of changed lines continued growing, we could talk about the "rebirth" of the project but it isn't, the number of changed lines could be around the same value that in 2006.

This analysis determines that either XSP is mature enough to get changed a lot or is in "decadence" (without new features). Well, we should know that XSP is the implementation of a web server interface for System.Web and there aren't many fields to improve or innovate.

It could be great to see numbers of this kind for other software projects. I'll get some more in a couple of days.

Here is the script I've used:

#!/bin/sh
LISTINGFILE="/tmp/listingfile.out"
TEMPFILE="/tmp/tempfile.out"
URL="svn+ssh://pedro@mono-cvs.ximian.com/source/trunk/xsp"
for file in $(svn list -R $URL); do
svn blame -v $URL/$file
done > $LISTINGFILE
cat $LISTINGFILE | sed "s/^ *//g" | sed "s/ */ /g" | cut -f 3 -d " " | cut -f 1 -d "-" | sort > $TEMPFILE
for i in $(cat $TEMPFILE | uniq); do echo -n "$i: "; grep $i $TEMPFILE | wc -l; done

Output
2002: 2481
2003: 4691
2004: 3560
2005: 3701
2006: 657
2007: 13881
2008: 137

I know that "LISTINGFILE" is not needed but I've included it because the "for" instruction with "svn blame..." is very slow and goes through the entire repository, it's good to have a "cache". Maybe TEMPFILE can be taken out but, as I said, it's a quick and dirty script.