<html>
<head>
<style type="text/css">
<!--
body { font-variant: normal; margin-top: 4px; margin-bottom: 1px; line-height: normal; margin-left: 4px; margin-right: 4px }
p { margin-top: 0; margin-bottom: 0 }
-->
</style>
</head>
<body style="margin-top: 4px; margin-bottom: 1px; margin-left: 4px; margin-right: 4px">
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">Cameron (and others),</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">That bundling piece seems like it could become a burden in some instances, probably not a big deal once most of it's all figured out for the first time though, but passing on the knowledge of how to operate that bundling process seems like it will be difficult over the long haul. If there are no other options there, then I would like to add in an option for configuring on a USB/CD. I'm thinking there need to be some more structure put to this early on related to how the different types of project can work together. Concentrate on how to set up a plug and play environment for projects insinuate themselves into. What about those folks that want to add to the LiveDVD after the fact for example, this seems like a good way to get alignment of methods going over the long run.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">One the time thing, for some reason 3 years for everything seems like a really long time. One year seems to short, I think I would have shot for a two year total time span on things.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">One other item, who does what from the list, the last piece about the reference book seems like 100% OSGEO, but what about the other tasks, is there a split of some sort, what should it be.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">Overall, I think this is the right way to approach the future, but I would like to see a little more thought put into it before decisions are solidified.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">bobb</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<br>
<br>
>>> Cameron Shorter <cameron.shorter@lisasoft.com> wrote:<br> </p>
<div style="margin-bottom: 0; margin-top: 0; padding-left: 7px; border-left: solid 1px #050505; background-color: #f3f3f3; margin-left: 15px; margin-right: 0">
<p style="margin-bottom: 0; margin-top: 0">
I agree with Frank's principles below which have served us well to date,<br>and I think we should keep them.<br><br>I propose now that OSGeo and our software is maturing, we should<br>recognise the increased quality of our projects through the OSGeo brand.<br>I see this taking the form of increasing criteria for incubation (or<br>whatever we may decide to call the OSGeo Quality brand).<br><br>The format for increasing quality is something that we can apply<br>gradually and will need to have caveats as there are differences between<br>projects.<br>But I suggest a timeframe for quality criteria should include something<br>like:<br><br>within 6 months: 1 page flier describing the project<br>within 12 months: Packaging of project into LiveDVD  or debian, or osgeo4win<br>within 18 months: Tutorials on how to use core functionality for the project<br>within 2 years: Tutorials for all functionality<br>within 3 years: Training material incorporated into tertiary education<br>courses / OSGeo reference book<br><br>Frank Warmerdam wrote:<br>><br>> Folks,<br>><br>> My take is that:<br>><br>> 1) We have already decided we are not going to pick one "winner" for each<br>>    part of the stack and exclude others.  This was implicit in MapGuide<br>>    and MapServer being founding projects of the foundation.  So we are<br>>    clearly going to be open to multiple projects that fill roughly the<br>>    same role.<br>><br>> 2) For our OSGeo marketing message to be effective I think we need to try<br>>    and restrict ourselves to quality, good-value projects.  Pushing a<br>> weak<br>>    project to some extent will devalue the others.  I have mostly chosen<br>>    to interprete quality in terms of a healthy supporting community<br>>    and projects that are reasonably mature.<br>><br>> 3) In the past we have not tried hard to integrate things into a<br>>    consistent stack, but we have shown some bias towards projects<br>>    that leverage other OSGeo projects (and to encourage this), and<br>>    also we have shown more interest in projects that "fill a gap".<br><br><br>--<br>Cameron Shorter<br>Geospatial Solutions Manager<br>Tel: +61 (0)2 8570 5050<br>Mob: +61 (0)419 142 254<br><br>Think Globally, Fix Locally<br>Geospatial Solutions enhanced with Open Standards and Open Source<br><a href="http://www.lisasoft.com">http://www.lisasoft.com</a><br><br>_______________________________________________<br>Incubator mailing list<br>Incubator@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/incubator">http://lists.osgeo.org/mailman/listinfo/incubator</a><br>
</p>
</div>
</body>
</html>