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

Adrian Custer adrian.custer at geomatys.fr
Sun May 24 08:15:35 EDT 2009


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.


More information about the Geotoolkit mailing list