This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Project Governance

Revision as of 14:28, 9 April 2009 by Jason Li (talk | contribs) (New page: This is a DRAFT page still under development by the Global Projects Committee =Introduction= As OWASP gains more and more visibility in the industry, the quality of OWASP Projects an...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This is a DRAFT page still under development by the Global Projects Committee


As OWASP gains more and more visibility in the industry, the quality of OWASP Projects and the OWASP website becomes more important. Past OWASP Seasons of Code have slowly but surely brought a shift in quality to OWASP Projects but there is still much work to be done. This proposal outlines the policy changes drafted by the Global Projects Committee in order to improve the overall state of OWASP Projects, and by extension the OWASP website. Current Project Qualifiers Currently, all projects are categorized as Alpha, Beta, Release or Inactive. The OWASP Project Assessment Criteria has clear definitions for Alpha, Beta and Release quality projects, but the evolving nature of all OWASP projects limited the ability of these qualifiers to fully characterize the current state of the project. For example, the ESAPI project is classified as “release quality” projects and yet contains numerous different versions (.NET, Cold Fusion, PHP, etc) as well as different releases for which a formal assessment has not necessarily been performed. The problem lies in the fact that there are many dimensions to a project and the Alpha, Beta and Release qualifiers are currently assumed for all dimensions of the project. As such, the Global Projects Committee proposes to separate characteristics used for project evaluation and apply appropriate the qualifiers.

Project Status vs. Project Versions

First and foremost, we propose two primary dimensions: individual project versions and overall project status. In the software industry, this strategy is already in use at major open source organizations like the Apache and Eclipse Foundations. Individual projects have a release cycle where projects versions go through alpha, beta, release candidate and then finally release versions. In addition, projects at these organizations are classified by project status. Namely, both foundations have an incubator for projects that are in “incubation” that have not yet reached full maturity. These two dimensions are independent of one another. There is no reason why a project in incubation cannot have release quality versions or a project not in incubation cannot have an alpha quality version. We believe this distinction allows for greater expression of the quality of OWASP projects and releases. It removes any “stigma” associated with being a Beta or Alpha Status project while still allowing OWASP to characterize the quality of any project deliverables. As the Global Projects Committee defines Project Assessment Criteria v2.0, we will take the existing criteria and reorganize them with these dimensions in mind. For example, a characteristic like having a project mailing list would become a requirement relating to project status where as having project reviewers would become a requirement relating to project versions.

Project Versions

The Global Projects Committee intends to keep the Alpha, Beta and Release designations as qualifiers for project versions. By associating these designations with versions, these quality designations become associated with specific deliverables. In that sense, it becomes possible to have consistency across all OWASP projects necessary for potential OWASP users to evaluate the version of a project they are using. This system also allows high visibility projects to maintain different versions that may still be under development, and therefore unstable, without compromising the quality status associated with the overall project.

Project Statuses

The Global Projects Committee plans to introduce the following designations as qualifiers for project status: Startup, Incubator and Community Endorsed. Projects that are just starting and have not made any deliverables will be designated as Startup projects. Upon successful completion of incubation entry criteria (to be defined), a project will be designated as an Incubator project. A project in incubation that has achieved a positive track record with deliverables, established itself within the community, and achieved incubation exit criteria (to be defined) will be promoted as a Community Endorsed project.