[Incubator] New Application: GeoToolkit

[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