Difference between revisions of "One Organizational Model"

From OSGeo
Jump to navigation Jump to search
(just some random thoughts)
 
Line 8: Line 8:
 
* must periodically report status to the Board
 
* must periodically report status to the Board
 
* additionally, the WebComm folk can define some common infrastructural properties for '''Project ''' objects, such as Wiki space, mailing lists, etc
 
* additionally, the WebComm folk can define some common infrastructural properties for '''Project ''' objects, such as Wiki space, mailing lists, etc
 +
 +
New projects should be subject to an "incubation" process.
  
 
Now, several types can be derived from the base '''Project''' class:
 
Now, several types can be derived from the base '''Project''' class:

Revision as of 09:32, 12 June 2006

As people were talking about forming local and special interest groups the other day, I made notes about an object-like model that could be used to "describe" the organizatinal structure of Foundation. Here they are, if only for posterity.

For the sake of discussion, let us use an object-like model to describe organizational strucutre of the Foundation.

The Project type has the following properties:

  • is initially chartered by the Board
  • has a Management Committee of some sort, with at least one elected Foundation Member
  • must periodically report status to the Board
  • additionally, the WebComm folk can define some common infrastructural properties for Project objects, such as Wiki space, mailing lists, etc

New projects should be subject to an "incubation" process.

Now, several types can be derived from the base Project class:

  • CodeProject- specifically concerned with code development work, e.g. OSSIM development
  • LocalInterestGroup - specifically concerned with bringing together individuals from a common geographic region, e.g. Ottowa or Brazil
  • SpecialInterestGroup - specifically concerned with bringing together individuals with a common geo-related interest, e.g. GRASS users

There are also types derived from Project which are to be instantiated as singletons:

  • IncubationComm
  • FunCom
  • VisCom
  • WebCom
  • EduCom
  • OpenDataCom

Given this, I then see the Foundation as really being a "federation" of Project objects, all of which share certain common properties. One of the underlying intents is that this model might help us better understand -- and possibly simplify -- the Board's role to just the following areas:

  • identify new strategic opportunities, and charter off a new Project as required
  • oversight over all projects, to make sure they are following OSGeo's goals and principles
  • control of budget and allocation of funds

Note that nothing in the above is intended to "change" the Foundation -- this is just a way of thinking about things.