[Incubator] New Application: GeoToolkit
dmorissette at mapgears.com
Sun May 24 12:46:22 EDT 2009
[Forwarding Vincent's reply since he doesn't seem to be on the list]
-------- Original Message --------
Subject: Re: [Incubator] New Application: GeoToolkit
Date: Sat, 23 May 2009 11:22:34 +0200
From: Vincent Heurteaux <vincent.heurteaux at geomatys.fr>
To: Jody Garnett <jody.garnett at gmail.com>
CC: Daniel Morissette <dmorissette at mapgears.com>, OSGeo-incubator
<Incubator at lists.osgeo.org>, Martin Desruisseaux
<martin.desruisseaux at geomatys.fr>, Adrian Custer <adrian.custer at geomatys.fr>
> I am going to put out a formal post up shortly. We had ask Martin to
> step down last month which was very dissappointing. After his
> contributions over the years we thought it good to allow him to step
> down gracefully.
Martin wanted to step down weeks before your proposal Jody. In fact I
strongly sustect you to make him this proposal after beeing informed
about the Geotoolkit initiative (I saw a lot of interesting connexions
on geotoolkit, days before your proposal ;-) )
> Larger picture we have had a bit of trouble working with his current
> company. We have development procedures to keep the project running in
> an even handed way; and it simply was not working out in this case.
We've got the same concerns with some company working around Geotools
In my opinion, Geotools is no more an independant toolkit, it's
release process is guided by Geoserver release process, does it mean
every new project that want to use Geotools need to follow Geoserver
What we've experienced is that if you're trying to push technical
solutions that doesn't fit with Geoserver needs, there are no chances
to make it appear on Geotols. JaxB was a good example, because its
integration approach (annotations) in Geotools was not forcing other
project to take care of it at all. Geoserver people were complaynig
about it because in a particular case (in eclipse if my memory serves
me) there was a bug that was disturbing Geoserver compilation process
(I'm not competent o explain you why, but Martin or Justin could give
you more details). But it was a bug somewhere but not on the JaxB side.
> A couple specific things that got me:
> - strategic decisions that should be made as a community were being
> made behind closed doors
Examples please !
> - in each case the community tried to be receptive; since we are set
> up for collaboration
> - A specific technological direction - the use of JaxB an xml parsing
> technology - we were unable to accept as it could not be used with
> Java 5 (representing our current installation base)
JaxB is Compilation agnostic so, if you don't use it because you want
to use an other technology for Java5 it can leave silently it's own
life without disturbing Java5 people.
> - in ability to accept patches; we had a $60k referencing patch that
> sat in the code base for 3 years; which we now see integrated on this
Oh, here you make my day Jody !
Let me explain how I percieved things on my side.
Referencing library has been conceived, writen, corrected, rewriten
from scratch by Martin since the begining of the SeaGIS project (way
before the start of Geotools 2.0 project). This library is a really
complex one (as mentionned Andrea in your IRC meeting) not because
Martin wanted to do things complex, but because geodetic concepts
*are* complex by nature.
At that time you arrived with a $60k contract to make deep
modifications (concurrency) in this library with no real knowledge of
what's going on in it. You talked with Martin about some design
concerns and after a long discussion about the real gains with a
concurrent approach in referencing, you started coding some pieces of
code that, finaly was not in a good shape enough to be integrated in
the core module. At that time Martin started Geomatys with me, and was
in the obligation to focus in priority in paid work rather than in
community ones. Referencing was working really well without
concurrency, you did'nt explained the real needs of it's inclusion on,
so there was no apparent emergency for Geotols to integrate it in a
hurry (and there was no funding on geomatys side to pay Martin for
Recently, Martin started a code cleanup and some rewrite of the
Geotools library he was maintainer in order to start a more robust
version of Geotools with the aim to push it in a future Geotools 3.0
project (code name Geotidy). Geomatys funded the whole amount of
Martin's time for this cleanup (about 6 month). When he arrived to the
referencing library, Martin started to integrate the concurrency
patches you created earlier (your name is in geotoolkit source code).
This integration was in fact a massive rewrite of your work (it wat
taking about one month), and was taking place in Geotidy, so it was
intended to take place in GT 3.0.
I suppose that at the end of your contract everything was working on
your side and you've done the patches integration in your client's
code base, so as I said there was no apparent hurry for it's
You never give us all the reasons about concurrency needs in
referencing. Even after doing the job on Geotidy, the only benefits we
can see is to avoid some blocking when requesting different geodetic
definition repository in an http way. So on my side explain me why
should I pay Martin for one month to integrate something tha we realy
don't need ?
I wonder why you never proposed to sub-contract with Martin if you
wanted to get things done in your timeframe, but tha's an other
> I am not sure what else is useful to say; the GeoTools project is
> open; has published procedures; and as a project management committee
> member it was Martin's responsibility to communicate on behalf of his
> users and organization. I enjoy a strong working relationship with
> Martin and really enjoy the chances we have to work together. I feel
> this one is as much about control; and the requirement to answer to
Everything has been said in the "history" page of Geotoolkit
> We have had a recent IRC discussion on this one
> and have been fielding private emails from our user community (hense
> the need for a public announcement). Personally I am more worried
> about the GeoAPI project then either of GeoTools or GeoToolkit.
I can read in this log that you're willing to use the referencing
library that comes from Geotoolkit, this is a really good news, that
means for OSGEO people, that this fork isn't a simple copy of
Geotools, but an innovative project whith it's own specificity, and
will have more technical departure by the time, that give in my
opinion all it's legitimity in the opensource ecosystem.
For GeoAPI, your company is an OGC member, so feel free to join the
SWG or contribute without being involved in the SWG like other people
are doing currently.
I'll let Martin and Adrian talk more deeply about what have been said
here, but on my side I can't let you claim that Geomatys has been
driven in a parasitical way. Martin has spend a lot of time on some
key library of geotools, and if Geotools is now incubated feel free to
thank's the huge amount of work done by Adrian (funded by Geomays).
>>> A couple weeks ago we received another application for incubation
>>> from the
>>> GeoToolkit project. GeoToolkit is a fork of GeoTools.
>> Um... a fork of an existing OSGeo project applying for graduation.
>> Not sure
>> what to think about that. Forks are part of our reality and I have no
>> problem with that, but I'm not sure that OSGeo can stand behind two
>> forks of
>> the same project.
>> The history page is an interesting read, but I still don't get a
>> clear idea
>> of what's happening exactly and what to think about both GeoToolkit
>> It would perhaps be interesting to hear what the GeoTools PMC
>> members have
>> to say about this fork... hear their side of the story.
>> Daniel Morissette
>> Incubator mailing list
>> Incubator at lists.osgeo.org
More information about the Incubator