OWASP 2014 Project Handbook

= Overview = Projects are one of the primary methods by which OWASP strives to achieve its mission, which is to make application security more visible. OWASP Projects provide a community based, online platform that allows project leaders the opportunity to freely test ideas and theories in an open environment. Leaders are able to leverage the OWASP brand, and the help of a dedicated OWASP project manager to guide development. 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. OWASP projects are divided into the following major categories:


 * Documentation Projects: These projects seek to communicate information or raise awareness about a topic in application security. Note that documentation projects can take any media form (e.g. CBT, videos, games, etc.) and are not limited to a print deliverable.


 * Tool Projects: Tool projects aim to create software that enables users to test, detect, protect, or educate themselves using a facet of application security.


 * Library Projects: These projects provide libraries/frameworks that can be leveraged by developers to enhance the security of their applications.


 * Operational Projects: These projects are a bit different than the types above. They were created to offer OWASP operational support. Some examples of operational projects include the OWASP Media Project whose contributors work on managing the OWASP YouTube channel along with working towards developing media content for the foundation.

As with all OWASP groups, OWASP Projects are driven by volunteers, and they are open to everyone. This means that 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 it should serve as a useful starting point for anyone that wishes to start their own project within the OWASP organization.

= Project Requirements = Starting an OWASP project is a very easy process. You simply have to submit an application to start your project, and work on it under the OWASP Projects umbrella. Additionally, projects and their leaders are expected to not only know and follow OWASP Project policies and guidelines, but they are expected to uphold the OWASP core values as well. The OWASP core values are: openness, innovation, internationalization, and integrity. Beyond these principles, a potential project leader with an idea only needs a project name, a project description, a project license choice, and a project roadmap.

