[Incubator] Governance and OSGeo Projects

[Mark Lucas]

Paul,

agree.

Mark

On Apr 12, 2006, at 7:30 AM, Paul Spencer wrote:

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