[OSGeo-Discuss] Supporting new projects

[Bob Basques]

Chris,

Ahh crap, I knew this was going to happen, the questions I mean.  :c)  I 
can continue with the detail offline if you like too . . .

I don't know how much detail you want to get into here, but we've been 
reviewing some of the code with regard to implementing some aspects in 
our package that deal with the tile services and optional reading and 
outputting of data. 

The group on this end has some reservations about how the code was put 
together and how we want to extend it, if possible.  It's about a 50/50 
right now, and still in the discussion phase as to whether to use the 
OpenLayers code or go a separate route.  Just about all of your points 
below have been discussed on our end.  We've been trying to think about 
how to best list those concerns and not seem overly critical of 
OpenLayers which seems to have a loyal following.  It's why we looked in 
the first place and are looking again now.  We also did some looking 
during the early phases of our project, but OpenLayers was no where near 
capable of doing the things that it does now.  The reading/writing 
aspects are the plus aspect that we're looking for from OpenLayers.  
While the principals don't require all of these types of capabilities, 
it is understood that they will help along our project towards general 
acceptance.  In the end, maybe we just stay a niche product and leave it 
at that. 

It's out there now with Version 1.0.0 released, and ready for flogging 
by others.  If we don't get any bites, then fine, better than not trying 
to let others look at all though.

It's still in it's open-source infancy however, but you can see the 
project at::  http://www/geomoose.org/moose

bobb




