Page History

...

ASF projects differ in how they do things, but most have documented process for working bug reports, introducing new features and planning and executing releases. As new features are developed and bugs are addressed, code changes are made that will go into releases.  Typically, proposed changes are submitted as “pull requests” (PRs) that explicitly describe how the source will change if they are applied.  The original source, the PR and any changes that result from applying it are all publicly visible.  Any interested party can comment on proposed changes and it frequently happens that performance, security or other issues are discovered in the open development process that creates and modifies ASF software.

• Our contributors tend to be seasoned software professionals whose employers include ASF releases in their commercial products.
• Our communities are healthy, open, and transparent.
• As a result of vulnerability reports, more attention is focused on the specific product, at least for a period of time.  Open source enables a more diverse group of people to participate in these efforts.
• Companies and government agencies that want to help don't need money or formal contracts to do so.  Join our mailing lists, review our code, contribute fixes.

How releases are versioned, validated and distributed (https://www.apache.org/dev/#releases)

ASF software is meant to be consumed in the form of versioned releases.  ASF PMCs have various ways of packaging software for distribution, but the core asset being released is always source code.  Most projects release only source code and are not producing builds of their releases.  Releases must be voted on by PMCs, who are responsible for validating release candidates (RCs).  Most PMCs also make RCs available to the public prior to or during release votes. Library or infrastructure projects sometimes make backward-incompatible changes as they develop new versions of their software.  Sometimes, a backward-compatible version of the software is added and maintained in parallel, but it often happens that the actively supported version is not backward compatible with an older version.   When library or infrastructure components make backward incompatible changes, downstream users may have to make code changes to upgrade their applications.

Who writes ASF code

...

.

How ASF code is incorporated in other software

...