Draft Charter Review Comments

[linas linas org]

Hi Bart,

This note is a re-write of some commentary on draft 3 of the charter
that I sent early last week.  Maybe I'll succeed in being more to the
point this time.   I beleive that there are several problems 
with this draft that should be fixed before the 8/15 announce. 

--linas

-------------------------------------------------------------------

The question of 'why is a gnome foundation needed?' isn't ever clearly
asked, and is answered only indirectly in the section 'tasks of the
foundation' section.  I think you need to ask and answer this question
first, in writing, as the preface to the charter.  

Let me state this in a different way: the section called "Principles 
of the Foundation"  is nice and floaty and airy,  and needs a bit more
of a solid anchor to make it meaningful.  It's important to have
principles, and to communicate them to others, but this section needs
some work:

-- "write access to CVS": is this really appropriate to mention here?
   GnuCash has always been nominally a Gnome project, and it has never
   had open, public write access to CVS, and is not likely to in the
   near future.  (Do I need to defend why we do things this way? 
   Becasue we think it results in better code.  Is that wrong?  Well,
   the FSF, the Linux Kernel, and Perl follow this model, so I don't
   feel like I'm committing a sin by maintaing tight control.)

   I am hoping that my company, Gnumatic Incorporated, can be one of
   the founding members of the Gnome Foundation. (We are enhancing   
   and marketing GnuCash, we hope to turn it into a world-class
   financial accounting package for the Linux desktop.)  Its all     
   GPL'ed and its an FSF/Gnu project, but implying "write access
   to CVS to all comers" is farther than I want  to go.

-- "smoke-filled rooms". This is an anachronistic remark on 19th  
   century American decision making processes.  Surely there must
   be a better way of saying this, especially in light of the next
   sentance:

-- "On certain occasions, converstations within the Gnome foundation
   will be confidential."  Sounds pretty damned smoke-filled to me.
   Which side of the mouth are we speaking out of, again?

   This paragraph is entirely inapporpriate for the "principles".
   Although the gnome foundation *might* have confidential meetings,
   the protocol for this should be dealt with in some later section 
   covering the operations and protocols, and *not* in the "principles".

   Furthermore, its not at all obvious why the gnome foundation
   should have *any* secret meetings whatsoever.  I agree that some
   corporations may wish to petition certain members of the gnome 
   foundation privately, to "feel things out", "test the ropes",
   as it were, and that's OK.   But this should be done privately, 
   and not by the gnome foundation.  Hey, if Micheal Dell wants to
   call Nat Freidman bout joining the gnome foundation, and talk about
   it in private, that's OK.  However, it would be highly inappropriate
   to call a secret meeting of the board of directors to discuss the
   situation.

-- "Gnome will include only Free Software, as determined by the
   Board of Directors".

   Lets erase the "as determined by the board" part of this sentance.
   Why? Again, its a proceedural issue, and would be better covered
   in the proceedures section.  It may happen that the board of
   directors will delegate this decision to some other body or comittee,
   etc.  The board may not have control over that body (e.g. if
   there is a standards committee subgroup of the gnome foundation,     
   it must have absolute technical authority, which even the board
   of directors cannot veto; see below).


-- "Participation in the foundation should only be available to
   those people who ..."
   This sentance should state something like "participation is
   intended only for those people who...".  Again, lets not make
   policy/proceedural declamations in the "principles" section. 


-- "Money cannot buy influence..."  I applaud this remark.  However,
   this is far from obvious in the actual structuring of the foundation.
   Care will need to be taken in "operations and protocol" section
   to ensure that this is will indeed be true.

-- Emperor Maximilian? Huh? This is a historical reference that is   
   too obscure for me.  Just because you know the story doesn't mean
   that others will.  Think Shiite vs. Sunni.  (don't get it? think
   "fork".)

===============================================================      


Section 'Tasks of the Foundation', I'd suggest listing 'Releasing Gnome'
and 'disbursing cash' last instead of first.   This ordering would be a
a bit more normal and customary, and makes infintely more sense to me.
If I understand other comments on the mailing list, "most" folks feel
the same way.


'We need a mission statement'.  May I dutifully point out that
the sections labelled 'public image', 'point of contact', 'direction
and vision'  already pretty much state what a mission statement would
say.  I dutifully submit that the section currently labelled
"Tasks of the Foundation" be simply re-titled "Mission Statement."

===============================================================

Section I. Goals of the Gnome Founcation.
"The tasks are the letter of the law; the principles are the spirit."
This sentance is just plain wrong.  The "letter of the law" is spelled
out in sections II, II, IV etc.  The "letter of the law is *not*
spelled out in the section called "Tasks".

===============================================================

Section IV. "The board of directors will be responsible for authorizing
the release of a new version of gnome."  Hogwash.

The board of directors should be responsible for preparing quarterly
financial statements for the dues-paying members.  The board of
directors will be responsible for promoting Gnome through press
releases, trade shows, etc.  The board of directors will deal with
trademark issues,  patent issues, legal issues.  The board of directors
will organize the advisory board, and the standards subcomittee.

The board of directors would be insane to also try to get involved
in technical matters or release schedules.  Not the least of which
are the severe conflict-of-interest issues already raised on the
mailing list.  The board of directors should maintain an arms-length
relationship with the body that is steering the actual code.

For example:  If the board does not like a standard that the
standards comittee has created, it does not have the power to veto
that standard.  It may have the power to dissolve the committee.
Similarly, it cannot veto a release schedule, although it can dissolve
the release-schedule subcomittee.

In practical terms, this protects the foundation from various forms
of corruption & ensures far more public oversight  (can you imagine
the fuss that will happen when a committee is dissolved when the
board doesn't like it?  This will be a strong incentive for the
board to be honest and fair in its dealings).

=============================================================

The remainder of this note is commentary about the standards
process.  However, a disclaimer: what I describe below only works
for highly structured boards.  I no longer think that this would
work for the Gnome foundation.  I think that Jim Gettys is right
and that a more IETF-style of proceedure is far more appropriate
for Gnome.

----


Q:'How does standards definition really work?' A: most of them don't.

I suggest that the board of directors delegate all decisions about
technology to the advisory board  (the board of directors retains
control over all basic proceedures, the funds, the PR campaign,
legalities, trademarks, brand certification, etc.)

It may be that the advisory board is not appropriate for tech issues, in
which case the charter should create a 'technical advisory board' or
'architecture review board'.  The board of directors does not have the
right to override any technical decisions made by the arch. review board
(although it has the right to disolve the board).  The tech review board
should have corporate members (I'm sure helixcode wants to have some
formal power) as well as some at-large members (elected by referndum).

In such a case, I'm not at all clear on why a non-technical advisory
board is needed.  I suppose that if the board of directors is hard to
reach, or only meets infrequently, then a non-technical advisory board
would be good.


Standards definition only works when the members on the standards
committe are of the very highest technical calibre, with impeccable
credentials, and also do not operate with either hidden agendas, or with
explicitly corporate-centric agendas.   Standards committe members must
be technically brilliant, knowledgable in consensus building, and have
plenty of free time.  Any two of these three is not enough, and would be
a recipie for friction ending in disaster.

*All* members of the standards committee must be technically brilliant
consensus builders with free time.  Having even 1/4th of the members
be second rate is enough to sink the whole thing (since they can cast
swing votes in the wrong direction).  (This may be why the IETF
doesn't use voting terribly formally.)
The standards body should have ultimate authority on tech issues:
the board of directors *cannot* override the standards body. They can
only dissolve it.  This prevents under-the-table dealings and improper
lobbying.

The standards committe must also have rules for selcting members, for
voting for adoption of standards.  Membership should be by
representation.  It should be limited to no more than a dozen or so
voting members, and maybe 20-30 people in the room who have a right to
talk, to be recognized by the floor.  The meetings should be
open and allow observers, but observers have no inherent right to
interrupt the proceedings or heckle or whatever.

Attendance is *mandatory* not optional; failure to attend is grounds
for explusion.  (i.e. you shouldn't be voting on technical issues if you
don't have the time to read the spec.).


--linas

Linas Vepstas
CEO
Gnumatic Incorporated
Developing and Supporting Gnucash and other Open Source Financial
Software