New Application: GeoToolkit

[Frank Warmerdam]

Folks,

A couple weeks ago we received another application for incubation from the
GeoToolkit project. GeoToolkit is a fork of GeoTools.

http://wiki.osgeo.org/wiki/Geotoolkit_Incubation_Application

The full list of pending applications is at:

http://trac.osgeo.org/osgeo/query?status=new&status=assigned&status=reopened&component=Incubator&keywords=%7Eapplication&order=priority

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Daniel Morissette]

Frank Warmerdam wrote:
> Folks,
>
> A couple weeks ago we received another application for incubation from the
> GeoToolkit project. GeoToolkit is a fork of GeoTools.
>
> http://wiki.osgeo.org/wiki/Geotoolkit_Incubation_Application
>

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
vs GeoTools:

http://www.geotoolkit.org/history.html

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
--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Daniel Morissette]

Daniel Morissette wrote:
>
> Um... a fork of an existing OSGeo project applying for graduation.

Of course I meant "... applying for incubation" and not graduation.

Daniel
--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Cameron Shorter-2]

Geotools as a project has already graduated to be a full OSGeo project.

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.

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.

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.

One thing that has been discussed before, and would be very valuable to
the greater community, and hence to projects, would be a purchasing
decision tree for the OSGeo projects that are supported. I think this
would be very useful for Geotools/Geotoolkit too. Under what
circumstances would you select Geotools? Under what circumstances would
you select Geotoolkit?

Cameron Shorter, the (final) incubation mentor for Geotools.

Daniel Morissette wrote:
> Daniel Morissette wrote:
>>
>> Um... a fork of an existing OSGeo project applying for graduation.
>
> Of course I meant "... applying for incubation" and not graduation.
>
> Daniel


--
Cameron Shorter
Geospatial Systems Architect
Tel: [phone]
Mob: [phone]

Think Globally, Fix Locally
Geospatial Solutions enhanced with Open Standards and Open Source
http://www.lisasoft.com

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Howard Butler]

On May 22, 2009, at 6:36 PM, Cameron Shorter wrote:

> Geotools as a project has already graduated to be a full OSGeo  
> project.
>
> 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 ..."

<http://n2.nabble.com/Geotoolkit-announcement-td2727370.html> states  
"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  
ecosystem?
...


>
>
> 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.


_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Jody Garnett-2]

Hi Daniel:

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.

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.

A couple specific things that got me:
- strategic decisions that should be made as a community were being
made behind closed doors
- 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)
- 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
fork

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
community.

We have had a recent IRC discussion on this one
(http://docs.codehaus.org/display/GEOTOOLS/2009/05/20/Breakout+IRC+Meeting)
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.

Jody

>> Folks,
>>
>> A couple weeks ago we received another application for incubation from the
>> GeoToolkit project. GeoToolkit is a fork of GeoTools.
>>
>> http://wiki.osgeo.org/wiki/Geotoolkit_Incubation_Application
>>
>
> 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 vs
> GeoTools:
>
> http://www.geotoolkit.org/history.html
>
> 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
> --
> Daniel Morissette
> http://www.mapgears.com/
> _______________________________________________
> Incubator mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/incubator

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Jody Garnett-2]

>> 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.

I will also comment that GeoTools PMC have not ruled collaborating
with the GeoToolkit, such details are being worked out currently.
Jodyl
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Jody Garnett-2]

Thanks for the discussion Howard:

I think I should refrain from further comment on this one.

Jody

> I will also comment that GeoTools PMC have not ruled collaborating
> with the GeoToolkit, such details are being worked out currently.
> Jodyl
>
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[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
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Adrian Custer]

     [Forwarded on behalf of Martin, who is not subscribed to the list]


Hello Jody

I would like to bring my point of view on some of the point raised:

Jody Garnett a écrit :
> We had ask Martin to step down last month which was very dissappointing.

Actually my decision to step down from the PMC has been taken before that, the
same day than when we decided to fork. It was not announced immediately
because we wanted to have the geotoolkit web site ready before to make the
anouncement.

