[Incubator] New Application: GeoToolkit
hobu.inc at gmail.com
Sun May 24 12:49:35 EDT 2009
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  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
> 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?
More information about the Incubator