[Incubator] New Application: GeoToolkit

[Howard Butler]

On May 22, 2009, at 6:36 PM, Cameron Shorter wrote:

> Geotools as a project has already graduated to be a full OSGeo  
> project.
>
> I'm disappointed to see Geotools fork. While I think I understand  
> the reasons behind it, I see a split as a sign of a fragmented  
> community, which is the opposite of the strong community criteria we  
> put on graduating projects.

Geotoolkit (a poor, generic, and confusing name, especially within the  
context of the Geotools name, but maybe that is by design) doesn't  
seem to share the ideals of the Incubation committee, and one of the  
major reasons for the fork was the rejection of the OSGeo-prescribed  
governance model (PSC).  http://www.geotoolkit.org/history.html  
states, "Geotoolkit has returned to the old governance model ..."

<http://n2.nabble.com/Geotoolkit-announcement-td2727370.html> states  
"The governance model for Geotoolkit has not yet been finalized but it  
will aim to separate out the community management aspects of  
governance from the technical decisions. "  This is a false  
separation.  The major reason for governance is so the community is  
able to bootstrap itself into power to participate in controlling its  
own destiny .  If you don't want to argue, you can change to a  
dictator or benevolent dictator governance model, but it is  
incompatible with the governance model that OSGeo supports, and the  
incubation committee should not ratify it. Is this what Geotoolkit  
wants for governance, benevolent (or ruthless ;) dictator?

Forks are not necessarily a bad thing.  In fact, they're one of the  
reasons OSS is great.  If I don't like what you're doing or how you're  
doing it, both you and I can take the same ball and go play elsewhere.  
There's been some good examples of strong and healthy forks --  
Firefox, X.org, etc -- but most of the time, forks don't carry enough  
momentum to eclipse the project they're forking from.    We the  
incubation committee should wait and see where Geotoolkit goes in  
relation to Geotools.  Their niches currently overlap a lot and they  
are fighting for the same user base.  That might change, but if it  
doesn't, I doubt there is enough audience to support both in a model  
that the incubation committee would be able to graduate.

>
> It also waters down OSGeo's branding to have 2 projects offering the  
> same or very similar functionality.
> One of the strengths of OSGeo is that the OSGeo brand helps sponsors  
> and integrators select the quality OSGeo projects over others. The  
> more projects we support (which do the same thing), the less the  
> value to the remaining projects.

MapServer vs. MapGuide.  GDAL vs GeoTools vs FDO.  gvSIG vs QGIS/ 
GRASS.  We already have plenty of overlapping functionality within  
OSGeo.  I don't think this is a reason for concern.  That boat has  
already sailed long ago.  If overlapping functionality was a criteria,  
OSGeo would have had its one and only founding project in it --  
MapServ^H^H^H^HGuide :) OSGeo's incubation branding is really about  
how the software is developed and that the source code is clean.  That  
is what most of our incubation documentation, governance  
prescriptions, and process is about.  The questions we ask are:
- is it a big enough project?
- is more than one organization footing its development?
- does it demonstrate wide integration with other softwares in the  
ecosystem?
...


>
>
> That said, I don't think that Geotoolkit should be locked out of the  
> graduation process because of the fragmentation, it just makes the  
> criteria to pass graduation harder. Of note, Adrian Custer, from the  
> Geotoolkit branch was a major force completing the Geotools  
> graduation, and knows all too well about the effort involved in the  
> graduation process.
>

I do not think Geotoolkit has demonstrated it meets the incubation  
committee's criteria for entering incubation yet, and I think we  
should table its acceptance until it matures as a project.    The only  
constraint I would suggest is once Geotoolkit does mature, the mentor  
for incubation should be someone who doesn't really interact with  
Geotools to eliminate any conflict of interest.