> A couple specific things that got me:
> - strategic decisions that should be made as a community were being
> made behind closed doors

The mercurial repository was public since the begining, and the main lines of
the most important changes were documented:

     http://www.geotoolkit.org/build/tools/geotk-migrate/changes.html

The above link has been given on the mailing list in various "report on
geotidy progress" emails. The PMC did not commented those changes as far as I
know.


> - 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 can be used with Java 5 - you just need to add the JAXB jar file provided
by Sun or other vendor. This is exactly the same situation than the Eclipse
technology used in other GeoTools modules, which require an eclipse JAR file
for parsing XML.

Note that in Java 6, JAXB is integrated straight in the JDK so there is no
longer external dependency, at the opposite of Eclipse-based XML parsing.

What was considered unacceptable was the addition of a dependency to an other
JAR file (JAXB) for Java 5 users, which I can understand. For this reason we
provided a mechanism allowing to "erase" JAXB annotations at compile-time for
those who don't want them. This mechanism worked with Maven (the official
GeoTools build tool) and NetBeans (the IDE we use at Geomatys), but was broken
on Eclipse (the IDE used by Geoserver developers). Consequently we rolledback
JAXB and moved our work to an other repository. At this time (one year ago) it
was for us a branch, not yet a fork.


> - 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
> fork

There are patches that I accepted much faster than this particular one.
Generally speaking I have been happy with Rueben Shulz's work for instance.

I did not accepted that particular patch because I was not happy with that
code. When as a module maintainer I asked for changes (on the mailing list),
someone from Refractions replied me that the contract with the client was over
and if I wanted my change requests to be applied, I need to pay Refractions -
or I should have done my requests sooner.

I have spent 10 years writting referencing. Then Refractions stepped in this
module which was mostly unknown to them. No use case was given for justifying
their objective, despite our questions on the mailing list. The result of that
work was in large part duplication of existing code.

That work has not been integrated "as is" in Geotoolkit. The code duplication
has been simply deleted, and the most noticeable new classes (ObjectCache and
related) have been rewritten from scratch (compare with the "Cache" class on
Geotoolkit) for technical reasons.

I rewrote all this work in 2 or 3 weeks. Knowning that Refractions has been
paid $60k for that just add to my amertume.


        Regards,

                Martin

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Adrian Custer]

Mr. Butler,

You have a surprisingly clear vision of the mode of governance that you expect
all OSGeo projects to follow. If your vision is widely shared, then indeed
Geotoolkit should not become a project of OSGeo since that is not the way that
I wish to foster community governance over the destiny of this project.


However, let me present an alternative model of governance from the PMC
rules/dictatorship dichotomy you construct, since it is the one that I believe
we started with in GeoTools and one that I wish to negotiate towards as we
build the Geotoolkit community. The Green Party of Alameda County, as I
discovered to my great surprise when I first went to observe a party meeting,
considers voting a major defeat. Indeed, they will go to immense lengths to
avoid voting. They have developed proceedures to work on issues first by
polling participants for general feeling on issues by the collective loudness
of snapping of fingers, then by fostering as much dissenting discussion as the
participants can muster, then by trying to reach consensus. If no consensus is
reached, they repeat the cycle, ideally with a slightly different focus to
unblock the discussion. Throughout all this, at any time, anyone can call
formally for a vote on the issue. However, a vote is widely considered a
dangerous failure. You might wonder why and I can only offer you my
interpretation. We all know the concept of the tyranny of the majority in
modern democratic republics, and that notion applies to any institution
working based on majority rule. Furthermore, the participants at the green
party meetings are greatly conscious of the rest of the party not present and
do not wish to impose the conclusion of that day's majority of those present
on the rest of the party as would happen after a formal vote. Instead, they
seem to hope that they can reach a place where even strong dissenters are able
to voice both their dissent and the position of others to which they finally
consented. By formally consenting, they are brought back into the mainstream
of the group and acknowledged as having compromised for the benefit of all---a
powerful mix. It is, obviously, a time consuming process but for me stands as
a marvelous example of humans trying to forge common goals on complex issues.

