Right, I don't disagree with this. I am just saying that there are a lot
of good ideas and one man projects that will never have a large
community to support them because of marketing,
communications,visibility issues, not technical reasons, but that
doesn't mean we should throw the code away. There are lots of open
source projects that have a contrib directory as a place to collect
unsupported contribution that other people might find useful. If enough
people get exposed to them then a few might evolve into a full blow
project and community. But if they never have an opportunity to have
some visibility then the go sight unseen whether they gems or junk. I am
not advocating making all these into projects, just that we consider
some kind of project that does nothing more than collect OpenSource code
that works with existing OSGeo project code or might be a valid OSGeo
project if it were to grow and that that code has some minimal
requirements to be included in contrib that the submitter must meet. The
PSC for "contrib" would rule on appropriateness of a contribution and
that it meets minimal requirements and might determine what those
minimal requirements are.
Anyway seems like this would be valuable, but if no one else cares I'm
fine with that, too.
-Steve
It is likely that most of this code would never go anywhere but
Cameron Shorter wrote:
For young projects that are not ready for incubation we have previously
set up:
http://wiki.osgeo.org/wiki/OSGeo_Labs
For the rest of this topic, I think we should go back to the principles
of OSGeo and what makes it effective.
OSGeo (like Ubuntu) promotes the "best of breed" GeoFOSS software. It
helps focus users, and developers behind the best products, rather than
splitting energy thinly across many products.
And one of the key components for a successful project is to have a
healthy community behind it so that it will continue when the key
sponsor moves on. I don't think a meta project of unrelated small
projects provides such a community because the developers from one small
project won't necessarily be interested or skilled in the other projects.
The Openlayers/Geotools model of sponsoring smaller project does work
because there (hopefully) should be the interest and skill sharing
between the projects.
Stephen Woodbridge wrote:
An other thought on this might be a some kind of OSGeo "contrib"
project that is more focused on collecting projects likes Bob's into a
common repository with the hope that making these public might allow
some of them to spin-off into full blown OSGeo projects if there is
enough interest and community need for it.
This would not give the code OSGeo stamp of approval, but would just
be a holding place for potentially interesting code related to other
OSGeo projects that people might want to be able access and helps to
prevent potential gems from getting lost.
My guess is that it would still need some kind of PSC to decide what
is the gate to let things in and to make sure that the basic minimal
stuff required for entrance is done and to encourge others to pick and
run with ideas and spin-offs of the code being held. Something like
this would need to minimally have any code contributed assign its
copyright to OSGeo and state that it was infringement free or
something like that.
Something to think about.
-Steve W
Bob Basques wrote:
Jody,
I was thinking about a bit more separation in functionality than you
describe, but it seems like the same process could work.
I guess I'm trying to figure out a way to let smaller projects in the
door, and let the mainstay project leaders decide if the smaller
projects have enough merit to nurture further or not.
I have a few different things I've put together that use MapServer
as a service, but they are all seemingly small project. As an
example, I have a Raster distribution service based on MapServer that
we use to populate our engineering AutoCAD sessions, it's really just
some specialized scripting in the AutoCAD instance, but I'm sure
there are folks out there that would re-use if I put it out as a
project. I would just barely have the time to put together a basic
how-to for something like this and publish it, but it wouldn't get
much in the way of support focus because of my own time constraints.
I have something similar for Google ion the Works, as well as
Sketchup sessions. These smaller projects have all had great success
here internally, and are all built as standalone services so they can
be mixed and matched as the business needs require.
Some might argue that they are all one thing, while other might want
them to remain separated. Anyway, just some more thoughts on the
subject.
bobb
>>> Jody Garnett <[EMAIL PROTECTED]> wrote:
Hi Bob; you will find that a few of the open source projects nurture new
talent this way.
The GeoTools library has the facilities in place to allow new developers
to come online and start an "unsupported" module with the support of the
community. Each module in GeoTools is an entire project (often making
use of the same interfaces and so forth). When a module meets the QA
requirements it can be included in the GeoTools download for the general
public.
Is this what you had in mind?
I understand that some something similar to Jakarta is often requested
from the OSGeo foundation. Thus far the incubation committee has been
really focused on getting existing projects through our incubation
process (and defining what the expectations are for such projects).
Jody
Bob Basques wrote:
> All,
> I have a question about a possible way to get some smaller projects
> into the system without the requirements of going full bore (as I
> perceive it now) I'm not really targeting any project per se at this
> point, but . . .
> > What about have a "Super" project that can act as a sponsor for a
> smaller project. When I say smaller, I mean where there might
only be
> one, two or three developers. The end result being that the "Super"
> project basically vouches for the smaller project in some fashion for
> it to get some sort of OSGEO stamp applied to it. This could
> possibly be a criteria where some of the established vetting is
> handled via a voucher system, where other "Super" projects can add
> their credentials to the mix over time.
> > Just a thought, still a little muddled too, but it seems like
there
> might be something workable in the concept. Any other thoughts?
> > bobb
> > >
------------------------------------------------------------------------
>
> _______________________________________________
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
> _______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
------------------------------------------------------------------------
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
