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

[Brian Hamlin]

Hi All-

   Hamish Bowman pointed out that there is a difference in project  
content
Some science-oriented code for example, may get quite old yet be very  
much worth preserving
On the other hand, I agree that projects ought to be "aged out" over  
time
So it may take some human editing decisions, with written guidelines  
put in place in case of conflicts

best regards from Berkeley, California
Brian M Hamlin
OSGeo California Chapter
415-717-4462 cell


On Mar 22, 2013, at 3:07 PM, Cameron Shorter wrote:

> 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:
> http://adhoc.osgeo.osuosl.org/livedvd/docs/en/metrics.html
>
> Also, we can determine which projects have been putting out new  
> releases from our OSGeo-Live package status sheet:
> https://docs.google.com/spreadsheet/ccc? 
> key=0Al9zh8DjmU_RdGIzd0VLLTBpQVJuNVlHMlBWSDhKLXc#gid=13
>
> 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
> http://www.lisasoft.com
>
> _______________________________________________
> Live-demo mailing list
> Live-demo at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/live-demo
> http://live.osgeo.org
> http://wiki.osgeo.org/wiki/Live_GIS_Disc
>