MS RFC 10: Joining the Open Source Geospatial Foundation

[Steve Lime]

I'm to the point where I think we should be looking at option #1. We
begin to loose credibility with #2, and it is important that MapServer become
a strong player in the foundation and that only happens by being amongst
the initial members.  The bootstrap board is top notch- I trust those guys.

Plus, look at the others already in. Grass, GDAL, MapBender, MapBuilder and 
OSSIM (this suprised me).  I really respect all of those projects. I am suprised
they could just simply join. I think we are taking a very proactive and open
approach- makes a lot of sense.

Plus we always have option 3 at our fingertips at any time- the fork.

Steve

>>> Howard Butler <hobu at IASTATE.EDU> 02/06/06 10:53 AM >>>
>1- Be one of the founding projects of the foundation. This means 
>making our decision to join solely on the spirit of Saturday's 
>meeting and the decisions made so far, which includes the 
>understanding that in big part the foundation will be defined from 
>the commonalities between the founding projects... kind of 
>reverse-engineering the foundation from the projects. There is a bit 
>of risk but this gives MapServer a chance to influence the direction 
>that the foundation will take, and in the end get a foundation that 
>will better suit its needs. Actually, it's an opportunity but also a 
>responsibility since the members of the founding projects are 
>expected to work together to help define the foundation.
>2- Wait and see, and decide to join only once everything about the 
>foundation is laid out clearly on paper and we know that it's safe to join.
>
>Well, we should not forget option 3:
>
>3- Never join and continue on our own.
>
>
>Should the RFC be ammended to clearly state which of #1 or #2 we're 
>talking about? I think you meant #1 (that's what I'd like 
>personally), but that's not very clear in the RFC.

Yes, the RFC was more about scenario #1 than scenario #2.  The RFC 
should be amended to reflect this.  Sitting on our hands and waiting 
for #2 to come to fruition means a few things in my mind:

- Our project's ability to influence the coalescence of OSGeo is 
extremely limited.  This may or may not be a big deal.  For example, 
if the foundation prescribes some sort of 
website/documentation/infrastructure component and this is inflexible 
after I've spent all this time on the mapserver website and can't 
reuse it in the context of the foundation, I have an issue.  There 
may be more things like that.  Or maybe I'm overreacting.

- Our project sits in purgatory while we wait.  Software and 
development-wise we can continue to move forward.  I don't know that 
we can do too much project-wise (website, infrastructure, project 
steering committee development, etc).   If we're not participating, 
our ability to accommodate any of the uniqueness of the organization 
of our project in the foundation becomes very limited.  Some of those 
things (like project steering committee) we don't even do now.  If we 
were to eventually go into OSGeo, we would want to make sure things 
are congruent with that organizational structure so we don't end up 
re-doing a bunch of work.  At the risk of having to redo things, we'd 
most likely do nothing.

>Another clarification for the RFC: perhaps it should be mentioned 
>somewhere that if it joins then MapServer would be expected to move 
>its project infrastructure (CVS, website, lists, etc.) to the 
>foundation at some point in time.

Please add this stuff to the RFC.  It was kind of alluded to, but not 
clearly spelled out.