[OSGeo-Discuss] Supporting new projects

[Christopher Schmidt]

(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