Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Date: Sat, 22 Nov 2003 09:15:15 -0800
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Add 'practice' PMC structure to projects in incubation
From: "Roy T. Fielding" <fielding@apache.org>
To: general@incubator.apache.org
Content-Transfer-Encoding: 7bit
Message-Id: <7025D8A1-1D0F-11D8-8AF4-000393753936@apache.org>

[Moved from the PMC list -- folks have got to stop proposing such
things on the wrong list.]

A long time ago, the name PMC was created in an attempt to genericize
the way that the Apache Group operated, using terminology that would be
easily understood by a judge or IRS inspector.  Unfortunately, the
name seems to have overwhelmed its history.  I described that in a
message to the members on March 12, 2003, which I'll include below.
However, I've been so overwhelmed with issues/fires this past year
that I never got around to fixing it.

Geir has proposed that we create practice PMCs (a.k.a. subprojects)
as part of incubation, and that we call them "Project Committers"
lists rather than PMCs.  I am +1 on the notion in general, but I
would prefer to call them core groups instead.  My rationale is that
"committer" privilege is a mechanism that we frequently give to
people on the basis of what they are planning to do, whereas the
core group are those people who have earned long-term voting rights
whether or not they happen to code.  Jakarta got into a weird state
wherein committer == voter and commit-access was given out like candy,
thus leading to the notion that committers run ASF projects.  I don't
believe it is appropriate to link voting with cvs access.

The key thing to note is that voting is a decision-making process
and we want that decision to be an ASF decision.  Furthermore, we want
the decision to be made as close to the volunteers doing the work as
possible, preferably by the volunteers themselves, whatever that work
may be.

The ability to make ASF decisions starts with the board and is
delegated to officers and their associated committees.  Anyone casting
binding votes (meaning votes that are counted toward making a decision)
must be listed as a member of the committee on which they are voting,
even if their votes are limited to a subcommittee.  Therefore, my
preference is for a fluid structure of incubating subprojects wherein
every voter is listed as being in one or more core groups and the
entire set of voters is listed as the incubator pmc.

I am aware that this would mean incubating projects would be able to
vote themselves out of incubation.  I think that if such a project had
their shit together to the extent that they could run such a vote and
get it past the majority of incubator members, then they no longer
need to be incubated.

....Roy

===============
From: "Roy T. Fielding" <fielding@apache.org>
Date: Wed Mar 12, 2003  9:46:04  PM America/Los_Angeles
To: members   at  apache.org
Subject: PMCs gone wild

I am getting a bit frustrated at what appears to be a serious attitude
problem within the Apache projects.  A lot of people seem to wait around
until "the man" makes a decision, sometimes doing nothing other than
gripe about the lack of concern that "the man" has for their pet issue,
or simply believing that they are not allowed to do anything until
"the man" says it's okay to start.  I am not just talking about the
newer Jakarta projects: this attitude has become endemic throughout
the ASF, and folks are far-too-frequently suggesting that decisions
should be relegated to "subprojects" or that projects should be
"managed" by only a subset of the voters.