Openness
OWASP Projects must be open in all facets, including source material, contributors, organizational structure, and finances (in 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 a community friendly license as approved by the Free Software Foundation (Appendix 8.2).

Innovation
All OWASP Projects are expected to be innovative, and address an application security concern unless they are operational projects. 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! This means that we want project leaders to bring projects forward, no matter how large or small, and no matter how unlikely they may seem. Project leaders are encouraged to be forward thinking in their ideas and designs.

Internalization
A project is internationalized when all of the project’s materials and deliverables are consumable by an international audience. This can involve translation of materials into different languages, and the distribution of project deliverables into different countries. OWASP 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 ﬂexible enough to support internationalization.

Integrity
OWASP Projects must uphold the integrity of The OWASP Foundation, and must not unduly promote a speciﬁc 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 a vendor agnostic endeavor. Project leaders must use the appropriate project designation to refer to their project and must not abuse the OWASP brand. Project leaders must also conduct themselves according to the OWASP Code of Ethics, and must follow OWASP Project policies and guidelines, at all times (Appendix 8.3).

Ownership
OWASP does not require a transfer of ownership of your project as all OWASP Projects must be offered under an open source license. Open Source means that the content must be made freely available and may be redistributed and modiﬁed by anyone. Every project leader and contributor owns their own contributions; however, he/she must accept that all contributions made to an OWASP Project must be open source. Project owners who own all copyrights to a project outside of OWASP, and no longer wish to be involved with the day to day management of a project, are welcome to donate their work to OWASP. Please contact the OWASP Projects Manager for information on how to best donate your project to OWASP.

Project Operational Requirements
At a minimum, all OWASP projects need to have a project name, a project leader, a project description, a project community friendly license choice, and a project roadmap. Below you will ﬁnd a short summary of what is expected for each of these operational requirements.

Project Name

A project name will include the OWASP brand name by default. A Project Leader can choose to omit the OWASP brand name from their project name, but the Leader inform the OWASP Projects Manager before it is omitted. Otherwise, the project will be set up using ‘OWASP’ as a preﬁx to the project name in the original application.

Project Leader A Project Leader is the individual who decides to lead the project throughout its lifecycle. The project leader is responsible for communicating the project’s progress to the OWASP Foundation, and he/she is ultimately responsible for the project’s deliverables. The project leader must provide OWASP with his/her real name and contact e-mail address for his/her project application to be accepted.

Project Descriptions A project description should outline 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 within 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.

Project Roadmap A project roadmap is the 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 plan. Generally speaking, projects with detailed roadmaps have tended to develop into successful projects. Some details that leaders may consider placing in the roadmap include: envisioned milestones, planned feature enhancements, essential conditions, project assumptions, development timelines, etc. It is recommended that Project Leaders have at least 4 yearly milestones in their roadmap.

Project License A project must be licensed under a community friendly or open source license. For more information on OWASP recommended licenses, please see (Appendix 8.2). While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation and operational projects, or a GNU General Public License variant for tools and code projects.

=Project Leader Expectations=

All OWASP Project Leaders are expected to act with integrity, openness, and abide by the OWASP Core Values and OWASP Code of Ethics. All Project Leaders should treat everyone within and outside the OWASP community with respect, and this includes board members and employees. Leaders should work towards collaborating in a professional manner with all involved in the face of conﬂict. Please remember we are all here to make the world a better place through software security by making it more visible to the world. The majority of the OWASP community is made up of volunteers, and we must all respect each other’s contributions and opinions even if we disagree.

Aside from the behavioral expectations OWASP has of its Leader, there are a handful of operational OWASP Project policies and guidelines that Leaders must abide by. You can ﬁnd a brief summary of each on below.

OWASP Project Spending Policy
The project spending policy has a series of guidelines aimed at assisting OWASP Project Leaders with OWASP Project spending related questions. In order to avoid any problems or misunderstandings in the future, we have developed these guidelines to provide clear expectations of how OWASP Projects should spend project funds, and what are appropriate project expenses. Please see Appendix 8.6 for a full list of the guidelines.

OWASP Grant Fund Spending Policy
OWASP has grown considerably over the past few years, and this means that our project inventory has grown as well. We currently manage over 100 open source projects under the OWASP brand umbrella. OWASP prides itself on being able to spend resources in the pursuit of potential grant funding opportunities for our projects. However, our recent successful grant proposals have added several restrictions in the way we can spend grant awarded funds as an organization. In order to avoid any problems or mis-understandings, we have developed a few guidelines to provide clear expectations of how grant awarded funds are to be managed and spent by all OWASP Projects. Please see Appendix 8.5 for a full list of the guidelines.

OWASP Project Sponsorship Operational Guidelines
The Project Sponsorship Operational Guidelines aim to inform project sponsors of what they can expect if they donate funds, or other resources, to an OWASP Project. Additionally, they outline what Project Leaders can offer sponsors in exchange for donating funds to their OWASP Project. In order to avoid future misunderstandings, we have developed these guidelines to provide clear expectations of how sponsors and projects are expected to interact when funds are given to a project for product development. Please see Appendix 8.7 for a full list of the guidelines.

=OWASP Project Lifecyle= Projects, along with Global Conferences and Local Chapters, are the cornerstone of the OWASP organization. We want to provide a fostering environment for new ideas and energetic project leaders; however, our global consumers depend on OWASP to provide dependable, quality projects. The OWASP Project Lifecycle represents a balance between keeping a very loose structure around OWASP Projects, and ensuring that OWASP consumers are not confused about a project’s maturity and quality.

Our lifecycle stages allow consumers to easily identify mature projects, and projects that are proofs of concept, experimental, and classiﬁed as prototypes in their current state. The greater the maturity of the project, the greater the level of responsibility for the project leader. These responsibilities are not trivial as OWASP provides incentives and beneﬁts for projects who take on these added responsibilities. Each of these stages is described in greater detail in the sections that follow.

The OWASP Project Lifecycle is broken down into the following stages:

OWASP Incubator Project Stage

OWASP Lab Project Stage

OWASP Flagship Project Stage

Incubator Projects
OWASP Incubator Projects represent the experimental playground where projects are still being designed, 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 gives Project Leaders the opportunity to leverage the OWASP brand name and resources while their project is still maturing. OWASP Incubator projects are given a place on the OWASP Projects Portal to leverage the organization's infrastructure, and establish their presence and project history.

Incubator Project Deliverables Leaders of Incubator Projects are expected to produce a draft or development release as a downloadable ﬁle 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, then that project can be returned to the OWASP Projects Portal as an Incubator Project.

Once a project leader has completed at least one version of a concrete deliverable, the project is eligible for graduation into the OWASP Lab stage. Note that graduation to the OWASP Lab stage is optional, and a project leader that has completed at least one concrete deliverable may continue in the OWASP Incubator stage.

Lab Projects
OWASP Lab Projects represent projects that have produced a deliverable of signiﬁcant value. Leaders of OWASP Lab projects are expected to stand behind the quality of their project as these projects should have matured to the point where they are accepted by a signiﬁcant portion of the OWASP community. While these projects are typically not production ready, the OWASP community expects that an OWASP Lab project leader is producing deliverables that are ready for mainstream usage.

OWASP Lab Projects are meant to be a collection of established projects that have gained community support and acclaim by undergoing the project review process. These reviews are part of the Incubator Graduation Process that is required to enter the OWASP Lab stage. To enter OWASP Lab, projects must be actively maintained, they must meet the OWASP Lab project standards, and they must seek to provide value to OWASP consumers.

While projects that graduate to the OWASP Lab stage can remain there indeﬁnitely, project activity is a prominently featured piece of metadata on the Projects Portal. As a result, 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 an OWASP Lab Project.

Flagship Projects
The primary goal of the OWASP Flagship Project stage is to identify, highlight, and support mainstream OWASP Projects that make up a complete software security solution. Selection of Flagship Projects is driven by the OWASP Community, and eligible projects are selected from the OWASP Lab Project pool by the Technical Project Advisory Group. 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 software 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.

Selection for OWASP Flagship designation is by invitation only. A Lab Project Leader can present their case for why they think their project deserves Flagship status. However, there is no 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 software security.

=OWASP Project Stage Benefits= The requirements laid out for the various stages of project maturity can be arduous. As 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.

Starting a Project: Incubator Stage Benefits
Aside from leveraging the OWASP brand, we can offer a number of beneﬁts to an OWASP project leader for starting a project. These include: Financial Donation Management, Resource Procurement Support, Project Review Support, WASPY Award Nominations Opportunities, OWASP Projects Track Participation, Opportunity to use Project Fund Bucket for Project Development, and Community Engagement and Promotional Opportunities.

Financial Donation Management As part of the project home page provided by the OWASP Projects Infrastructure, all projects can solicit ﬁnancial donations. While these ﬁnancial 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 unless it is pre-approved by the foundation. These funds are meant to be used towards project expenses. For a more information on our project spending policy, please view Appendix 8.6.

Resource Procurement Support Here at OWASP, we have an opportunity to work with many contractors and experts from different industries and ﬁelds. The OWASP Operations team are a hub of contacts, and we can help ﬁnd resources for Project Leaders when needed. Simply contact the OWASP Projects Manager for assistance on leveraging the OWASP network.

Project Review Support OWASP recognizes that project leaders often have difﬁculty objectively reviewing their own projects. The goal of a project review is to enable project leaders to receive constructive, objective feedback on how to improve their projects. OWASP Global Projects can retain the services of volunteer project reviewers from the OWASP community. As our reviewer pool is made up of unpaid volunteer staff, we are only able to review a project every 3 months. Please note, this service is still under development for the coming year.

WASPY Awards Nomination Project leaders have the opportunity to participate in the annual WASPY Awards. WASPY Awards are given to those projects that have provided outstanding contributions to the OWASP Community and the Software Security Industry over the year. Any OWASP project can be nominated to receive an award and have their name put into the nominee pool.

OWASP Open Source Showcase & OWASP Projects Track Participation This opportunity is open to all Open Source Projects. All Incubator project leaders and contributors are welcome to apply for the OWASP Open Source Showcase and the OWASP Projects Track event modules. These event modules are managed by the OWASP Projects Manager, and they take place at our global AppSec conferences every year.

Intra-OWASP Promotion Additional promotional opportunities are available via a number of our marketing channels, OWASP activities, and even via other projects within OWASP. For example, the OWASP Web Testing Environment (formerly the OWASP LiveCD), the Podcast series, the AppSec Tutorial Series, and Media projects all interact with 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 OWASP encourages project leaders, translation team members, chapter leaders, conference planners, and outreach leaders to consider promoting mature projects, the ﬁnal decision rests with those community members.

Opportunity to submit proposal for Project Development Funding All OWASP projects will have an opportunity to submit a proposal for funds that can be used for development of the project. There are restrictions to the use of these funds. Stipends cannot be used to pay project leaders or contributors for work done. Acceptable expenses include travel, marketing, advertising, technology, and development expenses. There is a set amount set aside from the Foundation for this award this year, and there is a proposal submission requirement before you can be awarded these funds. Please note, that Flagship and Lab projects will get a preference for funding, and funds will be awarded based on an appropriate justiﬁcation need, and on a ﬁrst come, ﬁrst serve basis.

Community Engagement and Promotional Opportunities Last but not least, project leaders get ﬁrst hand access to industry experts, and a wealth of knowledge and support from over 32,000 global OWASP members and supporters.

Benefits of Graduationg: OWASP Lab Stage
A Lab Project will continue to receive the same beneﬁts that OWASP Incubator projects receive (please see above), along with the additional beneﬁts outlined below:

Project Promotion Support OWASP recognizes that project leaders want to obtain visibility for their endeavors, and there are a number of ways that can be achieved through our Global Projects Infrastructure. As an OWASP Lab Project, Leaders get preference for promotional opportunities over Incubator Project Leaders. Projects can expect to be highlighted or “featured” for several reasons, including but not limited to:


 * New project inception


 * Recent project graduation


 * Recent release


 * High levels of contributor activity


 * Strong positive feedback responses


 * Press Coverage

If selected, projects will be highlighted through the Global Projects Portal and our social networking infrastructure as these are the primary methods we use to promote the visibility of OWASP Projects. Additionally, there is opportunity to be highlighted in our OWASP Connector Newsletter that is sent to over 43,000 subscribers.

Resource Procurement Support The OWASP Project Manager will give preference to Lab Project Leaders over Incubator Project Leaders when there is a need for resource procurement support. Simply contact the OWASP Projects Manager for assistance on leveraging the OWASP network. Please note, the project leader must be aware that all resource costs will need to come out of their individual project budget. Please ensure that your project has enough funds before spending funds or hiring a resource.

OWASP Open Source Showcase & OWASP Projects Track Travel Funding Assistance All Lab Project Leaders and contributors are encouraged to apply for the OWASP Open Source Showcase and the OWASP Projects Track event modules. These event modules are managed by the OWASP Projects Manager, and they take place at our global AppSec conferences. OWASP travel funding is available to those Project Leaders that are in need of assistance. Preference is given to Project Leaders that are traveling from the region closest the the AppSec event in question, and preference is also given to Project Leaders that have not participated in the OSS and/or Projects Track modules. Preference is also given to Lab Project Leaders over Incubator Project Leaders.

Opportunity to submit proposal for Project Development Funding All OWASP projects will have an opportunity to submit a proposal for funds that can be used for development of the project. There are restrictions to the use of these funds. Stipends cannot be used to pay project leaders or contributors for work done. Acceptable expenses include travel, marketing, advertising, technology, and development expenses. There is a set amount set aside from the Foundation for this award this year, and there is a proposal submission requirement before you can be awarded these funds. Please note, Lab Projects will be given extra consideration over Incubator Projects due to increased level of commitment. Funds will be awarded based on an appropriate justiﬁcation need, and on a ﬁrst come, ﬁrst serve basis.

Benefits of Graduation: OWASP Flagship Stage
A Flagship project will continue to receive the same beneﬁts that OWASP Lab Projects receive (please see above), along with the additional beneﬁts outlined below:

Grant and Finding and Proposal Writing OWASP will assist Flagship Projects with ﬁnding and developing a grant proposal to help fund their product development. Projects must have an active Project Leader willing to take responsibility for helping complete the proposal. Additionally, the Project Leader must be willing to take the lead on delivering the project outlined in the proposal if we are successful in securing grant funding. All projects have an opportunity to seek out and submit grant proposals via; however, Flagship Projects will get preference if assistance is required due to our limited resources.

Project Promotion Support As an OWASP Flagship Project, Leaders get preference for promotional opportunities over Incubator and Lab Project Leaders. If selected, projects will be highlighted through the Global Projects Portal and our social networking infrastructure as these are the primary methods we use to promote the visibility of OWASP Projects. Additionally, there is opportunity to be highlighted in our OWASP Connector Newsletter that is sent to over 43,000 subscribers.

Opportunity to submit proposal for Project Development Funding All OWASP projects will have an opportunity to submit a proposal for funds that can be used for development of the project. There are restrictions to the use of these funds. Stipends cannot be used to pay project leaders or contributors for work done. Acceptable expenses include travel, marketing, advertising, technology, and development expenses. There is a set amount set aside from the Foundation for this award this year, and there is a proposal submission requirement before you can be awarded these funds. Please note, Flagship Projects will be given extra consideration over Incubator and Labs projects due to their increased level of commitment. Funds will be awarded based on an appropriate justiﬁcation need, and on a ﬁrst come, ﬁrst serve basis.

=Project Reviews= OWASP recognizes the need for project consumers to quickly ascertain the maturity of a project. Project reviews are not mandatory, but they are necessary if a project leader wishes to graduate to the next level of maturity within the OWASP Global Projects Infrastructure. Projects can be reviewed when an Incubator Project wishes to graduate into the OWASP Lab designation, and project releases can be reviewed if they want the quality of their product to be vouched for by OWASP. The goal of a review is to establish a minimal baseline of project characteristics and product quality.

Project Reviewers
The Reviewer Pool is made up of a group of individuals that aim to ensure there are qualiﬁed reviewers making quality reviews of OWASP projects.The Reviewer Pool is made up of individuals hand selected by our OWASP Technical Project Advisors. These individuals have proven themselves dedicated to executing quality reviews of projects. Starting in 2014, members of the Reviewer Pool will be asked to ﬁll in their user proﬁle, which will be visible to all 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 should gain added recognition in OWASP.

Project Reviews
Project Reviews provide a way to look comprehensively at the overall maturity of a project. Additionally, there is signiﬁcant value in allowing projects to solicit general feedback to improve the quality of their projects. There are two types of reviews OWASP can provide for Project Leaders: Project Graduation Reviews and Project Feedback Reviews.

Project Graduation Reviews Project Leaders can submit an application for a project review to assess whether they can graduate to the next stage in the OWASP Project Lifecycle. These reviews are conducted in the same way the Feedback Reviews are. The only difference is that the project might be able to graduate to the next stage if their project assessment is positive.

Project Feedback Reviews Project Leaders can submit an application for a project review to assess the quality of their project, and to get general professional feedback from the OWASP Community. Reviews of this type can only be done every six (6) months due to the high number of projects in our inventory.

Projects Assessments
There are several assessments our reviewers use to determine the quality, health, and usability of a project. These assessments were developed over a 6 month period of time by our OWASP Technical Project Advisory Team. The Technical Project Advisors were recruited as volunteers to help the organization review and update the assessment criteria and project graduation process. After months of testing different assessment criteria and processes, the advisers determined that projects need to be assessed in three primary areas by both a dedicated reviewer and the community at large. Below you will ﬁnd the three assessments our reviewers use to determine the quality, health, and usability of a project. When reviewing a project, all of the assessments must be used to determine a more accurate and well rounded picture of the current state of the project.

Project Health Assessment Project health reviews are not mandatory, but they are necessary if a project wants to graduate to the next level of maturity. The Project Leader can submit an application for a project health review by submitting a request for review using the OWASP contact us form. After the application is received, the project will be assigned two (2) reviewers that will help assess the project.

The review centers around the following core concepts:


 * Project Maintenance: These questions assess whether the project leader is maintaining his project materials up-to-date.


 * Quality Expectations: These questions assess whether the project product is of value to users and software security.


 * Project Best Practices: These questions are meant to assess whether a project and its leader are following OWASP best practices.

These questions were designed to distill the core characteristics of a healthy OWASP Project, as any concern about a project’s quality can be aligned to one of the above questions. This assessment is qualitative in nature and therefore the outcome is subjective to the unit of measurement used, the reviewer. This is why reviewer selection for each project is crucial.

Project Quality Assessment The quality assessment is used to determine how good the product produced by the project is. It is meant to determine whether the product is easy to use, and whether users can ﬁnd materials to help them use the product. Moreover, this assessment is meant to determine whether the product has continued support and whether the Project Leader is maintaining the product and improving upon it regularly. This assessment is conducted by the same two (2) reviewers that conduct the Project Health Assessment. Please note, this assessment is qualitative in nature as well. Therefore, the outcome is subjective to the unit of measurement used, the reviewer.

Project Usability and Value Assessment The Project Usability and Value criteria were created during the 2013 Project Summit as a solution to the issue of properly determining product value to users. The Project Health and Quality Assessments were created before the Summit. However, during the Summit, it was determined that there needed to be some way of measuring product value to users that was separate from the assessments the reviewers conducted. Only then could we have a well rounded picture of the current state of a project. This is where this particular assessment was developed and why.

The Project Usability and Value Assessment is a survey aimed at capturing the value a product is providing to its users. It is based on the four (4) OpenSAMM business functions and twelve (12) Security Practices. The survey is to be sent out to product users, and the assessment will only be complete after at least 20 users ﬁnish the survey. After this assessment is complete, the (2) reviewers selected to assess the project will take the results, and use the feedback to complete the qualitative Project Quality and Health assessments. The aim is to have quantiﬁable metrics that demonstrate usability and value based on actual user input, and a qualitative assessment of health and quality based on expert opinion.

=Appendix= In this section, you will find examples, forms, and extra information relevant to the OWASP Projects infrastructure.

==OWASP Project History

June 2011 GPC Working Session Since the inception of the Global Projects Committee (GPC) at the 2008 OWASP Summit, our goal has been to foster an environment where OWASP Projects can grow and mature. As application security awareness rises, the knowledge and capabilities provided by OWASP Projects becomes increasingly important. To that end, we must balance the history of OWASP Projects as a loosely managed collection of random application security projects with the necessity to provide clarity and assurance to a world that has come to depend on many of these OWASP Projects.

Over the last three years, the GPC made great strides towards this goal, but virtual meetings have their limitations, and progress slowed signiﬁcantly. Following the initial 2008 Summit, the GPC met in person only once during the 2009 Mini-Summit. During this session, we met with renewed rigor and were able to take advantage of the Summit to outline an overall OWASP Project Lifecycle, along with an ambitious but achievable agenda for the remainder of the year. The argument could be made that the productivity of a week at the Summit matched or exceeded the productivity of the GPC during the entirety of the previous year. Recognizing the value of in person meetings, the GPC requested support for two in person meetings during the 2011 year as part of our overall 2011 budget, which was approved at the May 2011 Board meeting.

The GPC held the ﬁrst of these working sessions in the three days leading up to OWASP AppSec EU in Dublin, Ireland. The GPC Working Session took place from June 6th – 8th at the Trinity Capitol Hotel, separate and away from the ofﬁcial conference venue. This separation was deliberate to minimize distractions and maximize productivity of the GPC. During this session, the GPC met for over 30 hours and accomplished a variety of goals including:


 * 1) Designated the phases of the OWASP Projects Lifecycle
 * 2) Outlined vision for OWASP Enterprise Edition support
 * 3) Established processes for moving from phase to phase
 * 4) Targeted projects to pilot OWASP Flagship designation
 * 5) Drafted mapping of Flagship projects to OpenSAMM categories
 * 6) Created of Project Health Evaluation criteria
 * 7) Selected of Projects Hosting Infrastructure provider

Many of these accomplishments were uncompleted goals from the original GPC charter. The working session also resulted in several deliverable artifacts which are enclosed with these proceedings. We hope that these proceedings demonstrate the value of in person committee working sessions and provide the framework and precedent for other committees to pursue their own working sessions. For the full report, please see the GPC Full Working Session Proceedings Document.

Committee Dissolution In early 2013, the OWASP Board of Directors made the decision to do away with all of our OWASP Committees. The committee structure was completely dissolved mid 2013, which meant that the GPC would no longer be ﬁnal decision makers on OWASP Projects related matters.

Technical Project Advisors Faced with the need for experienced technical expertise for project reviews, the OWASP Projects Manager, Samantha Groves, recruited six (6) experts from different areas of the software security community. The aim was to build a grow of Technical Project Advisors that would help develop the assessment criteria and process OWASP would use to determine project health, quality and usability for the purpose of improving overall product quality throughout our projects inventory. The assessment criteria and process has been created, and we plan on implementing it thoroughly in 2014.

List of OWASP Recommended Licenses
Here you will ﬁnd a list of OWASP Recommended Licenses that you can choose from for your project. Choosing one of the licenses below is not mandatory. We only ask that you choose a community friendly license.

=Acknowledgements=