Christopher Schmidt wrote:
> (I'll disclaim this by saying that OpenLayers is one of the projects I
> think of as 'my' open source projects: OpenLayers, TileCache,
> FeatureServer. However, I think that I could make the same argument for
> other libraries that are not mine as well.)
>
> On Mon, Oct 01, 2007 at 11:35:58AM -0500, Bob Basques wrote:
>   
>> Also, I believe that there are some flaws with the coding approach in 
>> some cases for OpenLayers.  I'm trying not to downplay Openlayers here, 
>> but I believe that Open Layers is at the point of a re-write as well. 
>>     
>
> I'm wondering what makes you think that. Is it something that has been
> said, or do you feel this way from observation of the code or something
> else?
>
> For the record, although I do feel that OpenLayers can only last another
> 6 months or so before we go to version 3.0 (though I'd love to make it
> last longer), even when we do so, by the time we do, it will probably be
> very similar to Python's setup -- you write your application for 2.x,
> turn on debugging to ensure there are no deprecation warnings, and if
> there aren't, then you can probablye switch to 3.0 without any problems.
>
> I can't say that this will be the path for sure, but I highly doubt
> there will be a substantial rewrite of OpenLayers in the next 12-18
> months.
>
>   
>> Recently we've been discussing using the OpenLayers tiling "get" methods 
>> for incorporation into our package, but some concerns about memory leaks 
>> and coding methodologies are cause for concern by our team.
>>     
>
> These types of things are great to share between projects, and sharing
> them might lead to alleviating the concerns on both sides -- either by
> resolving the issues within OpenLayers, or in the worst case, confirming
> the status is the way you think it is, thus leading to a sounder call on
> this type of decision. A project which doesn't reach out like this is,
> in my opinion, one which should be carefully considered when approaching
> incubation: much of the purpose of OSGeo and the community of Open
> Source developers is to establish the bonds needed to ensure that the
> products coming out are the best they can be.
>
> If someone is doing something similar to OpenLayers, and is implementing
> the same wheel simply because they are unable to make OpenLayers do what 
> they want given its current state, I think they are likely to be passed
> up as time goes on. OpenLayers has grown a large -- and growing daily --
> community. Part of the reason is because we have taken an active attempt
> to reach out to similar projects and offer to maintain the functionality
> they are using for them.
>
> Many OpenLayers use cases are, for example, similarly or better met by
> the ka-Map code. To help out users looking for OpenLayers-like ease of
> use and ka-Map like tile loading, OpenLayers implemented and supports a
> ka-Map layer class to display data from ka-Map tiles, and the OpenLayers
> community -- via myself and Schuyler Erle -- built TileCache, an
> alternative to ka-Map's tiling engine.
>
> Neither will solve all cases for all users, but they have both helped to
> increase the community around OpenLayers. In some cases, it's possible
> that this has smothered another community (though that has never been
> intentional!), which is something that OSGeo needs to be careful of
> happening to projects which pass through incubation.
>
> The same has been done with WorldWind tile access, with vector drawing,
> with so many other things: working together with others doing the same
> thing is one of the biggest reasons, in my opinion, that OpenLayers has
> grown its community. Without that community, the project would not be
> sustainable -- and without the efforts put forth to work with other
> software, and to solve other problems, that community wouldn't exist.   
>
>   
>> In short, pointing potential users at any one application/package is not 
>> going to promote innovations and the overall code stack will suffer 
>> because of it.  
>>     
>
> I agree. But OpenLayers isn't an application. Pointing potential users
> at only applications using GDAL for raster data access does not, to me,
> seem to limit innovation. 
>
> Of course, OSGeo is open to more than just one project in the same
> space. FDO and GDAL/OGR are in a similar space, but both are undergoing
> or have undergone incubation.
>
> The community around a project is far more important. Is it
> self-sustaining? Is it likely to last? As OpenLayers grows -- and
> continues to improve -- will other projects which compete with it
> survive? Is a project different enough that it will have a different set
> of users -- different enough that OpenLayers improvements and expansions
> won't snuff it out?
>
> Oftentimes, the answer is "Yes." Other times, the answer is "Maybe we
> should change our tactic." MapBuilder has recently been working on
> creating a build which uses OpenLayers as the map rendering library.
> ka-Map has done the same thing. DM Solutions Fusion project has done the
> same thing. All these are building application-level functionality on
> top of OpenLayers -- which means that as OpenLayers improves, these
> other projects will also be able to improve. That is an important
> consideration, in my opinion, and one that any project which is directly
> competing with OpenLayers at the library level may want to ask itself.
>
> I say this not because I think OpenLayers is the best at what it does.
> Other libraries have a smaller Javascript footprint, a smaller memory
> footprint, a more concise object model, less dependancies on external
> code, easier usability, etc. I say this because I think that as time
> goes on, OpenLayers will improve faster than a project which can not
> sustain a vibrant and growing community. 
>
> 1 year ago, I wouldn't have advised that anyone use OpenLayers for
> mission critical tasks.
>
> 6 months ago, I would have advised you would need to spend a fair amount
> of time understanding it to get use out of it.
>
> 3 months ago, I would have said you would need to be aware of it's
> limitations.
>
> Now? Now it's one of the premier places that people look for vector
> editing in the browser. It's got support for parsing and saving out a
> number of geographic information formats. Now it's got hooks so that it
> really is a library -- and can be treated like one, underlying other
> applications. Now it's got a vibrant community growing by dozens of
> people every week. Now I'm working with my employer to make it the
> primary search interface to our enterprise product.
>
> 1 week ago, I might not have advised it for a number of different things
> -- for example, if you wanted client side reprojection support, I might
> have pointed you to Mapbuilder, or some other client. 
>
> But now I don't have to, because there is a huge amount of work being
> done in OpenLayers to support exactly that. 1 week ago, I would have
> targeted this to 3 - 6 months in the future. But Mike Adair, building on
> his work with the MapBuilder project, came through and built it -- not
> in a week, but in a day, so far as I could tell. Now, OpenLayers can
> have real client side reprojection support.
>
> This single case can be expanded to dozens of others I can share -- but
> it wouldn't change the fact any more than I've already stated.
>
> There is room for many other web mapping applications. There may even be
> room for other web mapping libraries. But they better have something
> htat's siginficantly different from OpenLayers -- because if they don't,
> eventually, they may well get passed by. It might well be better to help
> improve OpenLayers -- we're very open to that! -- than to develop it on
> your own.
>
>   
>> Making the strengtha and weakness know would be a much 
>> better approach.  
>>     
>
> I think the biggest thing OSGeo needs to consider when taking in
> projects for incubation is if they have longevity. What's the 'bus
> number'? Is it maintained by a single person -- and if that person wears
> out, who's next? That's far more important to the future of a project
> than whether it has competition or not. 
>
> Regards,
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20071001/975af9d4/attachment-0002.html>