[Live-demo] How to identify OSGeo projects that should be retired

Cameron Shorter cameron.shorter at gmail.com
Fri Mar 22 15:07:48 PDT 2013

On 23/03/2013 6:30 AM, Seven (aka Arnulf) wrote:
> PS:
> I keep revisiting the need to revisit our projects after some time but
> am not going to bring it up again except in post scripta like this one.

Noting that OSGeo and OSGeo-Live can be considered a "Badge of Quality" 
and "Level of Endorsement" I agree with Arnulf that in order to retain 
that reputation for quality that we need to periodically monitor our 
OSGeo projects and ensure that they are continuing to progress as 
healthy projects.
I'd go as far as to argue that our successful projects are increasing in 
quality over time, and as such, our "quality requirements" from OSGeo 
projects should increase as well.
But for the moment, I'll focus this discussion on periodic monitoring of 
project health.

We are fortunate enough to have an established periodic process which 
evaluates some aspects of project health through the OSGeo-Live project. 
I'd suggest that the OSGeo-Live build process could be extended slightly 
to add some checks to evaluate project health, which in turn might 
result in legacy projects being retired.

The primary area I think we should be looking out for is that project 
becomes obsolete, usually due to another project stealing market share. 
So how do we recognise such a project, and then suggest that they 
de-register as an OSGeo project?

Typically a project which is becoming obsolete will:
1. Start loosing its community and sponsors
2. Then start loosing its developers
3. This is recognisable by a reduction in traffic on email lists, 
reduced code commits, reduced releases of the software, reduced 
commitment from projects to keep the software and documentation 
maintained on OSGeo-Live releases.

Note that reduced software releases can also be attributed to 
established projects which have fully reached their potential and don't 
require any more work.

Ohloh provides metrics about Open Source projects, and I've started 
aggregating details I could find into:

Also, we can determine which projects have been putting out new releases 
from our OSGeo-Live package status sheet:

We are already verifying that projects are updated to work with the 
latest Ubuntu.

So I suggest that OSGeo and OSGeo-Live incubation criteria be updated to 
include a requirement to configure Ohloh for each project.

And then during each OSGeo-Live release, we should question projects 
which have not put out a release for the last year if they still have a 
community behind them, and maybe whether it would be appropriate to 
retire the project from OSGeo or OSGeo-Live.

Cameron Shorter
Geospatial Solutions Manager
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Geospatial Solutions enhanced with Open Standards and Open Source

More information about the Osgeolive mailing list