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

[Daniel Morissette]

[Forwarding Justin's reply since he doesn't seem to be on the list]

-------- Original Message --------
Subject: Re: [geotk] Re: [Incubator] New Application: GeoToolkit
Date: Sat, 23 May 2009 15:17:54 -0400
From: Justin Deoliveira <jdeolive at opengeo.org>
To: Adrian Custer <acuster at gmail.com>
CC: Daniel Morissette <dmorissette at mapgears.com>, 
geotoolkit at lists.osgeo.org,  Arnulf Christl 
<arnulf.christl at wheregroup.com>, OSGeo-incubator <Incubator at lists.osgeo.org>

Hi everyone,

I would like to respond to Daniels request to hear from the rest of the
GeoTools PMC and voice my thoughts. First off I just want to say that I
am actually not against the fork. As Howard said forks are a good thing
for OSS. And the diversity of the projects in OSGEO is one of the things
that makes it so great.

That said, I would like to rebut a point that the GeoToolkit history
makes indicating that the GeoTools PMC is over dominated by GeoServer
developers:

"Meanwhile the PMC also came to be dominated by developers working
primarily on the GeoServer project so that decisions related to the
GeoTools library were subsumed to the needs of the GeoServer project"

This is false. While I will admit having a number of GeoServer
developers on the GeoTools PMC introduces some natural bias, I can
recall a number of occasions in which technical decisions were made that
were bad for GeoServer. The use of java logging, a core dependency on
conflicting libraries, etc... were all very problematic for GeoTools
outside of its referencing core. However in the interest of
collaboration and compromise we worked around it in GeoServer.

Unfortunately the move to java 6 is not something we can work around.
GeoServer is a long running project with a wide user base and many
installations running in production. There are many organizations that
due to policy simply can't make the upgrade, and many others in which an
upgrade would be too problematic to be worth it.

Martin did eventually graciously offer to provide us with Java 5
compatible builds. But it did require a significant amount of
synchronization work on our side, so given the "take it or leave it"
offer we were forced to leave it for the time being.

Lastly I would like to point out that anyone who follows our developer
list will notice that it is often the case that the GeoServer developers
on the GeoTools project do not agree amongst themselves. Even developers
belonging to a single organization have disagreements about project
decisions. I can recall proposals in which i have been out voted on.

That said, I agree with Adrian on a number of points. The first is that
the fork has actually been good for GeoTools. It has forced some long
needed cleanup, but more importantly it has made us step back and
reevaluate some of our policies. Which is a good thing for the community.

The second thing I agree with Adrian on is that we have not ruled out
integrating with GeoToolkit. Unfortunately this has to be a slow process
for us because of a) the switch to java 6 is not trivial and b) we need
to evaluate any other issues or library conflicts that might result
since we are now effectively out of the loop.

And in closing let me state that it is my personal opinion that the real
issues here are not technical, those are solvable, but political.
Various threads scattered on mailing list and IRC (both public and
private) clearly indicate this imo.

That said, I don't envy the incubation committee on this one. A touchy
issue which will undoubtedly set the precedence for similar situations
in the future.

-Justin

Adrian Custer wrote:
> 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
> _______________________________________________
> Geotoolkit mailing list
> Geotoolkit at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geotoolkit


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.