[Incubator] New Application: GeoToolkit

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