incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: What is "The Apache Way"?
Date Thu, 08 Jan 2015 17:24:36 GMT
On Thu, Jan 8, 2015 at 11:01 AM, Ross Gardler (MS OPEN TECH) <> wrote:

> WTF? There have been presentations about the apache way at every ApacheCon
> for about 15 years (twice in most years). I personally give 5-10 such
> presentations a year (sometimes public sometimes not). I'm sure many others
> here do the same.
> The Apache Way is really simple. There are very few immutable rules but
> anything that undermines those rules is not part of the Apache Way.
> The problem is not a lack of clarity its a lack of agreeing what does/does
> not undermine those few immutable. The way we get around that is to have a
> group of members who define it and take any action necessary to ensure the
> Apache Way is protected.
> Those members can become IPMC members and help incoming projects learn the
> immutable rules and how to evaluate whether an action will undermine those
> rules.
> There is a process for building consensus around what is and is not
> acceptable. There is an escalation process if consensus cannot be reached.
> In the IPMC it goes...
> PPMC -> Mentors -> IPMC -> Board -> Members
> In TLPs it is similar:
> Community -> Committers -> PMC -> Board -> Members
> Nobody expects the PPMC to understand. Everyone expects Members to
> understand, which means everyone expects Mentors to understand (see how it
> is designed to be flat?)

You can become a member without ever living through a commit veto, or a
nasty argument about corporate (over)involvement, or any number of other
critical test cases of whether a community is, in fact, successfully
putting the principles into practice. This wouldn't worry me so much except
that I fear that (rarely) some members who have become mentors don't even
recognize when something is happening which calls for them to call for

> This is not a top down organization where rules govern what we can do. It
> is not the boards job to define policy, that's the members job (and the
> IPMC is mostly members). The board are the end of the escalation chain,
> they break deadlocks only (and approve policies defined by the membership).
> In my experience, there are some people who consistently act as if there
is some sort of top-down flow of rules. (In fact, in some cases, I would
even count myself as one of them.) The usual source of floods of email on
this subject is not the community principles of governance, but rather the
legal details of releases. Some people 'round here think that's it is very
important that the contents of NOTICE files are completely correct. Some
podlings have achieved extreme frustration in this area, especially when
some of those people disagree about what constitutes 'correct'. So, when
Martin writes what he writes, I'm reasonably sure that what he's looking
for is not a rule book of how to run a consensus community, but rather
clear, complete, and non-contradictory documentation of how to produce a
proper release.

I have always had a sense that, at the VP Legal level, there is a sensible
application of the legal principle of _de minimus_ -- that, in fact, little
problems with this stuff are just not material. But, if I am right about
that, I feel pretty clear that this does not get communicated downwards.

Here's where I come in as a legalist: at the end of the day, a PMC is a
legal formalism. The board delegates certain legal authority (notable, to
make releases) to the PMC, and appoints the chair. The IPMC thus is a
complex device: on the one hand, it is the legally constituted PMC with
responsibility for the releases of podlings. On the other hand, it has
spent the last few years trying to find ways to push authority downwards
into the podlings. The pTLP business asks, 'well, is there a way to just
simplify this by letting each new project just be a PMC?' My writeup asks,
'OK, if you want that, what _might_ it look like?'

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message