[OSGeo-Discuss] Supporting new projects

Mon Oct 1 15:14:02 PDT 2007

Paul,

As reading the replies up to now I continue to think what OSGeo can do
is more adding some technical expertise rather than creating a venue
and a project advertising board.

Currently I feel a significant power around the users and developers
forming the OSGeo to decide or at least give some point of
consideration whether a project should be brought to alive or not,
definitely. Therefore it would be prudent for the developers/designers
to have been measured with the ideas by a broader community before
creating a new project. This would be good for the project and the
OSGeo as well, because:

1. The designer could avoid spending quite some time and money for a
functionality they already have, but no one have ever mentioned about
the possibilities by pointing them to a right project's direction.
2. The new project could make sure that the idea behind that is
compelling enough to grow a large community around that. Having the
support of the majority of the developers and users of OSGeo could add
the necessary initiative to that.
3.  The OSGeo could get to know whether we've lack of the
functionality in some areas or the relevant projects should solve some
substantial issues they still haven't been aware of to make their
existing functionality usable.
4. The OSGeo could have some feedback what is happening behind the
scenes of the projects around the open source geospatial area. I'm
pretty sure getting to know about a full featured new project with
it's functionality is more frustrating for the existing projects than
getting up to date information about the ongoing projects and how
those will complement the current functionality.

Certainly the new project may decide to go on it's own way an omit all
of the information the OSGeo could provide, however that might
possibly cause potential difficulties when they'd like to apply for an
official support by the community one day.

Having the infrastructure inside the OSGeo or not is not the biggest
issue. In my opinion allowing to host the new projects inside the
OSGeo could save some efforts from the developers when they decide to
join to the infrastructure. Doing so after the incubation is somewhat
painful as far as I've experienced that with some already incubated
projects. However, AFAIK, it's not compulsory either to join to the
infrastucture after the incubation process.

I think OSGeo could support projects with similar functionalities as
well, but we should make sure about the extra information how these
projects behave in a different way for the user. For example those
might be different in technology (like java or C/C++ based) or provide
a different user experience etc.

OSGeo should only support those open source geospatial projects that
are definitely incubatable by the means those'll someday get the
"officially supported certificate" from the community.

Best regards,

Tamas

2007/10/1, Paul Spencer <pspencer at dmsolutions.ca>:
>
> 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/ |
> +-----------------------------------------------------------------+
>
>
>
>
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>