Summary

  • Apache's published rules distinguish a qualified veto on a code-modification proposal, a separately governed formal package release, project-level PMC authority and Foundation-level Board oversight.
  • A release-authority receipt should name the action, artifact, eligible binding group, applicable rule, objections, decision and any distinct corporate step instead of turning a commit, a vote or Board attention into the same mandate.

One foundation, several kinds of decision

The phrase “Apache approved it” can conceal more than it explains. It may refer to a repository change, a mailing-list consensus, a formal release vote, a PMC roster decision, a Board resolution, or merely a director asking a question about a quarterly report. The Apache Software Foundation's own governance pages do not flatten those acts. They distribute responsibility across a project community, a Project Management Committee, corporate officers, Members and a Board of Directors.

That distribution is not bureaucratic decoration. It lets a software project retain technical autonomy while the Foundation remains able to carry legal responsibility, protect common assets and intervene where a project has lost the ability to govern itself. But the structure works only if readers preserve the boundary between technical action, formal release, corporate oversight and Foundation membership.

The most useful starting point is the action rather than the actor. “A committer touched the code” is an action. “A PMC voted to release an identified artifact” is another. “The Board appointed a Vice President, set a Foundation policy or reviewed a report” is another. The same individual may participate in more than one of these layers, yet the layer—not the person's reputation—determines what has been authorized.

Commit access is not formal release authority

The PMC Guide makes the first distinction explicit: committers may update project code, while only the PMC as a body has authority to vote on formal releases of the project's software. That does not diminish a committer's contribution. It says that repository write access and the organizational act of issuing an official Apache release answer different questions.

Code changes can be frequent, incremental and locally reviewable. A release is a named artifact presented under the Foundation's institutional and legal surface. It may collect many earlier commits, but it is not simply the last commit multiplied by a version number. A later reader needs to know which exact source revision or release candidate was presented, who had binding authority for that action, which rule governed it and whether the outcome made an official release.

This distinction also prevents an opposite error. A PMC release vote is not evidence that every line in a repository was individually re-litigated at the Board. The published Apache model places project technical direction with the PMC. Board oversight has a different object: corporate assets, officers, Foundation policy, reports and the health of the project system. A release record should not borrow Board authority merely because the Board receives reports about the project.

A code veto is a specific rule, not a universal red light

Apache's Voting Process separates procedural matters, code modifications and package releases. For a code-modification proposal under normal, non-lazy conditions, the stated rule calls for three +1 votes and no -1 votes. A negative vote from a qualified voter can be a veto; it requires technical justification and cannot be overridden until the voter withdraws it.

That is a strong and useful rule, but its scope matters. It does not mean that every negative comment made anywhere in an Apache discussion freezes every project activity. It concerns the applicable code-modification proposal, the relevant voting group and the qualified voter. Nor does it transform technical disagreement into a claim about corporate ownership, trademark policy or membership election.

The reasoned-veto requirement supplies an important discipline. A veto is not supposed to be a silent block or a personal rank claim. The published rule asks for a technical explanation: a security exposure, a performance problem or another concrete reason the change is bad. The proper response is therefore neither “the veto makes the critic sovereign” nor “a majority can simply ignore it.” The response is to preserve the proposal, version, stated technical basis, qualified status, discussion and eventual withdrawal, modification or abandonment.

The evidence that a code proposal did not proceed is different from evidence that a formal release did not proceed. Conflating them generates bad operational inference. A patch may be vetoed and later redesigned. A release may be delayed for a different reason. An issue can remain open without proving that the PMC or Board has made a permanent policy decision.

A formal release uses another test

Apache's published voting guidance gives package releases a separate path. A release requires at least three binding +1 votes and more positive than negative binding votes. The page also says that releases may not be vetoed. The rule is not a weaker spelling of the code-change rule; it is a different decision design for a different action.

That difference should not be romanticized. It does not prove that release voters all tested the same conditions, that users have adopted the artifact, that every contributor favored it or that no future vulnerability will be found. It does establish a defined PMC-level decision threshold for a formal release. The artifact identity is therefore indispensable. A vote count without the precise release candidate, source revision, signatures or published release identifier cannot tell a reader what was decided.

The common shorthand “there was a -1, so the release was vetoed” is exactly the kind of sentence an authority receipt should prevent. It may describe a code-modification rule, a non-binding comment, a project-specific practice or a release concern raised before a decision. It cannot be treated as the release result without the applicable action type and rule. Conversely, “the release passed” does not erase technical objections already recorded elsewhere. It gives a formal status to a particular release action.

The PMC governs the project; the Board governs the corporate frame

ASF describes PMCs as the bodies that oversee their named projects, set their community and technical direction, manage releases and act within Foundation requirements. The Board creates PMCs by resolution, appoints the project Vice President/Chair as a corporate officer, receives reports and can take action where a PMC is dysfunctional or fails required policy. Yet the same governance material says that the Board does not provide technical direction for individual projects.

This is a deliberate split, not a contradiction. The Board manages corporate assets, intellectual property, trademarks, support equipment, officers and overall policy. Directors do not automatically gain committership, PMC membership or binding technical votes in projects. A director who wants to influence project technology must acquire merit and be elected into the relevant project like any other contributor.

The Chair's role shows the same separation in miniature. A Chair is a normal PMC member for project voting, but also a corporate officer responsible for reporting and keeping the official PMC roster accurate. A PMC may reach a view about a Chair change, but the new Vice President/Chair becomes official only through the Board's resolution process. A project consensus and a corporate appointment are connected records, not interchangeable ones.

ASF Members add a further boundary. Members elect Directors and vote in Member elections. They do not automatically acquire standing to direct a project technically. Membership, project merit, PMC authority and Board office can overlap in people, but the Foundation's published structure does not let overlap erase the separate grants of authority.

Publish a release-authority receipt

The practical proposal is modest: attach a compact, versioned receipt to any significant formal release or governance transition. For a code-modification decision, the receipt should identify the proposal or change set, review route, applicable decision mode, eligible qualified voters, explicit +1 and -1 positions where public, the technical basis of a valid veto, and the final disposition. It should not publish private personnel or security material.

For a package release, the receipt should name the exact release candidate or artifact digest, project, PMC, opening and closing window, binding-voter rule, binding tally, relevant non-binding input, result and official release identifier. It should say that the event is a package-release decision rather than calling every prior code review a release ballot.

For a corporate event, it should separately identify whether the Board acted by resolution, reviewed a report, made a request, appointed an officer, changed a PMC or applied a Foundation policy. It should not relabel ordinary Board awareness as a technical approval. If a technical project act and a corporate action are both present, the receipt should link them as two records with two purposes.

The point is neither to impose a new Apache procedure nor to require every community exchange to become a formal dossier. It is to make consequential words—veto, release, PMC decision, Board action—testable against the authority they actually describe.

Sources

  1. Apache Corporate Governance — PMCs
  2. Apache Voting Process
  3. Apache Project Management Committee Guide
  4. Apache Corporate Governance — Board of Directors
  5. Apache Corporate Governance — Members
  6. Lu Heng, The Multi-Stakeholder Mirage