[Incubator] New Application: GeoToolkit

[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