Page History

...

The ASF doesn't pick technologies or set technical direction for our projects.  There are very few policies and there is no SDLC policy.  Projects to have to adhere to various foundation-wide policies including trademarks, release policy, security vulnerability handling policy. There are very few required policies (and there is no SDLC policy). 

We also require that everything happens in the open:

...

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.

...

Although we use the term "volunteer" extensively in our materials, 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.

...