[geotk] Re: [Incubator] New Application: GeoToolkit

[Adrian Custer]

Mr, Morissette, Members of the Incubator list, Arnulf,


The Geotoolkit application now before the incubation committee breaks new 
ground for OSGeo. At the very least, even if it proves a difficult decision to 
make, it should make the committee's work on this issue more interesting than 
usual. At the best, it could help everyone understand better their own 
philosophical stance and their goals for the OSGeo foundation.

Mr. Morisette, you have unfortunately started the discussion on the foot of 
examining the reasons, justifications, and merits for the fork itself, a 
discussion which I, in your position, would have avoided avidly. The reasons 
for the fork are long, mixing differences in vision, with differences in 
professional demeanour and technical competence, along with divergent personal 
loyalties and strategic commercial interests. Unfortunately, since that cat is 
now out of its bag, we will have to engage in that discussion as well despite 
it being of limited utlitity. Here, however, I tackle the issues which seem 
more relevant to the decision on this application and are possibly more 
interesting, confronting your committee with some existential questions around 
what kind of OSGeo you are striving to build.



 From my perspective, the interesting and fundamental issue before you 
involves what is the best decision on this incubation application for OSGeo as 
a foundation, as a community, and as a custodian of its current projects, one 
of which is GeoTools.

First of all, you face the issue of whether Geotoolkit actually meets your 
criteria for incubation---if it does not, then the issue becomes quite simple. 
You, of course, will have to be the ones to make this decision but 
circumstances limit the bases for your decision. By graduating GeoTools, you 
have already affirmed that you believe the project goal, the license, and the 
code base meet the aims and requirements of OSGeo. On this aspect then, you 
are possibly left only with deciding if the management and running of the 
Geotoolkit project meets the requirements of the foundation. Here you also 
face new ground as Geotoolkit is run using the distributed version control 
system Mercurial making many of your usual criteria for evaluation, such as 
number of programmers with access to the (centralized) VCS, no longer apply. 
It is a Linux in a sea of FreeBSD, a new comer and ugly cousin of what you are 
used to seeing. The time of incubation is explicitly set up as the time during 
which projects can sort out their management issues so that it seems that your 
decision ends up being around whether you think the project wishes to and is 
capable of adopting the open style of collaboration which you wish to foster 
within the foundation. That will be a hard decision for you to make, I can not 
even establish which criteria I would use myself to be able to reach such a 
decision.

A second question you face is whether adding Geotoolkit to OSGeo will directly 
hurt GeoTools. At a practical level, the projects will be independent with 
separate possibly overlapping communities so there will not be any direct 
effect of one on the other. At the level of copyright, adding Geotoolkit would 
directly help GeoTools since the two project code bases would be copyright of 
OSGeo and therefore GeoTools could incorporate the code of Geotoolkit without 
mixing copyright holders. At the level of competition, it may make both 
projects work harder.

For the OSGeo community, a question you face is deciding whether having two 
projects which are naturally in competition today would prove harmful to the 
members of the Foundation. One can imagine that in the near future the 
projects, each on its side, will keep an undercurrent of resentment towards 
the other until both have established their own identities enough to feel 
fully self-justified. A question would be guessing how much of this sniping 
will keep happening and whether having this under the umbrella of the same 
foundation would matter particularly one way or the other. You will have to 
balance that concern with the clear benefit of pulling in to the foundation 
the scientific community now forming around Geotoolkit.