When I speak of returning to the old governance model of GeoTools, I am
seeking to return to a similar way of working. There was a time when voting
was very rare in the Geotools community. It became popular initially as a
shortcut during IRC meetings towards polling for consensus where participants,
instead of offering opinions, simply typed "+x". This evolved slowly,
steadily, and unacknowledged to become the actual mode of decision making.
Jody eventually formalized this way of working in his 'proposal' process as
the approach that would be required for any changes to the main module and to
core API, and this proposal process then came to control all changes to the
library. This is not to criticize Jody for this change, but to present the
evolution of governance as I have experienced it. As the member of the
community most involved in the project but not on the board, I saw the
decision making process evolve from one where decisions were made based on
intense technical discussion and hard compromise to one where only two typed
characters were required to take a position and that position was then imposed
on me. At the same time, I found myself formally excluded from consultation
since I have never been on the PMC and therefore do not have any standing on
that decision making process. There even arose during this period a closed,
hidden mailing list of the PMC which is one of the most insidiuous steps a
governing body can ever take.

If I had to point a finger at one thing that killed GeoTools for me, it would
be that. Having the majority of the PMC impose its will on the whole community
is a disaster. Justin mentions a compromise he made years ago on logging, and
I remember it well. We all made significant, hard compromises to work together
over the years and I remain quite conscious of the work it took to reach and
maintain consensus. Those compromises enriched me since they were affirmations
from others that they were willing to take on a burden for the benefit of the
community. Now that effort no longer happens but the PMC regularly falls back
on their vote. So instead of my participation in the project being fueled by
technical argument, it was dictated through vote by the majority of a
committee of a mere six members of the project, one of whom was generally
absent and one of whom I consider incompetent technically. Over the years I
have done more than my fair share of grunt work in the project to help it
along and make sure that others could focus on the work they were best at, my
incentive for this went from the aspiration to follow good technical arguments
to the burden of following the majority vote of the PMC.



My vision, then, of the governance model for Geotoolkit differs deeply from
the way GeoTools ended up working by 2008. I most hope to avoid anyone having
to follow the fiat of some sub-committee of the project be they the
self-appointed leaders or anyone else. However, this vision is merely my own,
one that I will not impose on anyone but one that I will have to argue
passionately for when we take on these issues. For now, we are waiting for the
community to grow, waiting certain participants to finish the institutional
paperwork that will allow them to join us formally, and waiting for others to
assess the project and see if they want to join us. When we reach critical
mass, we will be able to tackle such issues formally; for now, we are working
this way informally.

I believe, on the basis of intuition alone, that the systems of distributed
version control (DVCS) have fundamentally altered the world of software
development and provide an enourmous democratizing potential for project
governance. This is not just that being able to make micro commits to one's
hard drive helps programmers work. It comes from placing everyone in the
project on an absolutely equal footing and with the same burdens of
responsibility to make ongoing collaboration possible. It also returns to the
fore the technical meritocracy that makes for the strongest projects since
everyone needs to decide, freely and on their own volition, whose changes they
wish to integrate. No one yet know how this will play out. I am aware that it
may make reaching compromise more work but am also certain that it will both
make the need to agree on everything unnecessary and free parallel lines of
development. Indeed, if GeoTools ever decides to rely on Martin's improved
referencing code in Geotoolkit, they will be able to do so y maintaining their
own clone integrating any changes they wish to make locally and evolving the
code at the pace that they wish to follow---a great advantage for everyone.



This is a long answer to make you read, and for that I apologize. However, I
realize that in many ways this is Adrian's manifesto for Geotoolkit governance
so it is useful that it live email archives of that project.

Cheers,
   adrian


