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

Difference between revisions of "OWASP 2014 Project Handbook"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
= Overview =
 
= 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 =
 
= 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 flexible enough to support internationalization.
 +
 +
==Integrity==
 +
OWASP Projects must uphold the integrity of The OWASP Foundation, 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 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 modified 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 find 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 prefix 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=
 
=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 conflict. 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 find 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 Project Lifecyle=
 
=OWASP Project Lifecyle=

Revision as of 20:17, 6 January 2014

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.

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 flexible enough to support internationalization.

Integrity

OWASP Projects must uphold the integrity of The OWASP Foundation, 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 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 modified 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 find 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 prefix 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.

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 conflict. 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 find 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.