At the level of the foundation, Cameron Shorter raises a separate issue, of 
whether OSGeo can host two similar projects without confusing its users or 
donors. This, to me, is a critical question that you will have to answer in 
the course of your decision and which reaches the core of OSGeo's aim as a 
Foundation. Clearly, OSGeo hosts several projects with similar aims, such as 
the various web clients including MapGuide, OpenLayers, and the new 
application MapFish, so the Foundation has not yet adopted a principal of 
exclusivity. Cameron suggests OSGeo may want to adopt a funding prioritization 
plan between projects. If you do so, you will be faced with the tricky 
question of choosing the basis on which you will favour one of your projects 
over another. Will you be building an umbrella foundation for geospatial 
software or building an advocacy group for your prefered geospatial projects? 
If the latter, do you have a good sense of the reasons you will take for 
favouring one project over another or will you simply favour the first project 
of each type to join the foundation? Hard questions for you, and we will all 
learn from your answers to them. Note also that these questions go beyond the 
evaluation criteria you have set out for yourselves:
   http://www.osgeo.org/incubator/process/evaluation.html
so, depending on how you answer this issue, you may need to amend that document.

These questions may be hard but they will help clarify where you stand and 
what kind of OSGeo will emerge. I am personally lucky in this since your 
decision on Geotoolkit incubation, which will influence the depth of my 
ongoing work with OSGeo, will simultaneously establish whether your vision 
matches my own perspective on these issues.




A brief discussion of the fork, since the issue has been raised.

First, we should note that the fork has been wonderfully beneficial to both 
projects. GeoTools is currently undertaking a frenzy of cleanup, adding new 
members to its board, picking new ways of working, and generally has much more 
positive energy than it has had in a long time. Geotoolkit similarly has good 
energy, working methodically to break new ground and cleanup its code in its 
own way. In my personal case, I was deeply surprised by the relief I felt on 
unsubscribing to the GeoTools list four months ago---a wave of anguish was 
lifted from my shoulders. In retrospect then, I think the Geotoolkit project 
should have forked much sooner and we all should not have spent the last year 
struggling to resolve what are fundamental differences and struggling to keep 
GeoTools whole, all merely to avoid a 'fork'. Forks are entirely healthy parts 
of a functioning open source ecosystem not terrifying admissions of some deep 
seated failure.

The fork in Geotools2 arises from a number of long simmering differences in 
the community, perhaps the most fundamental of which is a difference in vision 
of what is being built: either a complete library for geospatial work based on 
published standards or a functional library for the needs of the projects 
using the library. There are other differences in the approaches of these two 
sub-comunities, one favouring Sun Java technologies, the other Apache 
libraries, one favouring a full, possibly complex, design, the other favouring 
simplicity. There are also strong differences in personalities and in vision 
of relative responsibilities of PMC members, module maintainers, and regular 
participants. Also, the commerical interests of GeoServer have never been far 
from the table since the developers paid by TOPP to work on GeoServer could 
never justify working on aspects of the library which did not directly help 
GeoServer. That the Geomatys developers, having been pushed out of the 
GeoServer community, started the competing Constellation server exacerbated 
these tensions. We can see this difference clearly in the difference in 
importance the two groups attach to writing Javadoc code documentation for 
third party users and in the recent new nominations to the GeoTools PMC all of 
whom work on GeoTools in the context of GeoServer. These differences are deep 
enough that they are not worth reconciling---much better to have two projects 
each going in its own direction trying to do its best at what it wants to do.

The question of the similarity of the name has been raised on the IRC channel. 
The name was picked intentionally since, in our opinion, the project which is 
really taking a new direction is the project currently named GeoTools. In our 
opinion, they are taking the new 'fork' in the road by repudiating the goal of 
building a general purpose library, by recondsidering their adherance to the 
ISO/OGC standards and by centralizing control in the PMC. For us, Geotoolkit 
is staying true to the original goals of the GeoTools2 project and so, as the 
intellectual heirs to that original vision, we wanted to maintain continuity 
with the name.


I would have liked to have kept the discussion at this abstract level where I 
try as honestly as I can to express the differences in vision and modes of 
working that led to this separation of ways. Unfortunately, Jody's recent 
email to the incubation list impunes directly one of the developers I most 
respect in the whole free software community from GNOME to FreeGIS. Since 
Martin is much too polite to respond directly to such statements, I will find 
myself obliged to confront Jody directly and bluntly. However, I will address 
those issues in a separate mail.


All the best,
   -adrian custer