PS The name Geotoolkit actually seems to me to better reflect the nature of
the project than GeoTools ever did. Ever since Osterhout invented the term at
Berkeley, 'toolkit' has a well defined meaning in the programming world as a
library of reusable components which is what the project always intended to
be. I have explained, in my earlier email, that we use a name so similar to
the original to maintain historical continuity with the GeoTools2 effort that
Martin co-founded. In my mind, it is the new GeoTools project that has taken
the fork in the road in order to become libgeoserver and I am working on a
'fork' only because developers making their living working on geoserver had
operational control, i.e. the votes on the PMC, to block GeoTools3.

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Daniel Morissette]

[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 <[hidden email]>
To: Jody Garnett <[hidden email]>
CC: Daniel Morissette <[hidden email]>, OSGeo-incubator
<[hidden email]>, Martin Desruisseaux
<[hidden email]>, Adrian Custer <[hidden email]>

Great !

 > 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
you know.
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
needs ?

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
 > fork
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
this job).

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
integration.
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
story ...

 >
 >
 > 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
 > community.
Everything has been said in the "history" page of Geotoolkit
 >
 >
 > We have had a recent IRC discussion on this one
 >
(http://docs.codehaus.org/display/GEOTOOLS/2009/05/20/Breakout+IRC+Meeting
 > )
 > 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).

Cheers,

Vincent

 >
 >
 > Jody
 >
 >>> Folks,
 >>>
 >>> A couple weeks ago we received another application for incubation
 >>> from the
 >>> GeoToolkit project. GeoToolkit is a fork of GeoTools.
 >>>
 >>> http://wiki.osgeo.org/wiki/Geotoolkit_Incubation_Application
 >>>
 >>
 >> 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
 >> vs
 >> GeoTools:
 >>
 >> http://www.geotoolkit.org/history.html
 >>
 >> 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
 >> --
 >> Daniel Morissette
 >> http://www.mapgears.com/
 >> _______________________________________________
 >> Incubator mailing list
 >> [hidden email]
 >> http://lists.osgeo.org/mailman/listinfo/incubator
 >
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Howard Butler]

On May 24, 2009, at 7:15 AM, Adrian Custer wrote:
> When I speak of returning to the old governance model of GeoTools, I  
> am seeking to return to a similar way of working. There was a time  
> when voting was very rare in the Geotools community. It became  
> popular initially as a shortcut during IRC meetings towards polling  
> for consensus where participants, instead of offering opinions,  
> simply typed "+x".

MapServer, who's governance model [1] is copied across a lot of OSGeo,  
provides for short circuiting the tyranny of the majority by allowing  
people to veto.  A veto has consequences, however, and the person  
vetoing makes themselves responsible for coming up with a viable  
alternative to the proposal.  This prevents folks from merely saying  
"I don't like it" and forces them to say "I don't like it and I think  
this is better."  If I recall correctly, there have been *no* vetos in  
MapServer to date.  I think this is because proposers understand who  
they need to placate when they are proposing implementations or  
solutions.

> Jody eventually formalized this way of working in his 'proposal'  
> process as the approach that would be required for any changes to  
> the main module and to core API, and this proposal process then came  
> to control all changes to the library.

My experience with MapServer and GDAL is that they tend to only write  
proposals for areas that look like they will impact lots of people.  
The idea is if you are wondering whether or not you need to write a  
proposal, you probably do.  In the same way that writing a question to  
an email list can crystalize your knowledge of a problem, writing a  
proposal can have the same effect.  In fact, I have written a few  
proposals for MapServer that were quite simple or even irrelevant  
after I went through the effort of writing it.  I think the proposal  
process is too heavily relied upon as primary documentation for  
MapServer, but this is better than before when there wasn't even that.

GDAL also requires proposals for changes to core APIs, but I think  
GDAL's culture is quite different than GeoTool's.  There is  
practically no refactoring in GDAL, because we think the churn it  
creates for users is quite high and it sheds them.  While I find this  
terribly infuriating sometimes, from a practical standpoint it means  
there is very little subtraction from the public API, and developers  
must live with some of the impudent aspects of the externals and  
internals of GDAL.  This policy has served the project well even  
though it can cause plenty of developer heartburn.

> At the same time, I found myself formally excluded from consultation  
> since I have never been on the PMC and therefore do not have any  
> standing on that decision making process.