"the man" is usually their perception of a PMC as some other-worldly
land where benevolent beings ponder deep issues and create solutions.
[Sometimes "the man" is the ASF board, but that is very rare -- most
people have the sense to realize that the board's solution to a
squeeky wheel is to yank it off, throw it away, and install a new
wheel -- which usually isn't the effect desired by most wheels.]

I think I know what is causing this attitude, and sadly it points
back to one of the decisions I thought was a good idea when we were
crafting the ASF bylaws.  You have to understand some background
on that first...

The ASF bylaws were crafted by Drew Wright using a Delaware
nonprofit template and a ton of input from more than a year of
discussion amongst the Apache Group (circa 1998), discussion at
the post-ApacheCon'98 group meeting, and yet more discussion on the
old apache-core mailing list.  Our goal was to create a legitimate
corporate infrastructure around Apache without changing how Apache
decisions were made or the volunteer nature of the foundation.
By legitimate, I mean something that would be defensible in a court
of law if some asswipe were to sue the foundation for something we
did as a group.

The concept of a Project Management Committee was created in the
bylaws to be analogous to the Apache httpd core.  A PMC is the
legally sanctioned body authorized by the Board of Directors to do
things (e.g., approve changes, release code, etc.) on behalf of the
ASF for a given project.  Why?  Because it means that when the PMC
votes to do something, they are "doing" on behalf of the ASF instead
of themselves, and hence any repercussions from what was done
must be addressed to the ASF as a corporation rather than to just
the people as individuals.

[Note that it is still possible to get sued as an individual -- it
simply isn't possible to selectively sue that person for something
decided by the ASF, and any competent judge will immediately dismiss
a defendant from a joint suit if their actions were directed by the
corporation by way of its bylaws (the PMC).  This is separate from
indemnification, which I'll try to explain below.]

For those of you who aren't aware of US corporate law, there are
only a few legitimate ways for a corporation to delegate authority:

   o  Board -- by default, the board of directors has authority over
      and responsibility for all corporate decisions and assets;

   o  Officers -- the board can delegate some authority to an
      individual named as an officer of the corporation, provided
      that responsibility is maintained through active oversight
      of their activities with communication back to the board;

   o  Committees -- an officer can call on other individuals to
      compose a group that, upon approval by the board, is tasked
      with authority and responsibility for that scope, in which case
      the officer's responsibility is reduced to maintaining oversight
      of the decision-making process itself and providing feedback
      from the committee to the board;

   o  Contracted employees -- an officer can make a contract between
      the corporation and some person or corporation for the purpose
      of doing some action on behalf of the corporation; this does
      not delegate authority or responsibility, and the officer must
      maintain active oversight of the contract.  Employees of a
      corporation are typically hired by the President/COO under the
      terms of an employment contract, though really big corporations
      will delegate that further to division officers (V.P.'s).

We don't have employees, so the latter option is right out.  We don't
contract very often because it is an expensive process and we simply
do not have the money to cover it.  We can't make everyone an officer
because the board cannot maintain direct oversight over everyone and
the law does not recognize as legitimate any corporate structure for
which the line of oversight cannot be reasonably maintained.

So, we are left with committees, which is pretty much exactly how
Apache httpd was operating at the time, and Drew did an excellent
job capturing that in appropriate legalese that could be easily
understood by any future lawyer (e.g., a civil or IRS judge) that
might have a reason to inspect our bylaws.  Hence, PMC.

Unfortunately, the name is filled with historical legacy that
leads to a natural prejudice: Project [my boss gives me those things]
Management [people who tell me what to do] Committee [people who sit
around discussing things].  Yikes!  It doesn't seem to matter how
many times I tell people that

     project    = "something the ASF wants to accomplish",
     management = "making decisions for progress toward a goal", and
     committee  = "the people voting on decisions"

it still comes back as "the PMC" is some other group outside the
development mailing list that makes all "real" decisions on behalf
of the project.  Bullocks!  That is absolute, unadulterated CRAP!

The PMC must equal the voters on a given project, or the entire
theory of delegated authority, responsibility, and oversight upon
which the ASF depends for legal defense of its contributors becomes
just a load of horseshit that any greedy lawyer can and will bypass
on their way to our personal assets.

I am tired of dealing with people's prejudices.  I hereby request
that the ASF bylaws be changed to replace PMC with Core Group,
that it further explicitly state that members of the core are the
only people allowed to vote on actions by a project, and that all
external actions by a project (such as a software release) must be
publicly approved by vote of the core according to a single
Apache Guidelines document that shall be the bylaws for all projects
within the ASF.  Each project shall maintain a primary public dev
list, cvs module, and cvs commit list within which all project
votes will take place and be recorded, aside from those discussions
that are legally or ethically required to be private.  A single
private mailing list per project, called private@project.apache.org
or project-private@apache.org, shall replace the pmc@ lists and
may include any persons deemed necessary by the project core.

Does anyone object?  I will make the appropriate diffs to the bylaws
once it is clear that this is a direction worth pursuing.  We have
a members vote due sometime soon, so we may as well get started.

If infrastructure doesn't want a hostname per project (meaning
code base), then please eliminate all such hostnames.  We can and
should have all projects start at www.apache.org and @apache.org for
static content and lists, and only use cvs, jakarta, tcl, and perl
for dynamic content requiring a special set-up.

....Roy

p.s. Indemnification is a promise by the corporation to pay the legal
      expenses of an *individual* if that *individual* becomes subject
      to criminal or civil proceedings as a result of their actions
      under a role identified by the corporation, as long as such person
      acted in good faith and in a manner that such person reasonably
      believed to be in, or not be opposed to, the best interests of the
      corporation.  In other words, a member is only indemnified for
      their actions as a member (not much).  A director or officer is
      only indemnified for their actions as a director or within the
      scope of their mandate as an officer.  A PMC member is indemnified
      under the category of "who is or was serving at the request of
      the corporation as an officer or director of another corporation,
      partnership, joint venture, trust or other enterprise" and only
      to the extent of that enterprise (the project).  A committer
      who is not a PMC member is not authorized by the corporation to
      make decisions, and hence cannot act on behalf of the corporation,
      and thus is not indemnified by the corporation for those actions
      regardless of their status as a member, director, or officer.

      Likewise, we should all realize and understand that the ASF's
      ability to indemnify an individual is strictly limited to the
      assets held by the ASF.  Beyond that, we are on our own as far
      as personal liability.

      It is a far better defense that an outside entity cannot
      successfully sue an individual for damages due to a decision
      made by a PMC, so it is in everyone's best interests that all
      of the people voting on an issue be officially named as members
      of the PMC (or whatever entity is so defined by the bylaws).

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


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org