(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 [email protected] http://lists.osgeo.org/mailman/listinfo/discuss
