[Incubator] Incubator Application: deegree

[Jody Garnett]

Hi Markus, I agree that this is a great write up and it would make a 
good blog post/debate.

One area I would like to ask for clarification on is this... Going 
through incubation is a fine time to take stock on how a project can 
collaborate better in the future, but I don't think incubation is the 
correct time to try and correct areas of duplication. I am much more 
interested in the basics; is the license open source, does the project 
have procedures in place for people to join and contribute and control 
the project, do we know what is in the code base etc...

I would not like to see a project hesitate to join OSGeo simply because 
they did not manage to collaborate with the first couple of projects 
through the gate; a better time to check would be:
- when a project asks our advice about starting up
- as part of a yearly report

If we are going to promote cross project collaboration we may want to 
choose a different venue rather the incubation process.
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,
>>
>>
>
>