[Incubator] Incubator Application: deegree

[Frank Warmerdam]

Chris Holmes wrote:
> Personally I'm actually in disagreement - I think collaboration with 
> other projects should be a requirement of incubation.  I realize that 
> I'm probably in the minority here, and I don't actually want to 
> discourage deegree from becoming a part of OSGeo.
> 
> But when we originally started I had felt that being an OSGeo project 
> meant a high level of collaboration and cooperation, not merely the 
> 'potential' for cooperation.  To me the 'the basics' from a superficial 
> level are not sufficient for making truly open collaborative projects 
> with multiple supporters - the only way to actually tell this is if 
> there is already a strong community of outside contributors.  My 
> original view was that OSGeo would only take on projects that were very 
> well on their way to this, though incubation could be a way to indicate 
> a greater desire for this, but that projects would not graduate 
> incubation unless they really had an ecosystem past the founding group. 
>  In my mind not doing this dilutes the OSGeo brand to be just a bit 
> above sourceforge.  And I see the incubation process as the only place 
> where promoting cross collaboration has any 'teeth'.
> 
> I've personally put in an inordinate amount of time trying to 
> collaborate with several other projects and have been burned by lots of 
> abstract talk that quickly turns in to nothing as soon as any real 
> technical work is involved.  But I've also participated in a number of 
> successful collaborations, and the defining factor for success has been 
> the projects that actually already have outside contributors.  But I've 
> not put in enough time in to the incubation committee to give my voice 
> any weight, so take this all with a grain of salt.  I just wanted to 
> throw my two cents in.

Chris,

I feel there are two parts to what you are saying.

(1) is that projects need to be open to contributions and participation
from folks outside the initial core ... especially outside an initial
founding organization.

(2) is that projects need to be prepared to collaborate with other
projects.  Collaboration could be a variety of things I suppose, but I
presume mostly we mean sharing some code components rather than duplicating.

I agree wholeheartedly that the incubation process is not complete if
(1) has not been achieved.  I think (2) is very desirable and will even
often occur fairly organically once (1) is achieved.  But, we as an
incubation committee have not made it a priority nor am I certain that
we ought to.

I will say that forced collaboration - especially early on - was often
seen through the prism of whether we would force MapServer and MapGuide
to merge.  As you can imagine there were some sensitivities in this regard
and so we mostly took a kid-glove approach to the matter - hoping to setup
conditions for cooperation but not trying to force the matter.

So, based on that we accepted that we would have some projects that were
quite duplicative (MapServer and MapGuide, to some extent Mapbender,
MapBuilder and OpenLayers, FDO and GDAL/OGR).

The alternate approach would have been to try and add projects in a way
that formed a coherent stack with a "best of breed" component for each
aspect and trying to minimimize duplication.  As you can imagine this
would have required quite a bit of engineering as well as lots of ego
bruising as projects are dismissed as not making the cut, and other
projects are forced into a particular puzzle hole.  Honestly, as an
organization we just don't have the leverage and resources to make this
sort of thing happen (IMHO).

All that said, I think it is very healthy for us to do what we can
to encourage collaboration and sharing at the code level between
projects.  I think it is also fair for us to use willingness to
collaborate and strategic 'stack building' as criteria when selecting
projects for incubation.

 From the Java side of the world, I often boggle at the fact that
GeoTools doesn't get more use in big projects like gvSIG, deegree
and JUMP.  I've heard complaints about appropriateness of the feature
model, but surely there would still be useful components that could
be shared - projections engines, low level vector format translators,
and raster translators for instance!

I wonder if it would make sense to have a "Java Geo" summit at the
next FOSS4G where key representatives of all the major Java projects
would attend in an attempt to find at least a few components there is
interest in sharing, and agreement to have them live within GeoTools.
If there are impediments to making this work, then hopefully we could
identify them and resolve them.

Of course, this isn't really the right place for me to be putting in
my oar, since it isn't my world except to the extent I'd like there to
be one Java interface to GDAL that gets widely used!  I feel like this
is something the Java community needs to get itself together on.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org