[Incubator] Governance and OSGeo Projects

Tue Apr 11 17:14:47 EDT 2006

I'd prefer to start with guidance and policy consistent with our  
goals rather than trying to impose some sort of pass/fail criteria on  
existing and mature projects.  If we run into serious issues or  
contention then we can provide a path to discuss this within the  
community and potentially at the board level to see if action is  
required or prudent given our overall objectives.

I've been impressed by the lack of controversy and the degree of  
cooperation in all of the OSGeo discussions.

In terms of governance we have some common sense guidelines that we  
could all quickly agree on:

Projects should manage themselves striving for consensus and  
encouraging participation from all contributors - from beginning  
users to advanced developers.

Projects should document how they manage themselves

Contributors are the scarce resource and successful projects court  
and encourage them

Projects are encouraged to adopt open standards and collaborate with  
other OSGeo projects

Projects should maintain developer and user documentation
Projects should maintain a source code management system - svn or cvs  
preferred
Projects should maintain a discrepancy tracking system
Projects should maintain project mailing lists
Projects should actively promote their participation in OSGeo
Projects are responsible for reviewing and controlling their code  
bases to insure the integrity of the open source baselines
Projects are encouraged to adopt OSGeo look and feel, branding, logos  
on their project sites
Projects are encouraged to participate in OSGeo standardization  
efforts to present a common interface for OSGeo visitors and members

The OSGeo will in turn attempt to make available the best of breed  
open source collaborative tools and resources to support those  
efforts, if we offer better tools and resources projects will  
naturally migrate to the better implementations.

I'm sure I've missed several important points, the main point being  
that we lead vs control.

New projects compete for our approval with the same guidelines -  
hopefully they will be included based on their perceived value to the  
OSGeo overall goals and objectives.

Mark

On Apr 11, 2006, at 4:33 PM, Frank Warmerdam wrote:

> Folks,
>
> I am wondering what our expectations are for Project Steering  
> Committees
> and how they operate.  I have been assuming we would encourage  
> projects
> to adopt something like the Apache style with a consensus based voting
> approach and a generally egalitarian approach for anyone accepted  
> into a
> PSC.
>
> In the case of MapServer we adopted RFC-1 defining the operation of
> the PSC last summer.
>
>    http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1/
>
> Generally speaking it says that proposals for substantial changes must
> be written up as RFC's.  They are voted on, and any vote of -1 is a  
> veto
> as long as it has a reason.  If a proposal can't be revised to the
> satisfaction of the vetoer then the veto can be overridden with an  
> absolute
> majority of all eligible voters expressing +1 support.  New folks  
> joining
> the committee are handled by vote.  In case of a voting dispute,  
> the chair
> adjudicates.
>
> The RFC also details a variety of somewhat project specific things  
> like
> what requires a vote, and what does not.
>
> But the question does arise what principles we want to encourage and
> require in PSCs.   The MapServer (Apache) model is to try and be quite
> egalitarian among a set of self-selected PSC members.  For instance,
> Steve doesn't have any final control other than that the chair is  
> given
> final control if things "break down".
>
> Another approach is the so called Benevolent Dictator For Life (BDFL)
> approach used by many successful projects, such as Linux, Python  
> and till
> now GDAL.  In this model one person has ultimate control over the  
> project,
> though they are expected to use the power wisely so as to encourage
> participation by many people.  One advantage to this approach is  
> greater
> ease in maintaining coherency to a project.  Something that could
> potentially be lost in "committee rule".
>
> But the downside is that the BDFL might rather arbitrarily dismiss  
> some
> ideas that are important to the community, and potential contributors
> feel they have no redress when refused.  I'm sure that lots of folks
> trying to contribute to GDAL in the past have felt this way about my
> pig-headed resistance to some ideas.
>
> I see that for OSSIM Mark has written: "Garrett Potts is the  
> designated
> lead and has final say over software architecture implementation."  In
> this case I believe Mark intends a consensus based PSC but reserves
> the right of the chief architect (Garrett) to act to preserve the
> architectural coherency if needed.  Perhaps this is a bit like a
> constitutional monarchy.  :-)
>
> While Linus is a BDFL, he also uses the approach of devolving  
> responsibility
> to lieutenants for some areas of the kernel.  I believe this is  
> something
> like how GeoTools works, with a committee discussing issues, but  
> the code
> base split into modules which are the responsibility of module  
> owners.  On
> a less formal base this applies in most projects, with developers  
> generally
> expecting to be able to make minor non-disruptive changes to their  
> their
> own modules as needed without a lot of consultation.
>
> So, I am soliciting feedback from the incubator members on what  
> models of
> governance we should accept in foundation projects.
>
> Best regards,
> -- 
> --------------------------------------- 
> +--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,  
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGF, http:// 
> osgeo.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>