ASF Glossary | Apache Software Foundation

Introducing The ASF’s New Logo Read Now
This glossary provides a brief description of some of the organizational terms used at the ASF and in Apache projects. For more information about anything Apache, see the /dev documentation or the Community Development project.
A file which is created as the outcome of a process, typically the release preparation process.
The Apache Software Foundation, a non-profit organization.
A location for discontinued, abandoned, and retired codebases and projects. The Apache Attic project preserves the information for posterity, reference, and potential future re-activation, while keeping it clearly distinct from active work.
The nine-person legal governing body of the ASF, elected by the members. The board provides the oversight of the Foundation's activities and operation, and applies and enforces the ASF's bylaws. Among other things, the board approves or rejects resolutions brought before it, such as for the creation or dissolution of ASF projects , funding requests, legal concerns, and disciplinary actions. As an open and non-profit corporation, the ASF makes the minutes of board meetings publicly available at https://www.apache.org/foundation/records/minutes/. These minutes include all decisions not made in executive sessions. Also see Director.
Arguing (pointlessly) about which color to paint the bikeshed. As explained here it may happen when the argument is so trivial that it's easy for anyone to have an opinion, and want to see theirs prevail.
A Build is a package which is not suitable for distribution to the general public. Builds are works-in-progress, and should only be available to people working on product development at the Foundation.
Bylaws are a codification of the rules that an organisation follows. Some, such as the ASF bylaws, are legally binding and have significance outside the organisation. Others, such as the Jakarta bylaws, are only meaningful within the community and are only as binding as the community itself makes them. The bylaws of an organisation within the ASF may not contradict those of the ASF proper; any such conflicting parts in the organisation bylaws are necessarily null and void.
1. The Chair of the Board of Directors of the ASF, responsible for the orderly meeting and functioning of the Board. 2. The official head of a committee, such as a Project Management Committee PMC. PMC Chairs are ASF Vice Presidents given charge of the proper operation of their projects.
A meaningful group of source. Some projects use only a single codebase, while others have several.
ASF projects collaborate on code using version control software to coordinate changes. The ability to make direct changes to that code is known as commit access (from the [VCS] commit subcommand). This process patches the actual official code. Also see Karma .
An individual who has the privilege to directly commit changes to an Apache codebase ( commit access ).
(Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code changes which permits developers to make changes at will, with the possibility of a change being retroactively vetoed. C-T-R is an application of decision-making through lazy consensus. The C-T-R model is useful in rapid-prototyping environments, but because of the lack of mandatory review it may let more bugs through in daily practice than the R-T-C alternative. Compare R-T-C, and see the description of the voting process.
Group of individuals with a common cause. The community of a project consists of all those with an interest in that project.
The official developer and user conference of the ASF (see the Community Over Code Web site ).
'Consensus approval' refers to a vote (sense 1) which has completed with at least three binding +1 votes and no vetos. Compare Majority Approval. Also see Lazy Consensus, and the description of the voting process.
Someone who makes consistent improvements to the entities under an ASF PMC, code or documentation or otherwise. This does not, in and of itself, imply commit access, though frequent and valued contributors are readily voted on for such access.
Contributor License Agreement (CLA) is sometimes referred to as Individual Contributor License Agreement (ICLA). There is also a Corporate Contributor License Agreement (CCLA). All are explained on the Licenses page.
See CommitThenReview
The Concurrent Versioning System, an older version control system.
See Software Darwinism.
A user who contributes to a project in the form of code or documentation becomes a developer. They take extra steps to participate in a project, are active on the developer mailing list, participate in discussions, provide patches, documentation, suggestions, and criticism. Developers are also known as "contributors".
One of nine individuals elected annually by the members to the Foundation's board of directors. Directors may or may not have individual responsibilities, but all are generally expected to stay informed about as much of the Foundation's operations and activity as possible, since the Board provides oversight for the Foundation as a whole.
A term used to formally designate someone as no longer active, but still entitled to many of the rights and privileges of the position. For example, an ASF member who hasn't attended any membership meetings for a long time is declared emeritus; someone who no longer has time to work on a particular project may declare themself emeritus. Emeritus status indicates interest but not activity, as opposed to having resigned.
Progress by gradual accumulation of small changes. Typical mode for Apache projects. Compare Revolution.
A portion of a board meeting which concerns confidential matters and which therefore cannot be publicly minuted. Examples include salary discussions, areas covered by non-disclosure agreements, disciplinary actions, and some types of funding decisions.
A version control system used by the majority of ASF projects.
Informal event at which ASF participants can get together,