MS RFC 10: Joining the Open Source Geospatial Foundation

Pericles S. Nacionales naci0002 at UMN.EDU
Mon Feb 6 14:45:38 EST 2006


My position (and UMN's) is that we move swiftly (option #1).  So, with 
the addition of all the comments Frank, Howard, and Daniel made to the 
RFC. I vote +1 to get this process in motion.

-Perry

Steve Lime wrote:

>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.
>
>.
>
>  
>



More information about the mapserver-dev mailing list