incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <>
Subject Re: Add 'practice' PMC structure to projects in incubation
Date Sun, 23 Nov 2003 08:56:07 GMT

Thankyou.  Read with great interest, and it put a few things into 
perspective.  Particularly the fact that to me the Practice PMCs made no 
sense from my perspective (based in the XML project's world).  I think I 
now understand why.

Couple of things came to mind whilst I was ruminating on the contents.

Firstly - am not so sure that changing the name of PMC to Core Group is 
either necessary or sufficient to fix things.  I note that you mention 
the codification of the requirements placed on the Core Group into a 
universal Apache Guidelines document.  For this I am absolutely +1 - one 
of the biggest problems facing the PMCs is a lack of clear understanding 
of what is required.  The only way to overcome that problem is to 
clearly document requirements.  E-mails going over the issues every 6-12 
months 'aint going to cut it.  I suspect if there was a clear set of 
guidelines and a board that was brutal about enforcing them then things 
might change.

Secondly, given the original intent of the concept of a PMC, I am 
curious as to why the board permitted umbrella PMCs such as XML and 
Jakarta.  You can change the name of PMC to Core Group, and put strict 
guidelines in place, but the spirit what you want is not going to happen 
until everyone on a given PMC is on the -dev lists that the PMC is 
responsible for.  That sounds fair, but is impractical for the PMCs of 
the large, divided projects.

So a possible suggestion.  FWIW.  Maybe a step towards where things need 
to be?  (Evolution rather than revolution?)

Can we turn a project such as XML into a federation of projects rather 
than one big project?  In terms of infrastructure (web site, mailing 
lists, cvs etc.) leave it as it is, with maybe a bunch of volunteers 
from each member project helping out with those items.

Each sub-project gets turned into a formal TLP, but not in the sense 
that is implied today (where TLP = web site, = mailing lists etc.). 
Rather the TLPs simply report to the board, have their own PMCs and are 
responsible for the code decisions.  That puts the decision making 
requirements back where I think the board wants it to be.  With a small 
core group of individuals responsible for each particular code base.

It also helps the Foundation scale as it reduces the requirements placed 
on infrastructure@ (new web sites etc.)

As I said - FWIW.


Roy T. Fielding wrote:
> [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" <>
> Date: Wed Mar 12, 2003  9:46:04  PM America/Los_Angeles
> To: members   at
> 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
> or, 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 and 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message