[Incubator] Incubator Application: deegree

Thu Jan 24 10:47:24 EST 2008

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.

best regards,

Chris

Jody Garnett wrote:
> 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,
>>>
>>>
>>
>>
> 
> _______________________________________________
> Incubator mailing list
> Incubator at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/incubator
> 
> !DSPAM:4005,47964c6021173668746562!
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/incubator/attachments/20080124/c4fb6cc7/cholmes-0001.vcf