[OSGeo-Discuss] Supporting new projects

[Paul Spencer]

I would like to encourage this discussion to be less about specific  
projects and more about the general concept of providing new projects  
a place to get started.  This type of discussion (the one below) also  
needs to happen, but at a project-specific level.

I would encourage Bob to bring his list of concerns/differences of  
opinion to the openlayers dev mailing list where the pros and cons  
can be discussed in a level of detail that might otherwise nauseate  
others :)

At a generic level, I am of the opinion that projects have design  
goals and architectures developed to suit the goals.  I believe that  
it is possible to have many different approaches to solving a problem  
and by always encouraging folks to look at existing projects, some  
interesting new approaches may not be considered.  As much as Chris  
(and I for that matter) like OpenLayers, it is possible that someone  
could have a better idea for how to approach the problem it solves  
and that this new approach would not fit OpenLayers for any of a  
number of reasons.  If we didn't encourage this, we'd still have ka- 
Map and OpenLayers wouldn't exist.

Returning to my original point, then, should OSGeo provide support  
for getting new projects off the ground?

Cheers

Paul

On 1-Oct-07, at 1:29 PM, 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,
> -- 
> Christopher Schmidt
> Web Developer
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+