[OSGeo-Discuss] Supporting new projects

[Paul Spencer]

On 30-Sep-07, at 6:21 PM, Tamas Szekeres wrote:

> 2007/9/30, Paul Spencer <pspencer at dmsolutions.ca>:
>> What do others think about this?  Should OSGeo be in the business of
>> helping new OSGeo projects get off the ground?
>
> Absolutely. That could allow the identities to focus on establishing
> the core funcionality much easier without having to bother with
> creating the infrastructure behind that.

this is only part of it.  More than infrastructure (which we could  
easily just point projects to sourceforge for), I am hoping we can  
build a communications channel that allows new projects to attract  
interest and feedback

>
> Furthermore I have the following additions/considerations according to
> the responsibilities of the OSGeo from this aspect:
>
> 1. OSGeo might establish the possibility to accept new project plans
> in a well formaized manner.

In so much as we are guiding them to launching their project, not to  
filtering or eliminating them before they even get started

> 2. OSGeo should form a committe (or extend the roles of the incubation
> committe or the role of the charter members) to decide whether a
> project plan will possibly have a fair amount of interest regarding to
> the functionality and technology it has. I personally would prefer if
> a wider range of the community would be involved.

Here I think the 'best of breed' approach will provide all that is  
needed.  If we provide support in the form of communications, users  
will try out new projects if it aligns with their needs.  If the idea/ 
project is good, it will grow a community of users and developers.   
If not, it will die or remain a one-person project.


> 3. OSGeo should provide the necessary infrastucture for the project
> initiatives so that they could proceed in approaching  a stable
> project state (an estimated plan with the milestones should also be
> gathered)

This is a possibility, but one that potentially stretches our  
existing resources.  If it is feasible to have a 'zero-effort'  
project creation process then fine.  If not, I would be happy to just  
provide a list of places where a new project can set up shop.

> 4. OGGeo would use some measures around whether the project is making
> a good progress and the community around that is somewhat increasing.

I don't think this is necessary.  Part of the initial advice can be  
instruction on how to approach the IncCom when the project feels that  
it has developed enough momentum.   IncCom can provide advice on  
whether incubation is appropriate or not.

> 5. The neglected projects are to be declared as obsolete by the OSGeo
> (by using a voting process).
> 6. The project initiatives having a stable release could apply for
> starting the incubation process for getting the OSGeo "officially
> supported" state.
>
> More comments:
>
> - OSGeo should continue to "officially support" only the incubated
> projects having a fairly considerable community around each and
> possibly continue to be supported in the future as well.
> - As the number of the projects is increasing OSGeo should start
> providing a better categorization between the projects and their
> functionalities/technologies for guiding the new users to make the
> selection easier an find the differences between them in connection
> with the desired specifications they have.
> - Project duplicates should be avoided, new incremental
> functionalities should be stirred towards the existing projects as
> much as possible.


I respectfully disagree on your last point.  I personally believe  
there is great benefit in encouraging new approaches.  Mapnik is a  
good example, we would have discouraged its development in favour of  
mapserver.  OpenLayers vs ka-Map is another example.  There are many  
others.  In many cases, a complete rewrite is desirable to take  
advantage of new ideas/technologies etc and existing projects often  
don't want to undertake a complete rewrite.

Paul

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