"I am forking this project unless I can be on the PMC and have some  
control over my destiny" would have probably been sufficient to cause  
the PMC to act, especially if they thought you had the wherewithal to  
follow through and make it stick ;)

> There even arose during this period a closed, hidden mailing list of  
> the PMC which is one of the most insidiuous steps a governing body  
> can ever take.

I agree that private PMC lists (at least ones that have discussions  
about anything significant) can be rather poisonous to project harmony.

> I believe, on the basis of intuition alone, that the systems of  
> distributed version control (DVCS) have fundamentally altered the  
> world of software development and provide an enourmous democratizing  
> potential for project governance.

I do not believe that DVCS is incompatible with OSGeo-style project  
governance.  As a SAC member, I have been investigating the DVCS  
technologies, because I think it is inevitable that we will have to  
support one.  I would like one that integrates with Trac first and  
foremost because I think Trac has been a productivity boon to all of  
the OSGeo projects. One that integrates with Subversion would be nice  
but not a blocker.

DVCS can widen the source code availability, usage, and convenience,  
but I disagree that it does much for project governance.  The  
"project" is a construct that sits atop the source code.  I think the  
really important issues that a PMC helps to clarify, like when/how to  
release, still happen regardless of the version control.

> PS The name Geotoolkit actually seems to me to better reflect the  
> nature of the project than GeoTools ever did.

My opinion is to outsiders, especially uninformed users, this is  
unnecessary ambiguity.   A name need not describe what something does  
(MapServer, I stare in your general direction :), but it needs to be  
distinctive enough to discriminate -- *especially* within the context  
of a fork.  Otherwise, it will be hard to allow the two projects to  
diverge from a technical standpoint, right?

[1] http://mapserver.org/development/rfc/ms-rfc-23.html
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Jody Garnett-2]

Hi Howard:

A couple of clarifications in line.

>> At the same time, I found myself formally excluded from consultation since
>> I have never been on the PMC and therefore do not have any standing on that
>> decision making process.
>
> "I am forking this project unless I can be on the PMC and have some control
> over my destiny" would have probably been sufficient to cause the PMC to
> act, especially if they thought you had the wherewithal to follow through
> and make it stick ;)

We asked Adrian about PMC membership several times; since he was
taking such a strong leadership role in the incubation process. The
ability to make change proposals is open to all; and one can always
step up with contributions to a module; or even become a module
maintainer.

>> There even arose during this period a closed, hidden mailing list of the
>> PMC which is one of the most insidiuous steps a governing body can ever
>> take.
>
> I agree that private PMC lists (at least ones that have discussions about
> anything significant) can be rather poisonous to project harmony.

The mailing list geotools-administration is open to all; it was taken
as a step for a code free list (since discussions were being lost in
the chatter). This mailing list is open to the public - although
frankly the PMC members have forgotten to use it.

Cheers,
Jody
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Frank Warmerdam]

Adrian Custer wrote:
> My vision, then, of the governance model for Geotoolkit differs deeply from
> the way GeoTools ended up working by 2008. I most hope to avoid anyone
> having
> to follow the fiat of some sub-committee of the project be they the
> self-appointed leaders or anyone else. However, this vision is merely my
> own,
> one that I will not impose on anyone but one that I will have to argue
> passionately for when we take on these issues.

Adrian,

I understand a consensus based approach to decision making as a goal.
What isn't clear to me is how Geotoolkit intends to address failure to
reach consensus.  It is fundamental to me that OSGeo projects have a
formal mechanism to address failure to reach consensus on technical and
non-technical matters.  If Geotoolkit fundamentally disagrees with having
such a mechanism then I'm not sure it makes sense to try and fit it into
the OSGeo mold.

I understand there has also been a concept at times of GeoTools package
maintainers being sovereign in their own package.  Sort of a local dictator.
I am also concerned that this is contrary to the goals of OSGeo where
new folks can join the project and have a reasonable degree of comfort
that their voice will be heard.  I'm not sure if it was intended to utilize
this approach in Geotoolkit or not, but if so it would be a matter of
concern for me.

