[Incubator] New Application: GeoToolkit

[Christopher Schmidt]

On Tue, May 26, 2009 at 10:08:29PM +0200, Martin Desruisseaux wrote:
> Christopher Schmidt a écrit :
> >On Tue, May 26, 2009 at 07:47:13PM +0200, Martin Desruisseaux wrote:
> >>The thing that can scare Geomatys to the point of staying out of 
> >>OSGeo would be that someone else takes Geotoolkit code and push their 
> >>modified flavor of it as if they were the main author (they don't need to 
> >>said that explicitly - I have meet last automn developers of the gvSig 
> >>project who were convinced that the GeoTools referencing module has been 
> >>wrote by an other compagny), getting contract at the expense of Geomatys.
> >
> >Again, how does OSGeo play or not play a role here? That can happen
> >without a project being an OSGeo project, and the choice of tools and
> >governance model seems to encourage it to some extent. With dictatorial
> >style source code control and community governance, you are seeking to
> >excercise strict control over the codebase. This is reasonable, but is
> >likely to encourage companies who wish to invest to seek other avenues
> >for their investment -- whether that's forking or not.  
> 
> Our concerns are based on past experiences. The credit received outside a 
> small circle of developers is often more a factor of communication power 
> than work effectively done. This is part of the rules of Open Source, but I 
> was thinking about something slightly different. Could OSGeo play the role 
> of someone that "equilibrate the power" between the projects that it host? 
> What I try to express by "equilibrating" is to make sure that, if someone 
> ask for an improvement in one particular area of a project, OSGeo know and 
> take in account the fact that this area of project "A" actually come from 
> project "B". It doesn't mean to give automatically the contract to "B", but 
> to avoid the situation were that fact was simply unknown.

I don't feel that this is the responsibility of OSGeo. I would be
strongly against OSGeo playing this role with any projects.  

> To be really frank, my sentence was worded like a general case scenario but 
> my real concern was specifically about the GeoTools - Geotoolkit 
> relationship. It may be me who is not yet appeased as I should - and my 
> concern is not about preventing GeoTools from recycling code (quite the 
> opposite I would feel honored if it happen). It is about consciensiousness 
> that we don't have the same marketing power, that (I believe) we can be 
> recognized on the merit of the library itself, but this effort can be 
> vanished if our work is absorbed by GeoTools to the point of making us 
> invisible.

Again, I don't think that preventing this is the role of OSGeo. Ensuring
that projects are meeting the requirements of the license of places that
they obtain code from is a perfectly reasonable task -- though generally
I'm completely in support of leaving this up to the projects -- but
stepping in to say "You need to give GeoToolkit credit for code that you
are using which was written for the GeoToolkit project" would just be
silly. The copyright notices are likely required to be in place, and
anything beyond that would be well beyond the role of OSGeo as a
foundation.

If you don't want people to reuse your code -- again, in accordance with
the license -- then don't make it open source. (And if you want them to
follow a more strict set of rules, you might choose to create a more
strict license -- though without a nice lawyer behind you, you run a
pretty significant chance of that making it 'not open source'.)

> >If you're really worried about someone forking your code and being more
> >successful with it than you are, then it might be that you're doing
> >something wrong -- but I don't see how being an OSGeo project would
> >affect it in either direction. 
> 
> I will answer this question in a private email, not because it is impolite 
> in any way but because it involve strategic concerns on our side.

If it's not relevant to OSGeo as a whole, there's no need. My point here
was to understand how this particular set of statements might affect
other projects -- not to understand how GeoToolkit intends to do
anything, specifically. I want to make sure I understand possible
concerns about why a project might not want to be incubated into OSGeo.
Your previous email indicated that you had such a concern, but it seems
that your concerns here are irrelevant of whether you become an OSGeo
Project or not, so I'm good.

Thanks,
-- 
Christopher Schmidt
MetaCarta