[OSGeo-Discuss] Supporting new projects

[Bob Basques]

All,

I knew the comments were going to touch a nerve somewhere.  That's why I 
purposely kept things vague.

I don't agree 100% about the non-relevance though, overlapping stratgies 
were exactly what I was trying to comment on, and promote as a 
development method.  Our Project came out of our day to day work, and we 
though it of value to the community.   The discussion here was about 
supporting new project or not because of the perceived overlap, I was 
stating that we defintely had overlap and with which project, I don't 
see how the talking could proceed without naming things.

The support I would rally for from OSGEO, would be in the reviewing 
process, something along the lines of a para-professional (team??) 
taking a look at the project and reviewing for others so they can take a 
deeper look.  This is the exact type of thing that our project is 
missing, a promotions aspect.  It executes it's designed functions very 
well (we think).  Listing the catagories a project might be listed under 
and how it's functions differ from other packages of the same type.

bobb


Paul Spencer wrote:
> 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/ |
> +-----------------------------------------------------------------+
>
>
>
>
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>
>