DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
- The Apache Software Foundation (ASF) is one of the first and largest open source organizationsfoundations, home to many high profile projects.
- Background on the ASF (statistics, videos, and links) can be found at: https://apache.org/.
- Software developed at the ASF is made available at no cost and without warranty, under a license permitting commercial modification and reuse without notification. Many commercial products include ASF software without the end user being aware.
- Projects act independently and set their own technical policies and directions and have their own communities of developers and management
- Required policies exist for important supply-chain functions such as security vulnerability handling and notification, release management and distribution.
...
The ASF is a US 501(c)3 non-profit charity that acts as a steward for several hundred open source projects. The ASF is one of the largest open source organizations in the world, and is home to prolific projects such as Apache Hadoop, Apache Tomcat, Apache Cassandra, and scores of others. The The ASF provides a known and vetted set of governance, intellectual property, and release processes as well as providing a vendor-neutral place for contributors to collaborate. However, within those processes there is a high degree of autonomy for each project. Projects decisions are driven by the people doing the work. The ASF Board of Directors is responsible for project oversight, ensuring the health and vitality of each project.
...
ASF projects are run by Project Management Committees (PMCs). PMC members nominate and vote on new PMC members and collectively manage community, security, trademarks, or other problems. The The PMC plays a key role in technical project oversight, but not the only role. The full project community contributes by working, creating and reviewing patches and contributing to discussion.
The ASF regards all contributors as individuals and volunteers as part of its vendor neutrality. We do this despite the fact that many, if not most, of our contributors are paid by their employers to contribute to projects at the ASF. As part of that neutrality, we expect that all ASF contributors act in the best interest of the project. Additionally, who a contributor works for has no bearing on their standing in any particular project community. Contributors earn different levels of project standing based on their contributions to the project.
- The Apache Way
- How to get involved with the ASF
- https://apache.org/theapacheway/index.html
- https://www.apache.org/foundation/getinvolved.html
How development works (https://www.apache.org/dev/pmc.html)
The ASF doesn't pick technologies or set technical direction for our projects. Projects to have to adhere to various foundation-wide policies including trademarks, release policy, security vulnerability handling policy. However the number of mandated policies is kept to a minimum to allow projects to manage their own processes (for . For example there is no software development life cycle (SDLC policy)) policy mandated by the foundation, each project is expected to set its own.
We also require that everything happens in the open:
...
Software developed at the ASF is made available at no cost and without warranty
Commercial products may include ASF software without entering into any form of contract with the ASF, or even notifying us
- Vendors of said commercial products though, must inform end users as indicated in section 4a of the Apache License, Version 2.0
- Once informed, it is the responsibility of end users to keep track of whether and where an ASF software is used and which version(s), possibly with the help of a Software Asset Management (SAM)
- End users may purchase these products but may have little interest or ability to apply fixes
- There is a natural nesting that happens as software dependencies propagate through applications. Addressing vulnerabilities in base level components (e.g. log4j) has a cascading impact. Unless and until all downstream systems have effectively automated build, test and deployment systems, this creates systemic risk which has nothing to do with OSS per se.
- ASF software is used in running systems in basically 2 ways:
- A distributed system includes a running ASF product (e.g. Apache web server)
- ASF software is integrated with other software to build applications. When applications created are themselves used to create other applications, nesting happens, causing the impact of a vulnerability or incompatible change at the lowest level to have a cascading impact. When a new release is made available by an ASF project, downstream users need to minimally make configuration changes and test their systems. They typically have to rebuild and redeploy their applications. In nested situations, this often has to happen sequentially.
...