> I believe, on the basis of intuition alone, that the systems of distributed
> version control (DVCS) have fundamentally altered the world of software
> development and provide an enourmous democratizing potential for project
> governance. This is not just that being able to make micro commits to one's
> hard drive helps programmers work. It comes from placing everyone in the
> project on an absolutely equal footing and with the same burdens of
> responsibility to make ongoing collaboration possible. It also returns
> to the
> fore the technical meritocracy that makes for the strongest projects since
> everyone needs to decide, freely and on their own volition, whose
> changes they
> wish to integrate. No one yet know how this will play out. I am aware
> that it
> may make reaching compromise more work but am also certain that it will
> both
> make the need to agree on everything unnecessary and free parallel lines of
> development. Indeed, if GeoTools ever decides to rely on Martin's improved
> referencing code in Geotoolkit, they will be able to do so y maintaining
> their
> own clone integrating any changes they wish to make locally and evolving
> the
> code at the pace that they wish to follow---a great advantage for everyone.

I must confess that I'm not clear on the social implications of DVCS.
It does still seem important that an OSGeo project produce vetted
releases that are considered to be the product of the project as
a whole.  I'm not clear how that fits with a DVCS free-for-all.  But
I may be reading too much into this.

Overall my concerns with Geotoolkit are:

  1) Does it really have a sufficient community to flourish for some
     time?

  2) Is it really going to be able to operate in a community based
     manner or is it essentially a geomatys fork?

  3) Does it have technical strengths that make it appropriate for
     OSGeo to promote it?

  4) Is it going to be able to work within a governance model that is
     going fit with OSGeo's concept of prudent management?

My initial pre-disposition is to give things a bit of time to shake out
before seeking to bring the project into incubation.  This would give
time for us to see if Geotoolkit is attracting broad interest, and to
give the project some time to find it's governance/community operation
legs.  At that point it might be more clear if the fit is good.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Paul Ramsey]

On Mon, May 25, 2009 at 7:49 AM, Frank Warmerdam <[hidden email]> wrote:

>> I believe, on the basis of intuition alone, that the systems of
>> distributed
>> version control (DVCS) have fundamentally altered the world of software
>> development and provide an enourmous democratizing potential for project
>> governance.

> I must confess that I'm not clear on the social implications of DVCS.
> It does still seem important that an OSGeo project produce vetted
> releases that are considered to be the product of the project as
> a whole.  I'm not clear how that fits with a DVCS free-for-all.  But
> I may be reading too much into this.

I think this is valid concern, since control over the official source
is the lynchpin to control of the project. From whose DVCS instance
will geotoolkit-1.0.jar be built before it is placed on the web site
for download? The person who controls commits to that instance is the
benevolent dictator. The incubation application is explicit that "One
person will be responsible for all commits into the repository."

Not that benevolent dictators (*cough* Frank *cough*) can't produce
good (or even superior) product. But we seem to have decided that
we're not OK with that governance model (for reasons that are lost in
history?).

P.
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Daniel Morissette]

Frank Warmerdam wrote:

>
> I must confess that I'm not clear on the social implications of DVCS.
> It does still seem important that an OSGeo project produce vetted
> releases that are considered to be the product of the project as
> a whole.  I'm not clear how that fits with a DVCS free-for-all.  But
> I may be reading too much into this.
>
> Overall my concerns with Geotoolkit are:
>
>  1) Does it really have a sufficient community to flourish for some
>     time?
>
>  2) Is it really going to be able to operate in a community based
>     manner or is it essentially a geomatys fork?
>
>  3) Does it have technical strengths that make it appropriate for
>     OSGeo to promote it?
>
>  4) Is it going to be able to work within a governance model that is
>     going fit with OSGeo's concept of prudent management?
>
> My initial pre-disposition is to give things a bit of time to shake out
> before seeking to bring the project into incubation.  This would give
> time for us to see if Geotoolkit is attracting broad interest, and to
> give the project some time to find it's governance/community operation
> legs.  At that point it might be more clear if the fit is good.
>

