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