Re: [OSGeo-Discuss] Incubator Sponsor idea.
cc:ed to incubator, but please reply to the discuss list... 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? Bob, Something like this approach has been taken for the MetaCRS project. http://wiki.osgeo.org/wiki/MetaCRS The MetaCRS effort is an attempt to have a single PSC run a sort of federation of related projects. In this case the coordinating theme is coordinate systems (reprojection, dictionaries, datum shifting, CRS description translation). But the components (CS-Map, PROJ.4, proj4js, and libgeotiff) are initially fairly independent activities with relatively few shared developers or direct cooperation. In the case of MetaCRS there is an intent for them to grow somewhat closer, in particular in sharing coordinate system dictionaries. Another approach would be for a smaller project to place itself under the administration of an existing official project that is somewhat related. For instance, I could imagine a web framework like Chameleon that is MapServer oriented, might ask to be considered part of the MapServer project, and subject to it's PSC. I had contemplated doing this with libgeotiff within the GDAL project for a while, for instance. We do need to be careful, I think, that we aren't just creating shells with no concept of community in order to get around the incubation process which is aimed at developing genuine well functioning communities around projects before giving them an OSGeo stamp of approval. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Incubator Sponsor idea.
This is an interesting idea. I think it would have to be a case where an existing OSGeo project (I think what you're calling the Super project) expects this smaller project to have an important future as a viable OSGeo project. The PSC of the sponsoring project (say Mapserver, Mapguide or OpenLayers) would have to be willing to invest some time in nurturing this project towards the start of an incubation process. I think we would want to make it clear however that these smaller projects are not OSGeo projects -- as this would dilute the value of projects that have graduated incubation and are recognized as strong healthy projects. This is one of the most important roles for OSGeo -- to help provide legitimacy to projects for those outside looking into the OSGeo domain. There have been a few projects that have already started down this path -- but there really isn't a lot of structure in place to define how this would be done. It might be interesting to have for the future though. Dave On 12-Sep-08, at 11:41 AM, 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
Re: [OSGeo-Discuss] Incubator Sponsor idea.
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
Re: [OSGeo-Discuss] Incubator Sponsor idea.
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
Re: [OSGeo-Discuss] Incubator Sponsor idea.
Frank, Your last point would seem to work both ways. I see the idea as a way of solidifying project integration aspects vs making them into the gooey stuff inside of the Shell. :c) bobb Frank Warmerdam [EMAIL PROTECTED] wrote: cc:ed to incubator, but please reply to the discuss list... 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? Bob, Something like this approach has been taken for the MetaCRS project. http://wiki.osgeo.org/wiki/MetaCRS The MetaCRS effort is an attempt to have a single PSC run a sort of federation of related projects. In this case the coordinating theme is coordinate systems (reprojection, dictionaries, datum shifting, CRS description translation). But the components (CS-Map, PROJ.4, proj4js, and libgeotiff) are initially fairly independent activities with relatively few shared developers or direct cooperation. In the case of MetaCRS there is an intent for them to grow somewhat closer, in particular in sharing coordinate system dictionaries. Another approach would be for a smaller project to place itself under the administration of an existing official project that is somewhat related. For instance, I could imagine a web framework like Chameleon that is MapServer oriented, might ask to be considered part of the MapServer project, and subject to it's PSC. I had contemplated doing this with libgeotiff within the GDAL project for a while, for instance. We do need to be careful, I think, that we aren't just creating shells with no concept of community in order to get around the incubation process which is aimed at developing genuine well functioning communities around projects before giving them an OSGeo stamp of approval. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ 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
Re: [OSGeo-Discuss] Incubator Sponsor idea.
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
Re: [OSGeo-Discuss] Incubator Sponsor idea.
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