I agree. Sounds like "wait and see" is the best we can do for now.

Daniel
--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Adrian Custer]

Hello Frank,

I spent much of the day yesterday trying to frame a productive answer to
you and failed---perhaps starting anew will work out better. No,
unfortunately it has much the same form as the old, so I will send this
as is and force another missive upon you.



On Mon, 2009-05-25 at 10:49 -0400, Frank Warmerdam wrote:
> I understand a consensus based approach to decision making as a goal.
> What isn't clear to me is how Geotoolkit intends to address failure to
> reach consensus.  

As it works on other projects, there is very little scope for blocking
conflict; indeed, in ten years of working on Gnumeric I have yet to see
a single instance of such an issue. On technical issues, one always asks
the maintainer of each module for permission to make changes there. For
release issues, the person doing the work is generally trusted to make
it happen as best they can. For social issues, we work things out like
gentleman. I suppose, if it ever came down to it jody, and gmorten,
possibly with aguelzow would be the ones forced to make a call but that
need simply has not arisen and the level of mutual respect in that
community ensures it probably never will. One of the ideas of Mercurial
is to reduce further any scope for conflict: no one needs permission for
access to the VCS and anyone can maintain copies of the code modified in
their particular way so no one's progress is blocked by others. The idea
of timed releases takes that issue off the table as well---a feature
either is on this release train or can make the next one.

If you are persuaded that authoritarian control by a central committee
the only form of governance which can create inclusive, productive
software projects and you are willing to impose this on all incoming
projects as a condition of their acceptance for incubation, you should
vote against us re-joining OSGeo. I am unable to know or control how
Geotoolkit governance will invent itself over the next six months and
would not be interested to constrain its evolution over the next several
years. One of my joys of collaborative enterprise is discovering how to
structure that collaboration with people I admire for effective,
productive work---as part of such efforts, I am discovering a better me.

When OSGeo started, I had the impression that it was forming as an
association of free software projects, each accepted on its own terms
with its own licensing and copyright assignment systems. Indeed, I
remember that diversity made writing a re-usable copyright assignment
document quite difficult. Now you seem to have decided there shall be
one homogeneous form of governance for all projects---by that I am
surprised. At least your decision on Geotoolkit will clarify, for future
projects, if this is your official policy.


> I understand there has also been a concept at times of GeoTools package
> maintainers being sovereign in their own package.  Sort of a local dictator.
> I am also concerned that this is contrary to the goals of OSGeo where
> new folks can join the project and have a reasonable degree of comfort
> that their voice will be heard.

How does an authoritarian central committee empower new comers more than
an assembly of authoritarian maintainers would?

The latter does have the distinct advantage of ensuring that the
authority actually is authoritative---the maintainer at least knows how
the code of their modules really works.


> I must confess that I'm not clear on the social implications of DVCS.

Yes, I am discovering that none of you have yet struggled to understand
the workflow, organizational, or social issues around this new
technology. That is surprising since every large scale free software
project of which I am aware is adopting one of these systems---I would
have expected your natural curiosity to lead you to think about this new
wave and its consequences.


>   1) Does it really have a sufficient community to flourish for some
>      time?

Only time can tell us what time will bring, no?

>
>   2) Is it really going to be able to operate in a community based
>      manner or is it essentially a geomatys fork?

Both? It starts as a Geomatys/Lsis/... fork and will undoubtedly grow
into a community run project. You should probably, as part of your work
as a member of the incubation committee, peruse the Geotools mailing
list archives. Go back a couple of years and read Martin's emails and
judge for yourself whether you think his language is one of community
building or one of a tyrant.

>
>   3) Does it have technical strengths that make it appropriate for
>      OSGeo to promote it?

