[Incubator] New Application: GeoToolkit

[Adrian Custer]

   [Sent only to the Incubator list on this iteration, since
    the first messsage was rejected.]


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