Governance and OSGeo Projects

Frank Warmerdam warmerdam at pobox.com
Tue Apr 11 16:33:01 EDT 2006


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





More information about the Incubator mailing list