[Incubator] New Application: GeoToolkit
hobu.inc at gmail.com
Fri May 22 22:07:15 EDT 2009
On May 22, 2009, at 6:36 PM, Cameron Shorter wrote:
> Geotools as a project has already graduated to be a full OSGeo
> 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 ..."
"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
> 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.
More information about the Incubator