Re: gnome foundation: some key issues to discuss.

[rms39 columbia edu (Russell Steinthal)]

On Thu, 06 Jul 2000 22:06:19 PDT, Bart Decrem wrote:

>2) What's all this about modules?  In the Apache model, there's an 
Apache
>Foundation and then 5 or so autonomous projects, such as the HTTP 
server
>project.  The foundation's only power is that they can decide 
whether a
>project is still a part of the foundation.  So similarly, there are
>currently a ton of projects under the broad Gnome umbrella.  These 
projects
>are and will remain fully autonomous: the Gnome Foundation doesn't 
have any
>power to tell those groups what to do, but surely the Foundation will
>identify an overall direction for Gnome and communicate with 
maintainers of
>packages to get their support in pursuing that direction.  So the 
question
>is: do we want to keep today's structure with tons of projects, some 
really
>modest, some pretty big, or do we want to somehow group projects into
>modules? My personal opinion is that today's structure seems to work
>reasonably well, so I don't see the need for intermediate groupings 
into
>modules, but I think others feel differently.

Hmm... I read "modules" == "CVS modules" == (approx.) "projects".

That is, the CVS module structure is, with some minor variations, a 
fairly good mapping of the "project" breakdown.  The exceptions are 
relatively few: gnome-applets, for example, is arguably a lot of 
little projects grouped together for release convenience (gnome-utils 
is similar, I think), some modules (think virtual inclusion) are 
clearly *not* projects (e.g. libical, which is in modules so that it 
can be shared by gnome-pim and Evolution), and then there are some 
projects which are not in GNOME CVS, but which are arguably part of 
the GNOME "environment" (X-chat is the best example that comes to 
mind).  It's at least a good first approximation.

The only intermediate groupings that would make sense to me are 
basically the ones we already have- gnome-utils, gnome-core, 
gnome-applets.... A package on its own release schedule is another 
way of looking at basically the same thing.

But what's less clear to me (and possibly this is something which 
*is* clear to those who were in the original discussions) but what 
are we considering using projects/modules for, organizationally?  If 
it's just to make the statement that each project retains its 
autonomy of release schedule/design, do we need a formal definition?  
Or are people thinking of something akin to Debian, where (at least 
as I understand it as an outsider) voting is at least in some way 
associated with maintaining a "project."?

If the latter, what do we do about dying/superseded projects?  For 
example, I have maintained gnome-pim for the last few months 
(although I must confess to not having done any signficant GNOME work 
at all since the 1.2 release, due to time pressures).  Gnome-pim is, 
by all accounts, going to be superseded in the near future by 
Evolution.  Should it retain its "project" status (and my 
"maintainer" status, if that means anything) indefinitely?  As long 
as the maintainers want to keep releasing it?  Or just until 
Evolution reaches the point that it can replace gnome-pim in the full 
GNOME "releases"?

Personally, I think the last is the right answer for the project, but 
if project maintenance means something in terms of voting, it seems 
less fair to the maintainers of smaller projects which get "absorbed" 
into larger ones.  (Note: That's not a personal complaint, far from 
it--- it's just an observation.)

>3) Elections: do we want to have elections for the board of 
directors of the
>Gnome foundation?  If so, how do we decide who gets to vote?  I think
>there's rough consensus that all active Gnome hackers and a number of
>non-hacker contributors to Gnome should get to vote, but there'll be 
some
>problems at the edges: what about a package maintainer who hasn't 
done much
>lately; or what about someone like me, who's not a hacker and has a
>corporate affiliation?  So we need a system to address that.  The 
question
>of whether to have elections at all is a more interesting one, in my
>opinion: we may want to have a finely balanced group of people 
representing
>different geographic areas, some corporate affilitions, the major
>technologies of Gnome.  Chances are, an open election may not 
generate the
>perfect group, and some people who'd be really terrific for a board 
may not
>wish to go through an election process.  My current thinking is that 
it may
>be better to have indirect elections, such as: the Gnome community 
votes up
>or down on a proposed slate (and if a slate gets voted down, we have 
some
>plan B process),   Jim Gettys suggested we look at the IETF's 
nominating
>process (I have asked him to explain it to us in greater detail).