I am sorry Frank but I cannot find any way to read this question from
you without it striking me as rude. First of all, it is your job to
decide on the worth of applicant projects, that is, after all, why you
are on this committee and this is exactly the work you are expected to
do when evaluating new projects. You are expected to go look at the
public face of the project, possibly peruse the online code
documentation, perhaps download the bundle and run the command-line
client and, thereby, to make up your mind. Secondly, what exactly I am
supposed to answer here? Could I possibly answer that this project, on
which I have spent several years already and plan to spend a significant
amount of the next few years of my life, is fundamentally uninteresting?
So please, either take the time to do your work or don't, but you really
should not start out by asking me to do that work for you.

Martin put the geo in geotools2 when he merged his geo-referencing code
into the project and over the past decade he has modernized and improved
those module. Similarly, he has developed a highly sophisticated
infrastructure for handling grid coverages, from multi-spectral remotely
sensed imagery to outputs from general circulation models ('climate
models'). Johann has resurrected the old renderer design of Martin's and
now has a most advanced renderer capable of handling sophisticated
styles based on the OGC symbology encoding specification and beyond.
Axel and his lab at the LSIS are adapting their 3D algorithms for ISO
geometry. Geotoolkit powers an SOS, a transactional CSW, a WMS and a
WCS. Geotoolkit also provides the library for some mapping JSF clients
we are building. Yes, the library may perhaps have a few 'technical
strenghts'. Frankly, I am confused that you are asking.

>
>   4) Is it going to be able to work within a governance model that is
>      going fit with OSGeo's concept of prudent management?

I have addressed this above.



The issue before you comes down to one of trust. No form of governance
will save a project from leaders who want to act as tyrants; indeed, my
experience suggests that attitude is much more important than structure.
So either you figure our who we are, how we work, and what we are doing,
and on that basis decide you trust us and that you want to bring us back
into OSGeo or you decide you don't have that trust and reject us.

Whatever you decide is great. We have set out on a road that has taken
us over ten years already and may take another ten to finish. We were, a
short six months ago, working amongst you so we thought we would
continue to work that way. If that strikes you as morally problematic,
then let us know that and we will play elsewhere.



Now I have now written entirely too much on this subject and hope to be
able to sign off. If you have directed questions which I can be expected
to answer succinctly, I will be glad to answer them; otherwise, I hope I
can stick to writing the GeoAPI 3.0 Specification for the upcoming OGC
meeting.


sincerely,
  Adrian Custer

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Daniel Morissette]

Adrian Custer wrote:
>
> How does an authoritarian central committee empower new comers more than
> an assembly of authoritarian maintainers would?
>

In a well balanced committee, there should be participants from
different roots and interests, a mix of developers and power users,
ranging from private business, academic, government, to hobbyists. With
such a mix, legitimate requests from newcomers should be of importance
to at least one or two members of the committee who will take the issue
and ensure it is addressed.

In the benevolent dictatorship model, if a newcomer's issue isn't in the
current scope of priorities then the newcomer is out of luck, period.

Simply put, a well balanced committee of N members gives N times more
chances for newcomer requests to be heard and addressed. Of course, not
all committee members have the openness of some successful dictators,
but still, at the end of the day, the chances to be heard by a balanced
committee are higher than by a single dictator.

>
> Yes, I am discovering that none of you have yet struggled to understand
> the workflow, organizational, or social issues around this new
> technology. That is surprising since every large scale free software
> project of which I am aware is adopting one of these systems---I would
> have expected your natural curiosity to lead you to think about this new
> wave and its consequences.
>

"...every large scale free software project...", Really?

Perhaps some concrete examples of well-known large scale projects based
on DVCS could help us see the light.

Finally, Paul raised an important *practical* question yesterday that is
not clear to me either. Since what matters to the users of a project is
the official release posted on the website and the binaries derived from
it, how does a DVCS-driven project work with respect to official
releases? If the official release ends up being what the dictator chose
to approve then how is that different from a centralized SVN/CVS server?
We just end up with a person as a central point of control instead of a
server, don't we?


Daniel
--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Vincent Heurteaux]

Hello ,

> Perhaps some concrete examples of well-known large scale projects  
> based on DVCS could help us see the light.

The first projects that are comming into my mind are :

        - Linux
        - Firefox
        - Java7
       
Vincent
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator