ASF Rules Redux

This is a revision to a prior blog, 13 ASF Practices. Some elements have been condensed, and some new bits added … and now there are 11.
People often mention “Apache Rules”. We don’t actually have a rule book, but if we did, here’s what I believe might be the top eleven practices.

0

Individuals compose the ASF.
Projects must be managed in a collaborative, meritocratic way, so that new volunteers are encouraged to join the project group, and so that the volunteers doing the work are the individuals who make the decisions.
PMC members are encouraged to nominate qualified contributors as new committers.
ASF Members are encouraged to nominate qualified committers as new members.
Given sufficient time and sustained interest, the set of committers should equal the set of PMC members, and the set of PMC members should equal the set of ASF members.

1

Merit never expires.

2

The mailing lists are a project’s only venue for the conduct of business.
All development discussions must occur on the project’s public mailing lists, or be summarized to the lists, and the lists must be archived.
Development support products, like version control systems, issue trackers, and wikis, should log changes to a public mailing list.
Comments posted to a list through development support products are a normal component of development discussions.

3

The project’s private list may only be used to discuss pre-disclosure security problems, pre-agreement discussions with third parties that require confidentiality, nominees for project, project committee or Foundation membership, or personal conflicts among project personnel, and nothing else. Posts to a private list are considered confidential and must not be quoted on public lists without the permission of the author.

4

A project’s primary web site and mailing lists must be maintained on ASF hardware.
Resources maintained elsewhere are not ASF resources, even if maintained by individuals who happen to be ASF committers.

5

Project source code and documentation must be donated to the ASF under a Contributor’s License Agreement.
Donated source code and documentation must carry the ASF copyright and be placed under the Apache License.
Code and documentation donated to the ASF must be maintained on ASF hardware.
Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged.

6

A PMC member can veto a product change with a technical or legal justification.

7

A release must include the ASF source code being released, binaries are optional.
A release vote must be on the actual bits that comprise the release, preferably already digitally signed by a release manager.
An ASF release must be approved by at least three members of the PMC and by a majority of the members voting.
A release cannot be vetoed.

8

Other libraries included with a distribution may be under a different license but must be redistributable under the Apache license.

9

The PMC chair/Project VP must submit regular status reports to the ASF board.

A

Author tags in source code are discouraged but permitted.



Of course, there are other customs of Apache culture, but I believe that most other ASF practices would stem from this initial set. And, as with all things ASF, YMMV! :)