I think a combination of elections and a "designed" board might work. 
 As a rough idea (i.e. thought out as I type, not in advance), say 
the board must be composed of:

* m members representing corporate partners
* n members representing/who are independent developers
* r members representing the documentation project
* s members representing the translation project
* t members "at-large"

Let each of those subgroups select/nominate appropriate members, and 
then have the whole membership vote on the slate (or individually, I 
guess).

Looking back on that, that seems to track with the high level 
"module" structure Bart was talking about above.  At least to the 
extent that it recognizes that there are some "subprojects" which 
ought to be represented, such as the documentation/translation 
projects...

The catch of course, is picking values for {m, n, r, s, t} above.

>4) Geography: the Gnome community is a very cosmopolitan one, and a 
lot of
>people want to make sure it doesn't become dominated by one 
geographic zone
>(ie. the US).   On the other hand, the Gnome 'industry', at least 
for now,
>seems to be mostly in the US and there are a number of major industry
>leaders who are getting ready to embrace Gnome, and they need a US 
legal
>entity that provides them shelter from US antitrust laws (for
>example: Oracle and Informix can't go sit in a smoke filled room and 
talk
>about how to develop the market for database software - that would 
be an
>antitrust violation).  There is really no international legal entity 
(except
>for a few UN chartered organizations).  So I think we need to create 
a
>foundation that's incorporated in the US.  But I think the board of 
the
>foundation should be representative of the entire Gnome community.  
And I
>also think it's a good thing to have affiliated organizations around 
the
>world, such as the Gnome Foundation Europe.  But I think at the end 
of the
>day, we do need a place that can speak with authority on behalf of 
Gnome,
>and I think this foundation should be that place.  Your thoughts?

I have two thoughts here, both of which assume that there is going to 
be a U.S. foundation and at least one non-U.S. organization.  There 
obviously should be some coordination among them, and the two models 
which come to mind are:

(1) Reserving a spot on each board of directors (possibly non-voting) 
for a "liason/representative" of each of the other organizations.  So 
that there would be one person on the GNOME U.S.A. board who is 
selected by the board/membership of GNOME Europe as its official 
representative.

(2) Letting each region elect its own leadership, and then having a 
"coordinating committee" of some kind, to which each board would send 
one representative to handle high-level coordination.  To avoid legal 
troubles, the coordinating committee doesn't need to have money, or 
even legal status (I don't think- I am *not* a lawyer)- it would be 
analagous to the current SteerCom, in that it would just make 
recommendations of coordinated actions.

>[Havoc wrote:]

>>  - the group will be membership-based, where members vote on
>>    the board of directors and also vote on major issues.
>>    We will need some way to select the initial membership;
>>    additional members will be added by a vote of the current 
members.

This seems to imply a restrictive "membership," unless the vote 
becomes pro forma.  Why couldn't membership be handled similarly to 
the way gnome-hackers is now?  I.e. anyone who is a bona fide 
contributor (defined in some way to exclude pure users, although that 
doesn't even need to be a requirement, IMHO) can make request 
membership, and as long as there's not some hint of irregularity, 
just let them in?  Obviously, that would need to be formalized, but 
the point is that it could be a self-declaration of one's 
contributing status, subject only to disapproval by the 
board/membership (but generally *not* requiring an affirmative vote).

Those are just my thoughts, as interestedp, but uninformed outsider.  
I'm sure I missed some obvious things. :)

-Russell

-- 
Russell Steinthal		Columbia Law School, Class of 2002
<rms39@columbia.edu>		Columbia College, Class of 1999
<steintr@nj.org>		UNIX System Administrator, nj.org