[Incubator] Off topic: Collaboration

Cameron Shorter cameron.shorter at gmail.com
Tue Jan 22 14:47:01 EST 2008 

As an example of process,
I've witnessed a few of areas of collaboration that have worked between 
Mapbuilder and Openlayers.

At a BOF meeting at FOSS4G 2006, a number of Webmapping projects 
identified similarities between the projects. A general agreement and 
roadmap was set down on areas where the projects could share libraries.

Since then, both projects have adjusted their development to ensure they 
align with the general roadmap. It has been a slow process as the common 
libraries only get developed when funding becomes available.

In particular, Mapbuilder now uses Openlayers for rendering multiple 
data sources and Javascript Javascript Projections has been factored out 
of Mapbuilder and is being incorporated into Openlayers. Vector 
Rendering was something that both projects had just started working on, 
and we joined forces to work on it together.

 From a development/funding point of view, there is a short term cost 
and emotional scaring when collaborating. It is always quicker to solve 
a problem using your existing toolset, and it is emotionally hard to 
drop your hard written code and use someone else's instead. But in the 
long term, you gain not just new code, but developers willing to share 
maintenance.

So bottom line is:
Get together with other projects, identify similarities, and set a long 
term roadmap for collaboration. Then regularly liaise with the other 
project at a strategic level.

Jody Garnett wrote:
> 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,
>>>
>>>
>>
>>
>
> _______________________________________________
> Incubator mailing list
> Incubator at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/incubator
>


-- 
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html

More information about the Incubator mailing list