[Incubator] Off topic: Collaboration

Jody Garnett jgarnett at refractions.net
Tue Jan 22 13:00:30 EST 2008


A couple of thoughts (since this topic is part of my GeoTools report; as 
an area of weakness):
- If you back up one more step you will see the GeoAPI project which is 
how we try to formally collaborate between Java open source projects, 
any discussion that misses these interfaces needs to start again.
- I have not scene many actually changes for collaboration; two groups 
of developers need to have budget at the same time (or a funded code 
sprint needs to be set up). There are lots of places where collaboration 
makes sense (I have talked with the deegree team about graph and 
traversal code previously). The trick is we need to arrange for it to 
make cents.
- I am pretty sure that all of the software here is developed with tight 
deadlines :-)

One roll OSGeo can play is helping communication between projects. In 
the GeoTools community occasionally we have people delay their work (say 
on uDig) until another developer can find finding (for GeoServer) so 
that they can work together and both cut costs. If OSGeo can keep a line 
of communication open then the developers will at least know when they 
are both working on similar ideas.

Differences of license can be worked around; GeoTools often has code 
donations from GeoServer which is a GPL based project. You will also 
find GeoTools code forked into several GPL based projects. uDig and 
gvSig enjoyed several months of shapefile performance collaboration by 
competition (an example of open source being amazing; even when people 
can only see each others code).

Cheers and thanks for the thoughts,
Jody

> Hi Cameron,
>
> basically there is cooperation potential with all Java-based OSGeo 
> projects. As I see it these are at the moment:
> 1. GeoTools
> 2. gvSIG
> 3. Geonetwork OpenSource
> 4. Community MapBuilder
>
> I will discuss those four projects in the following. Please forgive me 
> if statements about the four projects are not correct at all times, I 
> do not know them in much detail so far.
>
> 1. GeoTools
> ------------
> deegree and GeoTools share many similarities, they are at the core, 
> Java libraries for geospatial applications with a focus on OGC 
> standards. There are many opportunities for collaboration and there 
> were several attempts to do so but I also have to say that so far all 
> of these attempts were not successfull. At the first look the projects 
> are so similar that someone wonders why collaboration here is so hard. 
> IMHO there are three main reasons:
> a) Some requirements are different. A good example is the need of 
> deegree for a complex feature model, a requirement that GeoTools 
> developed much later and with much less priority.
> b) The development process seems to be different: deegree is developed 
> for projects with tight deadlines and is in this way a very 
> "commercial" FOSS project. Quite often, decisions have to be made fast 
> and this leads sometime to less discussion via the list as there is on 
> GeoTools lists.
> c) The "not invented here" effect and other usual problems in 
> cooperation. ;-)
> Nonetheless I do not want to give up on this. Perhaps the fact that 
> deegree wants to join OSGeo opens new opportunities for cooperation 
> between the projects again. Perhaps some kind of "liasaon officer" 
> between the to projects would help here.
>
> 2. gvSIG
> Although deegree is a library, there also is by now a desktop GIS 
> (with similarities to gvSIG) under development. On a technical level 
> there is collaboration potential, the main problem here is that gvSIG 
> is published under GPL, while deegree under LGPL. This is the main 
> reason, why in the first place deegree started development of a 
> desktop component (the companies developing deegree have customers who 
> do not want to use a GPL-based desktop GIS program). Otherwise we 
> would have used OpenJUMP or gvSIG. On a technical level, here again 
> the problem is the complex feature model. There already were meetings 
> between people from gvSIG and deegree and support for complex features 
> seemed to be not on the top list of priority for gvSIG.
> In regard to the license problem, the cooperation here could be 
> "one-way", of GOS uses source code from deegree we would not run into 
> license problems.
>
> 3. Geonetwork Open Source (GOS)
> deeegre encompasses a metadata/catalogue component similar to GOS. On 
> a technical level there is good potential for cooperation, the problem 
> here is that GOS uses GPL while deegree LGPL.
> Here again, "one-way cooperation" (GOS uses deegree) could work.
>
> 4. Community MapBuilder (CMB)
> From the impression that I by now have, CMB shares a number of 
> similarities with deegree iGeoPortal, they are both web-based clients 
> for OGC web services. As CMB is published under LGPL there would also 
> be no licensing problems. It might turn out, that the respective 
> software architectures are too different for close cooperation, but 
> this will only be know if there is a more thorough analysis from bothe 
> sides.
>
>
> So, regarding the OSGeo Java tribe, I would say the most cooperation 
> potential exists with GeoTools and CMB as they share the same license 
> with deegree.
>
>
> Best regards,
>
> Markus
>
>
> Cameron Shorter schrieb:
>> Sorry for the slow response, usual excuses.
>>
>> Markus,
>> It is great to hear that a well established project like deegree is 
>> engaging OSGeo. I think deegree has a lot to offer the community and 
>> in particular I think it will benefit all if we see further 
>> collaboration between deegree and other OSGeo projects - something 
>> which I think has been one of the under-reported benefits of OSGeo.
>>
>> One of my standard questions for new projects is to discuss similar 
>> (OSGeo) projects and what opportunities there are for collaboration, 
>> or if not what are the barriers.
>>
>> The more collaboration, the more attractive the project is as a 
>> graduation candidate.
>>
>> -- 
>>
>> As I seem to bring up this question fairly regularly, maybe it should 
>> be included in the OSGeo Application page.
>>
>> Frank Warmerdam wrote:
>>> Folks,
>>>
>>> I'm pleased to announce that the deegree project has applied for
>>> OSGeo incubation.  The application form can be downloaded (in pdf) 
>>> from:
>>>
>>> http://trac.osgeo.org/osgeo/attachment/ticket/185/deegree_osgeo_questionnaire.pdf?format=raw 
>>>
>>>
>>> deegree is a Java framework including implementations of many OGC 
>>> and ISO
>>> standard geo interfaces.  The application was submitted by Dr. 
>>> Markus Lupp
>>> and I will ask him to join the incubation list if he hasn't already.
>>>
>>> Currently we have ten projects in incubation, so assuming we don't 
>>> want to
>>> raise our self imposed limit I don't anticipate bringing another 
>>> project
>>> into incubation immediately.  However, I am hopeful that at as many 
>>> as two
>>> of our current projects will be completing incubation soon at which 
>>> point we
>>> will be in a position to select new projects.
>>>
>>> The current application pending are:
>>>
>>> http://trac.osgeo.org/osgeo/query?status=new&status=assigned&status=reopened&component=Incubator&keywords=%7Eapplication&order=priority 
>>>
>>>
>>> GeoMOOSE
>>> JVNMobileGIS
>>> ORCHESTRA
>>> degree
>>>
>>> Best regards,
>>
>>
>
>



More information about the Incubator mailing list