[Incubator] Governance and OSGeo Projects

[Paul Spencer]

Mark,

despite your suggestion that we should lead vs control, I still think  
we need to set a minimum standard or level of project maturity.  I  
suggest that there are some of these items that are a 'will' instead  
of a 'should' or that a minimum number of 'should's have to be in place.

For instance:

Mandatory:
* Projects will manage themselves striving for consensus and  
encouraging participation.
* Projects will document how they manage themselves
* Projects will maintain a source code management system - svn or cvs  
preferred
* Projects will maintain a discrepancy tracking system
* Projects will maintain project mailing lists
* Projects will continuously review and control their code bases to  
insure the integrity of the open source baselines

Optional:
* Projects should encourage participation from all contributors -  
from beginning users to advanced developers.
* Projects should maintain developer and user documentation
* Projects should actively promote their participation in OSGeo
* Projects should use the OSGeo infrastructure where practical
* Projects should implement a daily build and test system

Desirable:
* Projects are encouraged to adopt open standards and collaborate  
with other OSGeo projects
* 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

... or something like that :)

Cheers

Paul

On 11-Apr-06, at 5:14 PM, Mark Lucas wrote:

> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>

+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+