Draft of Proposal for the GNOME Foundation.
- From: Nat Friedman <nat helixcode com>
- To: foundation-list gnome org
- Cc: rms gnu org
- Subject: Draft of Proposal for the GNOME Foundation.
- Date: 13 Jul 2000 12:02:42 -0400
[ The stupid mailing list bounced my last mail since I sent it from
the wrong address. ]
Hi everyone,
It seemed to me that it might be useful if someone were to write up a
summary of the discussions which have centered around the proposed
GNOME Foundation. So I tried to do that, but then I kind of got
worked up. This is the result of my calenture.
I hope that someone finds it helpful. I put it on the web, too,
thanks to the <pre> tag:
http://primates.helixcode.com/~nat/draft1.html
I think it's bad that this stuff is getting discussed in private. I
want to send my proposal to the gnome-hackers list, and maybe other
places too, to open up the discussion and see what everyone else
thinks. Let me know how you feel about that idea.
Richard, I thought you might find this interesting. Or are you
already on the foundation list?
Regards,
Nat
Proposal for The GNOME Foundation
Draft One (13 July 2000)
Nat Friedman (nat@nat.org)
---
Disclaimer:
Please note that this is the work of one person, and is therefore by
no means the result of any kind of thing even hazily resembling a
consensus.
It is an early, rough-hewn draft -- an attempt at synthesizing a lot
of the discussions that have gone on about the GNOME foundation
lately. Important details, and whole chunks of things bigger than
details, are definitely missing. And there are fundamental flaws in
what I talk about here that are easy to flame about. By no means do
I think this is a correct solution. (Plan to throw one away) But I
do hope that this will be a starting point for some new, hopefully
clearer conversations.
---
This document describes the purpose, basic structure and operational
policies of a proposed GNOME foundation. It is intended to serve as a
straw-man proposal and a concrete basis for further discussion.
Although certain issues are not addressed fully, the core functions of
the foundation are defined and procedures for them are described.
Crawl before walking, and so on...
I. Goals of the GNOME Foundation
In order to sketch even a rough outline of the foundation's layout
and operational procedures, we must first agree on the entity's
raison d'etre -- why is it here, and what do we want from it? Once
we agree (within epsilon) on our objective, we just have to
determine how to get there.
Different people have different ideas about what the foundation is
supposed to be; for example, is it a collection of individual
hackers or a consortium of corporations? These differences are
okay, and a lot of them can be resolved, but we have to talk about
them out-loud. Also, a clear expression of our common goals will
make the foundation's job easier in the future, when a tricky issue
arises and the role of the foundation in handling it is not clear.
I've divided the goals of the foundation into two categories:
principles and tasks.
Principles are the cultural and moral guideposts which are intended
to help us determine how the foundation should be structured, and
how it should act.
Tasks are the issues and decisions the foundation will face: how to
release new versions of GNOME, how to disburse funds, how to manage
corporate involvement and joint marketing, and other duties. The
day-to-day humdrum of modern living.
The tasks are the letter of the law; the principles are the spirit.
Well, that's the intent, anyway. I don't presume to speak for
everyone, or to have any deep anthropological insight into The GNOME
Community. But I do think that a lot of this stuff is common sense.
Principles of the Foundation
============================
These are the guidelines which I used in determining the proposed
structure of the foundation. Hopefully they will sound
ludicrously obvious, which would mean that we're all on a common
ground here.
Open and Public
---------------
In almost every sense of the word (except the OSF-corrupted
tragic-ironic connotation), GNOME is an open project. This is
one of our greatest strengths, has always been, and should be
the balefire by which we plot our course into the future.
The foundation should not be exclusionary or elitist. Every
GNOME contributor, however small his contribution, must have
the opportunity to participate in determining the direction and
actions of the project.
The openness of GNOME has always been a point of pride for us,
and an important characteristic which distinguishes us from
many of the other Open Source(TM) projects out there. Anyone
can become a contributor, write access to our CVS doesn't
involve trial by fire or other masonic rituals, we don't use
ACLs, and we've always been exceedingly good about folding
talented newcomers in our arms and welcoming them to the
project. No resume required.
Major components of GNOME -- things we now consider to be
absolutely core to the project -- were begun by energetic
individuals with the desire to create something cool. Look at
glade, zvt, libxml, dia, gnome vfs, libart, the desktop
icons... all of these were created by people who had not
previously contributed heavily to the project, but who are now
considered to be among our heavy hitters.
Look at how the GNOME UI group was created: Miguel mailed
gnome-list and said "We need someone to lead this new project;"
Jim Cape appeared out of the blue and replied "I can do that,"
and click, clack, it was done. The GNOME UI group has since
become a significant source of usability ideas for our
developers. We don't want to live in a world where we've put
up barriers that make it difficult for us to capture the kind
of spontaneous energy upon which this project has thrived.
The GNOME foundation must not stifle the interest of outsiders.
An ill-conceived foundation could discourage outsider
participation directly, by establishing rules which limit the
ability of potential contributors to make their mark, or
indirectly, by engendering an alienating sense of elitism. The
stained glass of the cathedral creates a colorful spectacle for
those inside, but from the outside, the building is just a
hulking grey edifice, intimidating and impenetrable.
This principle has real, concrete meaning for the foundation:
All discussions must be publicly viewable, any person must have
the opportunity to contribute to the decision-making process,
and every GNOME contributor must have the direct ability to
influence the decisions which are made. The foundation must be
democratic and friendly to those responsible for making GNOME
what it is. We didn't get here by way of smoke-filled rooms
and power hierarchies. We got here because of people.
GNOME is Free Software
----------------------
Free software licensing has always been a mainstay of GNOME,
and we must ensure that this tradition continues. The
foundation must not allow any software module to become a core
GNOME component unless it is licensed under the GPL, or a
GPL-compatible license. GNOME should strive to be free, while
still being friendly to ISVs and commercial developers.
GNOME is a Meritocracy
----------------------
Participation in the foundation should only be available to
those people who are responsible for actual contributions to
the software which makes up GNOME. A corporation, organization
or individual should not be granted a place in the foundation
unless its presence is justified by the merits of its
contribution. Money cannot buy influence in the GNOME project:
show us the code (or documentation, or translations, or
leadership, or webmastering...).
In the past, being a part of the GNOME project has simply meant
"I wrote some code" or "I hang out on the mailing lists and
build the thing from CVS frenetically every three hours."
There is no reason to change this.
Build on What we Have (or: too much structure is poison)
--------------------------------------------------------
In many ways, GNOME is a unique project. Comprised of dozens
of autonomous modules, GNOME has not been subject to
iron-fisted structural leadership. Furthermore, there are many
pieces of software which are core to GNOME which stand with one
foot in our camp and one foot outside. There really is no
clear analogue to GNOME among most other free software
projects. GNOME is bigger than almost every other effort in
existence (I count 75 megs of SRPMs), more loosely organized,
and possibly faster growing. Plus, GNOME sits on the frontier
of the Linux application market, and is likely to continue to
face growing pains as we try to meet the needs of ISVs and
other carpetbaggers jumping onto the bandwagon.
It would be impossible to impose a high degree of bureaucratic
structure onto a heretofore amorphous and somewhat anarchic
community. And it shouldn't be done, anyway. Let's not
attempt to imitate some of the groups which are smaller, or
which had more structure in their beginnings. Any new
structure which the GNOME foundation provides, if taken too
far, will be artificial, ignored, or at worst: really really
annoying to developers.
Furthermore, the foundation can have no real powers of
enforcement; compliance with foundation decision should be an
act of good-faith. If we've lost consensus to the point where
we're regularly forcibly ejecting people from the foundation
and coopting their projects, we're sunk anyway.
Heavy bureaucracy is not in our DNA. And it shouldn't be. So
let's not try to graft an administrative superstructure onto
the community we've built. Furthermore, too high a level of
administrative overhead will gum up the works to the point
where the foundation will completely cease to function and
become useless and vestigial.
Instead, let's create a foundation that will work with GNOME's
strengths to make it better. A foundation that provides
cohesion, vision, direction, and enough organization will be an
incredible asset. A foundation that attempts to do this, but
hides the iron fist under a velvet glove will not. Such an
entity would likely be ignored, and words like "fork" would be
thrown around. Think: Emperor Maximilian.
The foundation should provide the project with just enough
organization to accomplish its goals effectively. Some level
of structure will be important for decision making,
communication, and interacting with outside parties.
Independence
------------
The foundation must act in the best interests of GNOME,
independent of influence from outside organizations and
corporations. No single entity should have the ability to
direct GNOME to its own ends.
This is perhaps the single most compelling motivation for the
existence of the GNOME foundation.
Tasks of the Foundation
=======================
These tasks are intended to clearly define the specific ways in
which the foundation will lead and direct the project. This is
especially important in GNOME, where leadership and management has
largely occurred on an ad-hoc basis, coming from whomever has had
the energy and conviction to provide it. GNOME is far-flung: most
contributors operate independently, or under the direction of
their employers. And so a central, all-powerful foundation would
not be at home here. A good, clear-cut elucidation of the
foundation's functions will confine its role appropriately.
Most of these are tasks that we can probably all agree on; a few
are here because they seem to be natural extensions of other
duties.
Releasing GNOME, defining GNOME
-------------------------------
The foundation bears the responsibility of coordinating each
subsequent release of GNOME. For each release, this will
include setting a schedule (whether or not it is overlooked),
choosing the set of modules which are a part of the release,
and preparing the appropriate marketing materials.
GNOME is a loose collection of independent projects. The
foundation will determine the set of modules which fall under
the GNOME umbrella. The foundation will be able to endorse a
project as a GNOME project simply by including it in a
release. In this way, the foundation will be "defining
GNOME."
It should be apparent that these two tasks (defining GNOME and
doing releases) are deeply interrelated: defining GNOME is
just determining which modules are a part of any given
release. You can't coordinate a release without knowing what
you're releasing. The set of packages which comprises GNOME
is defined at every release. And so releasing GNOME and
defining GNOME are one and the same task.
Fund Receipt and Disbursement
-----------------------------
Individuals and organizations that want to make a monetary
contribution to the GNOME project will be able to do so by
writing a cheque to the GNOME foundation. The foundation will
be in charge of disbursing these funds in accordance with the
wishes of the benefactor, and to the benefit of GNOME.
This is actually the original reason discussions about the
foundation began.
Public Image and Voice
-----------------------
The foundation will be the sole entity with the ability to make
official public statements for GNOME, such as press releases.
The foundation will also be responsible for maintaining the
"GNOME brand," and will have to determine the appropriate uses
of the associated trademarks (which will need to be
registered). The foundation will also be a hub for
joint-marketing efforts by those organizations (corporate and
non) which want to make GNOME-related announcements.
Corporate and Organizational Point of Contact
---------------------------------------------
Companies and non-corporate groups which want to communicate
with the GNOME project should be able to use the foundation as
a their first point of contact. The foundation will be
responsible for helping these organizations understand the
GNOME project and become involved. The foundation will be
vested with the power to represent GNOME in these
conversations.
The foundation will also act as a forum for discussions between
the organizations and companies which have an interest in
GNOME. There will be a subgroup of the foundation which will
include members from these organizations to make this possible.
Standards Definition
--------------------
Eventually, as GNOME matures, it will become necessary to have
an official set of standards which define GNOME compliance, for
ISVs and for distributors. The foundation will be responsible
for ratifying these standards, and authorizing the application
of the GNOME trademark to them.
Direction and Vision
--------------------
The GNOME foundation should provide a sense of leadership and
cohesive direction to the GNOME project. The foundation should
attempt to communicate a vision and set of goals for the future
releases of GNOME. These should be communicated to the general
public and to the project at large.
If the foundation isn't able to do this, then it's basically a
non-integrated adjunct to the project.
It is very likely that there are other duties which are
appropriate and necessary for the foundation to undertake; if so,
they should be mentioned explicitly, to avoid confusion later.
II. Basic Structure and Operation of the Foundation
The foundation will be a virtual global entity, represented for the
purposes of funds disbursement in many countries. The GNOME
foundation is divided into three bodies: the General Membership, the
Board of Directors, and the Organizational Forum (Yeah, the names
are a bit corny. Suggestions welcome.).
General Membership
------------------
The General Membership will be a large body made up of people who
have made a contribution to any module which is part of GNOME.
The intent of the General Membership is to provide the opportunity
for all contributors to have a place and a voice in the GNOME
foundation. The General Membership will be open to all people who
want to be a member, and who have made any kind of contribution to
any part of the GNOME project, with no membership fee, and no
requirement of organizational or corporate affiliation.
The general membership will have two responsibilities: electing
and deposing members of the Board of Directors, and issuing
popular referenda on any issue under the jurisdiction of the
foundation, at any time (hopefully an infrequent event).
The General Membership will be open to all people who want to be a
member, and who have made any kind of contribution to any part of
the GNOME project.
Board of Directors
------------------
The board is the primary decision-making body of the GNOME
foundation. It is responsible for ratifying all decisions the
GNOME foundation makes. These decisions can, of course, be
overturned by referendum.
The board will be made up of a small, limited number of people,
elected by the General Membership. New seats on the board will be
made available as the project grows, subject to approval of the
board or referendum of the General Membership.
Miguel will be the chairman and will preside over all meetings of
the board, unless he is declared legally insane and "fit to be
tied" by the UN or the Pope.
No single organization or company will be allowed to have a
majority of the board seats, regardless of election results. In
the event that a corporation or organization holds a majority of
the seats, directors from that corporation will be required to
resign until a majority is no longer held.
Organizational Forum
--------------------
The Organizational Forum is made up of companies and organizations
which have a desire to participate in advising the foundation
about releases and other decisions. The Forum will have no
decision-making ability whatsoever. The Forum is a place for its
members to have open discussions about their GNOME-related
strategies. Membership in the forum is open to all companies and
groups who have contributed to the GNOME project, subject to the
approval of the board of directors. Debian and the FSF will be
given permanent positions in this body.
From time to time, ad-hoc committees will be formed, formally or
informally, either by the board or the General Membership. These
may be formed to propose a release schedule, a press release, or a
standards specification. The board will vote on the approval of any
such measure.
IV. Board Voting, Referendum and Election -- Is this really going to
work?
Board Voting
------------
Voting sessions of the board of directors will be formal,
performed either in-person, telephonically, via email, or on IRC.
This can be cryptographically authenticated with a registry of
public keys. A simple majority is required to approve any
measure.
Minutes shall be kept for all meetings of the board of directors.
Votes on all topics will be recorded and attributed. All of these
records will be archived and made publicly available immediately.
Referendum
----------
A referendum can be issued by any member of the general
membership. An electronic voting system will be established
online, with members voting on a web page or by email. The voting
system will maintain a database of all members and their
passwords/public keys.
In order for a referendum to pass, 1/3rd of the total membership
must participate, and 2/3rds of the participating members must
approve. There will be a mailing list for all of the members, and
all referenda must be announced to the list by the initiator
before they are opened on the voting system. At least three days
must pass before the referendum is closed, and no referendum can
remain open for longer than seven days. [ These numbers are, of
course, eminently debatable. ]
Elections and Board Size
------------------------
Elections for the board of directors will be regularly held every
year. Members will run as a slate, to ensure that the various
parts of the project have equal representation on the board. No
slate may be proposed which violates any board constraints (such
as majority control by a single corporation).
The General Membership will periodically vote for new board
members, when one board member resigns, is dethroned or a new
board seat is allocated.
Election of a board members and slates will be executed just like
voting on a referendum.
The size of the board will scale with the number of modules in the
project. The ratio (or whether or not this makes sense at all) is
an open question.
V. Release Engineering / Defining GNOME
The board of directors will be responsible for authorizing the
release of a new version of GNOME. The board will determine the set
of modules which will make up the release at least 60 days in
advance of the release date, subject to unanimous approval of the
module maintainers.
Operational management of the release will be handled by a
board-appointed committee or individual, made up of general members
and/or directors. The General Membership will be able to affect all
these decisions primarily by participating in the discussions which
lead up to them. In extreme cases, a referendum can be used.
If a new module is being included in a release, all its contributors
have the option to become part of the General Membership.
VI. Funds
One of the primary purposes of the GNOME foundation is to allow
outsiders to contribute financially to the continued development of
GNOME. These outsiders will make donations to the project, which
will be disbursed by the board, under the advisement of the General
Membership. Because GNOME is a widely dispersed project, it will be
important to allow people to specify a specific recipient for the
money.
The board will direct the donor to send the money either directly to
the recipient, or to the appropriate local legal entities
representing the foundation.
VII. Bootstrapping the GNOME Foundation
The General Membership will be populated with all the (consenting)
members of the gnome-hackers mailing list, people holding CVS
accounts, and anyone else who speaks out and wants to join when
asked.
The board of directors will be primed by the election of a slate of
initial members. Anyone may propose a slate, so long as it is
approved by at least 5 general members.
VIII. Future Work
I have tried to design a system which will have just the right level
of structure and formality to give GNOME the organization which it
needs. My thoughts are the result of reading the recent activity on
the foundation list a few times, and a bunch of iterations on a
whiteboard. A lot of the ideas come from Joe Shaw, who has a lot
better knack for politics than I.
In any case, there are a lot of obvious flaws and missing sections
in the above description. Here's a list of things to think about:
1. Historically, decisions in GNOME haven't been made. They've
just sort of happened. Does this foundation really have any
chance of doing anything useful except issuing press releases?
If it's going to be useful, I think it's pretty clear that it
has to be a natural growth step from whatever "organization" we
have now, and it has to be wide, wide open.
2. How do we determine the size of the board? Does it make sense
to expand this thing with the project? To some extent, it
does, since the project is going to continue to grow as the
industry does. And we don't have a set of totally neutral
non-affiliated people to sit on the board and independently
represent several organizations/modules/companies (about the
companies thing, keep reading). But too many directors can be
a problem too (deeper hierarchy?). Do we put term limits in?
Why?
3. Does this address the needs of companies in this space, while
keeping them sufficiently at arms distance that they can't be
divisive and use the foundation as leverage to their own ends?
I tried to design something which would. Companies have *no*
official voice in the foundation, and *no* direct
decision-making ability. But realistically, as Havoc has said,
you can't expect people not to represent their companies when
they vote. And does the Forum do everything companies will
want it to do?
4. Can the general membership voting system actually be done? I
think the software is pretty trivial. But will it be used?
Does democracy work? Are we going to get gerrymandered?
5. How does standards definition *really* work? This is going to
be really important some day, and someone should be cogitating
on it.
6. The numbers -- can you plug in better ones?
7. Can we really expect to use a system of non-enforcement and
*still* maintain a legally defensible trademark? Ok, this is
getting marginal...
Anyway, I hope that this is at least somewhat useful in generating
some directed thought and discussion.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
