FINAL DRAFT TO BE RELEASED 9/23/2011
OWASP Global Projects Committee
Produced: Jun 30th, 2011
Initial GPC Review: July 8th, 2011
Table of Contents
This handbook was made possible thanks to the support from:
These organizations directly supported the June 2011 GPC Working Session where the majority of these policies were hash out.
The goal of an OWASP Project is to create a concrete deliverable - such as a document, a tool, or a code library - that furthers the OWASP mission. Projects are one of the primary methods by which OWASP strives to achieve its mission to make application security more visible. As openness is one of OWASP’s core values, all projects at OWASP are required to use an approved open-source license. OWASP projects are divided into the following major categories:
Like all things in OWASP, projects are driven by volunteers and open to everyone. That means anyone can lead a project, anyone can contribute to a project, and anyone can use a project. This handbook is meant to be the primary reference for OWASP project leaders and should serve as a useful starting point for anyone that wishes to start their own project. In addition, project leaders can find out how to get certain OWASP benefits available to projects. ( where to find) The Global Projects Committee can be reached at firstname.lastname@example.org for any questions not addressed in this handbook.
Starting an OWASP project is very easy. Projects and their leaders are simply expected to uphold the OWASP core values: openness, innovation, internationalization, and integrity. Beyond these principles, a potential project leader with an idea only needs a project name, a project description, and a roadmap.
Projects must be open in all facets, including source material, organizational structure, and finances (if any). Project source code (if applicable) must be made openly available; project communication channels (e.g. mailing lists, forums) should be open and free from censorship; and all project materials must be licensed under an open source license as approved by the Free Software Foundation (FSF).
Projects are expected to be innovative and address an application security concern. Projects can be ideas turned into a proof-of-concept, new implementations of familiar ideas or tools, or something altogether different. The OWASP philosophy is to try many things and fail fast. What this means is that we want you to bring projects forward, no matter how small or large or unlikely as they may seem. Project leaders are encouraged to be forward thinking in their ideas.
Projects are not expected to be internationalized from day one, but they are expected to keep the international audience in mind for future development. OWASP resources and assistance are available to help in translation efforts, but project leaders will need to ensure that their project is flexible enough to support internationalization.
Projects must uphold the integrity of OWASP and must not unduly promote a specific company, vendor or organization. While OWASP welcomes corporate sponsorship of a project, project leaders must ensure that any such relationship is disclosed and that the project continues to be vendor agnostic. Project leaders must use the appropriate project designation to refer to their project (as explained later) and must not abuse the OWASP name. Project leaders must also conduct themselves according to the OWASP Code of Ethics at all times (not just in relation to their project - About OWASP: Code of Ethics:add in).
OWASP does not require a transfer of ownership of your project. Each project leader and contributor owns their own contributions, just like in any other major open source project. If project leaders who own all copyrights of their project and no longer wish to be involved with the day to day management of their project, they are welcome to donate their copyright ownership to OWASP if they desire, however this is not required nor the norm.
OWASP Projects, along with Global Conferences and Local Chapters, are the cornerstone of the organization. Therefore, we want to provide a fostering environment for new ideas and energetic project leaders. However, the world at large also depends on OWASP to provide dependable, quality projects. The OWASP Projects Lifecycle represents a balance between keeping a very loose structure around OWASP projects, while ensuring that OWASP consumers are not confused about a project’s maturity.
The lifecycle stage allows consumers to easily identify and distinguish between established, mature, quality projects from projects that are proofs of concept, experimental, prototypes, or still maturing. The greater the maturity of the project, the greater the level of responsibility for the project leader. These responsibilities are not trivial so OWASP provides incentives and benefits (as discussed later) for projects and their leaders/contributors who take on those added responsibilities.
The OWASP Project Lifecycle is broken into the following stages:
Each of these stages is described in greater detail in the sections that follow. At a minimum, all OWASP projects have: a project name, a project description, a project roadmap, and a project leader.
A project name may include the OWASP name. If a project chooses to use the OWASP name, any project artifacts must clearly state the project’s current lifecycle designation. For example, this notice can be on the cover page (documentation), in an ‘About’ dialog (tools), in comment header blocks (code), or some other prominent location.
A project description should be a description of the purpose of the project and the value it provides to application security. Ideally, project descriptions should be written in such a way that the start of the description can be used as a teaser or an excerpt (as commonly done for news articles and blog postings). This teaser will be seen and used in various places in the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, and project leaders should ensure that the teaser is concise and meaningful.
A project roadmap is an envisioned plan for the project. The purpose of the roadmap is to help others understand where the project is going. It gives the community a chance to understand the context and the vision for the goal of the project. Additionally, if a project becomes inactive or if the project is abandoned, a roadmap can help ensure a project can be adopted and continued under new leadership. Roadmaps vary in detail from a broad outline to a fully detailed project charter. Generally speaking, projects with detailed roadmaps have tended to develop into successful projects. Therefore, the GPC encourages projects to take the project roadmap seriously. Some details that leaders may consider placing in the roadmap include envisioned milestones, planned feature enhancements, essential conditions, project assumptions, development timelines, etc.
A project license must be chosen from the set of OWASP-approved open source licenses. While OWASP does not promote any particular license over another, statistically the vast majority of projects have chosen a Creative Commons license variant for documentation or a GNU General Public License variant for tools/code.
As innovation is a core value, OWASP welcomes all project ideas that further the OWASP mission and are consistent with OWASP values and ethics. OWASP believes in pursuing lots of experiments by using a “fail-fast” model where successful experiments are quickly supported and ideas that are not proven out are removed.
OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity. The label also allows project leaders to leverage the OWASP name while their project is still maturing.
OWASP Incubator projects are given a place on the Projects Portal to leverage the OWASP Projects Infrastructure and establish their presence and project history. Many of the benefits and privileges afforded to projects are dependent upon metrics and statistics that are automatically tracked by the OWASP Projects Infrastructure. There are a number of resources that may be made available to Incubator projects depending on these metrics and statistics.
In exchange for these privileges, leaders of Incubator projects must take on some responsibility. Like all projects, the leader must establish a project name, description, roadmap, and an appropriate open source license. These details will be used to populate the project’s official register on the OWASP Projects Portal.
In addition, leaders of Incubator projects are expected to produce a draft or development release as a downloadable file on the project page within twelve (12) months of project inception. As previously mentioned, OWASP believes in pursuing ideas in a fail-fast manner. In order to avoid an excess of stagnant projects that never mature, projects will not be permitted to linger in an undeveloped state beyond this time period. If a project has not produced at least a draft or development release, the project will be removed from the OWASP Projects Portal. If a project leader subsequently produces a completed release and wishes to re-associate with OWASP Projects, such a project can be returned to the OWASP Projects Portal through the Project Donation Process.
Once a project leader has completed at least one version of a concrete deliverable, the project is eligible for graduation into the OWASP Labs. A project leader that wishes to graduate to OWASP Labs should obtain five (5) project evaluations as specified in the Project Graduation Process. Note that graduation to the OWASP Labs is optional and a project leader that has completed at least one concrete deliverable may continue in the OWASP Incubator indefinitely.
While OWASP welcomes all projects, the organization recognizes that not all projects are at the same stage of maturity. Project leaders want some way to distinguish themselves among the vast OWASP project landscape. OWASP consumers also want an easily understood way to differentiate projects. Projects that are still in development or are simple proofs of concept are different that projects with releases that have functional value.
OWASP Labs projects represent projects that have produced a deliverable of value. These projects have matured to the point that they are accepted by at least a portion of the OWASP community. Leaders of OWASP Labs projects are expected to stand behind the quality of their projects. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are at least ready for mainstream usage.
OWASP Labs is meant to be the collection of established projects that have gained community support and acclaim by undergoing the project review. These reviews are part of the Project Graduation Process that is required to enter OWASP Labs. To enter the OWASP Labs, at a minimum, projects must be actively maintained, leverage OWASP standards, and seek to provide value. In addition to a designated project leader, an OWASP Labs project must also have a designated point of contact. These roles may be fulfilled by one individual.
In recognition of these qualities, such projects are afforded a number of benefits (subject to GPC funding availability) to help grow the project including graphic design support, technical writing reviews, and UI design reviews. OWASP Labs projects have the primary spotlight in the Projects Portal and receive the most promotional opportunities. OWASP Labs projects will be featured in the annual “OWASP Book” and the OWASP Translation working groups will be encouraged to prioritize their efforts on Labs projects. In addition, OWASP Labs projects can be considered for OWASP Flagship status.
While projects that graduate to the OWASP Labs can remain there indefinitely, project activity is a prominently featured piece of metadata on the Projects Portal. Projects without periodic activity will be automatically tagged as inactive. As a result, project leaders are encouraged to maintain the level of excellence attributed to OWASP Labs projects.
Beyond just maturity, OWASP also recognizes the need for a platform for application security. The goal of OWASP Flagship projects is to identify, highlight, and support mainstream OWASP projects that make up a complete application security platform composed of OWASP Projects. Selection of Flagship projects is driven by the GPC’s SDLC Project Mapping and eligible projects are selected from the OWASP Labs by the Global Projects Committee, in consultation with a working group of independent industry experts. This selection process generally ensures that there is only one project of each type covering any particular security space. These projects are selected for their superior maturity, established quality, and strategic value to OWASP and application security as a whole.
OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining. The core mission of OWASP is to make application security visible and so as an organization, OWASP has a vested interest in the success of its Flagship projects. Since Flagship projects have such high visibility, these projects are expected to uphold the most stringent requirements of all OWASP Projects.
Flagship projects are provided graphic design support and technical writing review in order to ensure deliverables are high quality, polished products. Flagship projects are expected to have a core team of project contributors that responds in reasonable time to issue tracking and provides support for project promotion (e.g. project pamphlets, intro presentations, media interviews, etc). The presence of a team also ensures continuity for a project if one project contributor is unavailable or leaves the project.
Selection for OWASP Flagship designation is by invitation only. A Labs project leader can present their case for why they think their project deserves Flagship status. However, there is not a deterministic process to be designated a Flagship project. There are no steps to be followed that guarantee Flagship status. This status is reserved for the strategic use of OWASP to identify a platform that supports the OWASP mission to improve the state of application security.
Projects that are selected for the Flagship designation do not retain this designation indefinitely. The SDLC Project Mapping, which drives Flagship selection, is reviewed semi-annually at the GPC Working Sessions. During that review process, the Flagship Selection Working Group examines that status of current Flagship projects. The working group also looks at rising projects for areas where a Labs project may have superseded an existing Flagship project in maturity, quality, features, or relevance.
In such cases where a Flagship project is superseded by a rising Labs project, the Flagship project will undergo the appropriate migration process to ensure a smooth transition back to the OWASP Labs. Likewise, the Labs project will undergo a transition process in order to ensure the project is properly elevated. The OWASP Flagship “platform” is a constantly evolving entity and Labs projects should not be discouraged by the presence of a Flagship project in the same functional space.
OWASP recognizes the need for project consumers to quickly ascertain the maturity of a project. As an organization centered around its community and dedicated to openness, project evaluations are done in an open manner. Project reviewers can be anyone - inside or outside of the OWASP community. The goal of a project review is to establish a minimal baseline of project characteristics.
The review centers around the following core questions:
These questions were designed to distill the core characteristics of a healthy OWASP project. Collectively, they encompass everything from “Does this project actually do anything?” (#5), to “Is there a bug tracker?” (#1), to “Does it use the OWASP name appropriately?” (#3), to “Is this project actually any good?” (#2).
To facilitate the review, the Projects Portal provides reviewers with a “Review Dashboard”. This dashboard displays relevant details, automatically gathered metrics, and guiding sub-questions to help reviewers perform the review. The results of these reviews are published openly and available to project consumers. Aggregate statistics are also provided and used to drive project placement on the Projects Portal, eligible benefits, and graduation from Incubator into Labs or selection to Flagship.
As previously mentioned Project Reviews are open to anyone - inside or outside of the OWASP community. This openness ensures that project leaders have a wide audience to solicit for project reviews. However, the openness also decreases the consistency in quality of review.
While anyone inside or outside of the OWASP community can contribute a Project Review, there is a need for at least some review by “trusted” parties. The Reviewer Pool is a mechanism to ensure there are qualified reviewers making quality reviews of OWASP projects. The Reviewer Pool is set of veteran reviewers who have proven themselves dedicated to executing quality reviews of projects. Any reviewer that has completed ten (10) project reviews in the last twelve (12) months is eligible to join the Reviewer Pool. Members of the GPC and the Board are also automatic members of the Reviewer Pool, as are any paid professional project reviewers retained by the GPC.
Members of the Reviewer Pool will be asked to fill their user profile, which will be visible to OWASP consumers as a testament to why their reviews have merit and relevance. Members of the Reviewer Pool serve a critical role in ensuring the quality of projects and will gain added recognition in OWASP.
The Project Reviews provides a way to look comprehensively at the overall maturity of project. However, there is significant value in a simple rating system to allow projects to solicit general feedback. The Projects Portal allows users to rate projects and leave generic feedback for both individual releases, and the overall project. These feedback responses are provided to project leaders and also used as part of the overall evaluation of project maturity.
While the OWASP Project Lifecycle may seem unwieldy, the goal of the lifecycle is to simplify OWASP project management. The following sections describe streamlined processes to move through the OWASP Project Lifecycle.
The Project Inception Process is how a brand new idea becomes an OWASP Project. Such projects are placed in the OWASP Incubator project. The process involves submitting the proposed project name, project description, project roadmap, and appropriate open-source license for the project using the New Project Form on the Projects Portal.
Once a request has been submitted, the proposal will be made open to the community for review and feedback for a period of five (5) days. Unless there are any critical objections or concerns that the project violates OWASP principles, the project will be automatically created in the OWASP Projects Infrastructure. The infrastructure will create the following items for the project:
An announcement will be made regarding the new Incubator project and the project leader will have twelve (12) months to produce a functional deliverable.
The Project Donation Process is used for a project that has an existing functional release, but is not currently associated with OWASP. This process is the primary mechanism by which individuals or organizations can share their existing project with OWASP. Project donation types include partnerships and endowments.
Partnerships occur when the project owner has decided to adopt OWASP principles and processes for their project. Such owners wish to continue their leadership and involvement with the project, but want their project to be included in the OWASP Project landscape. OWASP welcomes all such project owners and partnerships are the most common type of project donation.
Endowments occur when the project owner has created a project and wishes to completely turn over the project to OWASP. Such owners feel their project has some value, but do not wish to stay involved in the process. As a result, they would like someone at OWASP to “adopt” the project. In order to properly adopt such projects, owners may need to assign OWASP certain rights in order for the organization to properly accept the project. Though these situations are rare, OWASP welcomes all project endowments and will work with any such project owner to ensure a smooth and proper transition.
The donation process requires submitting the project name, project description, project roadmap, an appropriate open-source license choice, and the type of donation. In addition, the latest functional release should be uploaded along with the request. These items can be submitted through the Project Donation Form on the Projects Portal.
Once a request has been submitted, the proposal will be made open for review and feedback for a period of five (5) days. Unless there are any critical objections or concerns that the project violates OWASP principles, the project will be created in the OWASP Projects Infrastructure and the project owner will be provided the same project setup and resources as in the Project Inception Process. Note that endowments may be held for additional review in order to ensure that OWASP can properly make use of the project.
The project owner will be expected to migrate their project to the OWASP Projects Infrastructure and utilize these resources. OWASP understands that long standing projects may have established communities that make migration difficult or inappropriate. Exceptions to this policy will be made on a case-by-case basis. In such cases, project owners will need to work with the GPC to ensure the appropriate project artifacts and details are regularly synchronized to the Projects Portal. At minimum, a project home page and profile entry will still exist for the project even if the project is not hosted on the OWASP Projects Infrastructure.
Once the project has been migrated and the donation is complete, an announcement will be made regarding the project donation.
The Project Transition Process is used to transition leadership of a project to a new project leader. This is a simple automated process to transfer the relevant accounts, mailing lists, and other project resources to the new project leader. The current project leader should log into the Projects Portal and submit a Project Transition Request identifying the new project leader. The proposed leader will receive a request to confirm their new role. Upon receiving the new leader’s confirmation, the Projects Infrastructure will transfer the project to the new leader. An announcement will be made regarding the leadership transition.
The Project Adoption Process is a special case of the Project Transition Process for inactive projects. Any OWASP community member may volunteer to adopt an inactive project by submitting an Project Adoption Request through the Projects Portal. Upon receiving an adoption request, the GPC will contact the current leader of the inactive project in question. An inactive project leader can relinquish leadership of the project to the new proposed leader through the Project Transition Process. If no reply is received and no constructive activity is detected within thirty (30) days of contacting the inactive leader, the GPC will transition the project to the proposed adoptive leader. An announcement will be made regarding the project adoption.
The Project Removal Process occurs periodically through automated and manual review. The purpose of this process is to migrate projects that have been identified for removal off of the OWASP projects infrastructure. Possible reasons for removal include (but are not limited to) inappropriate evolution of a project that results in contradicting OWASP core values, abuse of OWASP project services or infrastructure, expiration of Incubator projects that have not developed into a functional product.
Any project can be “flagged” by anyone that questions the appropriateness of a specific project. The GPC will periodically examine projects that are excessively flagged.
The OWASP Projects Infrastructure automatically flags Incubator projects without a submitted release that have exceeded their time in the Incubator. Such project leaders will be warned in advance of this deadline. Upon the deadline, if no release has been submitted, the infrastructure will remove the project from the system. Additionally, the GPC will periodically review a random sample of Incubator projects to ensure that submitted releases are indeed “functional”.
A project that has been previously removed from OWASP cannot be submitted again through the Project Inception Process by the same project leader. If a project leader wishes to associate a removed project with OWASP, the leader may submit a completed deliverable through the Project Donation Process.
The Incubator Graduation Process is an optional process undertaken at the request of a project leader. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs. In order to be considered for OWASP Labs, an Incubator project must have submitted a functional release and obtained an aggregate of at least five (5) positive responses for each of the core Project Review questions. For example, if a project has had eight (8) reviews and five (5) of those reviews respond affirmatively to question #2, while three (3) of those reviews respond negatively to question #2, the aggregate score for that question would be two (2). Such a project would not be eligible for graduation.
In addition, at least one review must be performed by a member of the Project Reviewer Pool and their review must result answer affirmatively to each of the core Project Review questions. While the Project Reviewer Pool is generally responsive, the Incubator Graduation Process is not meant to be an impediment to maturing projects. Therefore, if a project leader has requested to graduate from the OWASP Incubator and the project fulfills all other graduation requirements except for the Reviewer Pool review, the GPC will ensure that the project receives a timely review. In such cases, the GPC will make a call for reviewers from the review pool. If no reviewer can be found within fourteen (14) days, the GPC will at its discretion pay for a professional, third-party reviewer to complete the review.
Upon confirmation that a project fulfills the requirements of the graduation process, a project will graduate from the OWASP Incubator to the OWASP Labs. An announcement will be made regarding the project graduation.
As entrance into the OWASP Labs provides greater benefits and visibility, the GPC expects that many project leaders will aspire to graduate from the Incubator as quickly as possible. In order to prevent undue strain on the Reviewer Pool and GPC resources, if a project leader makes a graduation request that is not subsequently confirmed by a review from a Reviewer Pool member, the project leader will not be permitted to make another graduation request for the project for a period of six (6) months. As a result, project leaders should be certain that their project is in good order prior to making the graduation request.
The Flagship Designation Process is a process undertaken to transition a Labs project that has been provisionally designated as a Flagship project. Selection of Flagship projects is driven by the GPC’s SDLC Project Mapping. The goal of this mapping is to ensure that OWASP is achieving its goal at promoting application security by providing projects that support the spectrum of application needs. The mapping is maintained and reviewed semi-annually by the GPC, in consultation with a working group of industry experts.
A project that is designated a Flagship project will be given provisional status as a Flagship project. This provisional status is given for a period of six (6) months during which time project contributors are expected to work on the project with graphic designers, technical writing reviewers, and other OWASP resources to attain polished project. If at the end of this transition period, the project successfully attains the expected quality level, the project will be a confirmed Flagship project. An announcement will be made regarding the project’s Flagship designation. The project will also be invited to designate a contributor to participate in the OWASP Track.
If the confirmed project was selected to supersede another Flagship project, that project will subsequently be returned to the OWASP Labs. Projects that return to the Labs continue to be active projects and may take advantage of benefits afforded to Labs projects. An announcement will be made affirming the project’s value and continued activity. A project that has returned to the Labs is still eligible for future re-designation as a Flagship project.
The Existing Project Migration Process is a one-time process undertaken in order to transition OWASP projects from the Assessment Criteria v2 to the OWASP Projects Lifecycle. As part of the June 2011 GPC Working Session, the GPC performed a complete inventory of all known OWASP Projects. During this inventory, each project was evaluated using specific criteria and assigned a provisional state in the OWASP Projects Lifecycle. These provisional assignments were made effective upon the launch of the OWASP Projects Infrastructure (September 2011).
Certain projects were identified during the inventory as having never created a functional release despite being over a year old. Such “graveyard” projects were removed from the system and were treated as if they had undergone the Project Removal Process.
Projects provisionally placed in the OWASP Labs and projects that are provisionally designated as Flagship projects had six (6) months to confirm their status by fulfilling the appropriate requirements. During this provisional period, the Reviewer Pool requirements will be eased in order to bootstrap the process of populating the pool. This bootstrapping process will also make more reviewers available to project leaders to fulfill the appropriate requirements within the provisional period. After this provisional period, if such projects did not fulfill the appropriate requirements, they will be assigned to the OWASP Incubator.
Projects that are provisionally placed in the OWASP Incubator can graduate to the OWASP Labs at any time by undertaking the Incubator Graduation Process. However, note that during this transition period, the GPC will increase the window for providing a paid Reviewer Pool review from fourteen (14) days to three (3) months. This extension is simply to allow time for the Reviewer Pool to populate itself before depending on paid resources.
The requirements laid out for the various stages of project maturity can be arduous. Since, all project leaders are volunteers, OWASP recognizes the need for incentives for both the project leader and the project itself. The following section provides a list of standard resources made available to project leaders based on their project’s current maturity level.
As part of the project home page provided by the OWASP Projects Infrastructure, all projects can solicit financial donations.These donations are processed through OWASP’s existing financial infrastructure. As a result, these transactions go through the appropriate accounting and auditing channels to remain compliant with relevant regulations. In addition, projects are eligible for the 60/40 Membership split. Newly registered paid OWASP members can designate a project or chapter of their choice to receive the split from their first paid membership fee. If a new member designates a project, that project will receive 40% of the membership fee.
While these financial resources are available to project leaders, there are strict rules for what these funds can be used for. In particular, these funds cannot be used to pay project leaders or contributors for their time spent working on the project. These funds are meant to be used towards project expenses. Some examples of acceptable project expenses include: production costs for making distributing project releases for promotion (e.g. sample book printing, CD pressing, etc); project services to improve a project (e.g. graphic design, technical writing review, UI design review, etc); travel expenses for project working sessions.
Projects can request reimbursement from OWASP out of their available funds for eligible expenses. Consult the OWASP Expense Policy for more information on acceptable expenses and for reimbursement processes.
OWASP has a signing certificate that can be used to digitally sign project releases. The signature can include signing: PDFs (or similar file) versions of documentation projects, code library projects, or tool projects. In order to have a release signed by OWASP:
In support of projects, OWASP has a team of technical writers available on retainer to review project documentation. Technical writers will not create documentation for OWASP projects. The goal of the technical writing review is to provide feedback to project leaders to improve their documentation. This review can be conducted not only for documentation projects, but also for user documentation created for tools and code libraries. As funding is limited, technical writing reviews may need to be restricted by the GPC. Generally, in order to have a project reviewed by a technical writer, the project must be:
Additionally, leaders are encouraged to only submit major releases for review as the GPC will generally limit individual projects from receiving multiple technical writing reviews for minor releases. Note that the OWASP technical writing review team can be engaged by project leaders for extra review work at reduced rates using available funds from their project budget.
In support of projects, OWASP has a team of graphic designers available on retainer to support projects. The goal of the graphic design is to enable project leaders to create polished, professional looking projects. As funding is limited, graphic design may need to be restricted by the GPC. Graphic designers will create a logo or icon for OWASP projects that meet the following requirements:
Only one logo or icon will be created per project, though the OWASP graphic designer team can be engaged by project leaders for extra design work at reduced rates using available funds from their project budget.
OWASP recognizes that project leaders often have difficulty objectively reviewing their own projects. The goal of a professional project review is to enable project leaders to receive constructive, objective feedback on how to improve their projects. The GPC retains the services of professional project reviewers to help manage projects. These reviewers can be engaged by project leaders for professional review work at reduced rates using available funds from their project budget. Additionally, reviews performed by these professional reviewers is sufficient to fulfill the Incubator Graduation requirement for a review performed by a member of the Reviewer Pool.
OWASP recognizes that many organizations that will want to use OWASP Projects want some assurance that a project is “secure’. Regardless of how OWASP community members feel about specific testing methodologies or particular security vendors, the reality is that external organizations value products that can make security assertions over ones that cannot. Therefore, project leaders understandably want to demonstrate the security of their project. To help support that, the GPC regularly seeks out corporate sponsorships with security vendors to provide security assessment services for OWASP Projects. These services can be requested as they become available. To be eligible to receive such services for a release, the project must meet the following requirements:
Many tool and code projects have rapid development cycles and make frequent releases. Organizations generally like to stay informed when a newly available version of a project they are using is released. The purpose of the Project Update Notification Service is to provide a single centralized service for OWASP consumers to be informed about project updates. This service publishes notifications of project updates to listening clients. These updates can be received via any OWASP standard notification client. Developers can also build notification monitoring into their developed tools.
In order to have a project release or update announced via the Project Update Notification Service, a project must meet the following requirements:
The GPC recognizes that project leaders want to obtain visibility for their project. OWASP provides a number of ways projects can attain visibility. The Projects Portal is the primary manner provided by the GPC to promote the visibility of projects. The main splash page of the portal shows a small random selection of projects to ensure fair access to prime visibility. However, side bar and banner placement is reserved for project promotion. Placement in these locations is apportioned automatically based on a heuristic that processes the metadata captured by the OWASP Projects Infrastructure. Projects can expect to be highlighted or “featured” for several reasons, including but not limited to:
The GPC also uses statistics and metrics gathered by the OWASP Projects Infrastructure are used to determine nominations for OWASP Awards. These awards are presented at OWASP Global AppSec Conferences and recipients will have their project profiles updated with the appropriate OWASP Awards ribbon.
Additionally, the GPC works jointly with other committees and communities within OWASP to provide additional promotion opportunities. In addition to the individual requirements listed below, projects that wish take advantage of promotional opportunities at OWASP must create the project promotional materials:
The Project Pamphlet is a one page data sheet summarizing the project and promoting its value. This pamphlet is used by the appropriate parties to obtain a brief overview of the project to determine suitability for the promotional opportunities below. The pamphlet also serves as ideal marketing literature for the project to be featured at the OWASP Booth at select conferences.
The Project Briefing Presentation is at least three slides presenting the project and highlighting main project features. This presentation is used by appropriate parties to obtain additional information about a project to determine suitability for the promotional opportunities below. The presentation also serves as an ideal way to promote the project at local Chapter meetings and OWASP outreach events.
The OWASP Track is a joint effort by the Global Conferences Committee in conjunction with the GPC. The goal of this effort is to highlight OWASP projects and activities. The GPC participates in the OWASP Track selection process and projects can receive preferential invitation through positive project development. These preferential invitations are provided as available to projects that:
Note that while the GPC has a voice in the OWASP Track selection process, the final decision to accept a conference talk proposal rests with the OWASP Track Program Committee.
OWASP creates two annual compilations: the OWASP Book, and the OWASP DVD. These compilations are among the common promotion items provided by OWASP to conferences, chapter meetings, and other promotional outlets. The compilations are professionally designed and polished to ensure a quality image.
The OWASP Book is an anthology of printable OWASP Documentation projects that have made a major release since the previous edition of the OWASP Book. Likewise, the OWASP DVD is a compilation of OWASP Documentation, Tools, Code, projects that have made a major point release since the previous edition of the OWASP DVD.
In order to be considered for these compilations, a project must:
Note that while every effort will be made to include any projects that requests inclusion and meets the above requirements, circumstances may prevail that preclude a projects inclusion (e.g. a document is too long to fit practically in an anthology along with other documentation projects, or a tool is too large to fit practically and allow other projects to be highlighted).
Additional promotional opportunities are available through a number of other initiatives, activities, and even other projects within OWASP.
For example, the OWASP Web Testing Environment (formerly the OWASP LiveCD), Podcast, AppSec Tutorial Series, and CBT projects all interact other OWASP projects. These types of projects can provide cross-promotion opportunities for other projects.
Likewise, there are multiple teams working on internationalization that support ongoing translation efforts. These teams can provide translation services that will help projects reach wider audiences.
OWASP also holds and participates in many industry and community events, including local chapter meetings, regional events, and outreach activities. Projects can gain increased exposure through OWASP presence at these events.
Note that while the GPC encourages project leaders, translation team members, chapter leaders, conference planners, and outreach leaders to consider promoting mature projects, the final decision rests with those community members.
FINAL DRAFT TO BE RELEASED 9/23/2011