Guidelines for OWASP Projects

Revision as of 16:50, 30 March 2009 by Mtesauro (talk | contribs) (Project Wiki Pages: added a bit about help with wiki text - linked to mediawiki cheat sheet)

Jump to: navigation, search
This is a DRAFT page still under review by the Global Projects Committee

This page is maintained by the Global Projects Committee to help assist Project Leaders with information about successfully running an OWASP Project. It will be updated from time to time, and changes will be discussed and announced on the OWASP-Leaders list.

Project Wiki Pages

  • When a new project is started, we will create a wiki page as the official homepage for your project. It will contain the [[Category:OWASP Project]] tag at the bottom. Please ensure this tag stays on your project homepage.
  • Project wiki pages will also be listed in the appropriate category on the OWASP Projects page, which means that, initially, until being assessed, it will be placed alphabetically within the ‘Alpha Status Projects’ category. Exceptions can be made for special circumstances (e.g. pre-established project being brought into OWASP), so contact the OWASP Global Projects Committee for more information.
  • We'll start your project homepage with a Project Identification template to capture the relevant meta-data that you already provided about your project. For example, the Live CD Project page contains the source code {{:Project Information:template Live CD 2008 Project}} and the template is automatically embedded on the project page.
  • You may move your Project Identification template anywhere you'd like (top/bottom of the page, to a separate tab, etc.) but please ensure it stays linked from your project's page. If you really would like it to be out of the way, you can just edit the Project Identification page and tag it with your project's category label, such as [[Category:OWASP Enterprise Security API]], and then no link on your project's homepage is required.
  • Your project homepage belongs to your project and you are free to design it as you like (some good examples of different styles include the ESAPI Project page and the Live CD Project page). It's usually a good idea to include information about your project including detailed descriptions, screenshots, download links, a link to the project mailing list, contact information for the project leader, and any other relevant information.
  • You can have as many wiki pages as you want to support your project. Please feel free to create them yourself. Everything posted on the wiki is accessible by many people around the world.
  • If you have never edited a wiki, take a quick look at the this cheat sheet for basic editing help. Also, OpenOffice is a free office suite which includes the ability to export to MediaWiki text. The exported text file contents can be copied and pasted into OWASP's wiki.

Project Sponsorship

Many OWASP projects are made more successful through contributions from sponsor organizations that donate money or man-power. But, managing sponsorship attribution over time can become tricky, so here are some general guidelines for project leaders based on common cases:

  • In cases where sponsors contribute materials governed by an open-source license that requires attribution, Project Leaders should ensure that attribution is done accordingly. In such instances, it may also be necessary to attribute individual contributors.
  • For financial contributions to a project (e.g. an outside organization donating through OWASP Season of Code sponsorship), sponsors should be attributed for at least 1 year. After that, Project Leaders are free to leave or remove the sponsorship attribution.
  • Sponsors can be attributed by name or through display of their logo. This can appear on the project homepage or built in to the document/tool itself. This is the choice of the Project Leader.

Project Licensing

For OWASP projects, the materials are available under an approved FLOSS (Free, Libre and Open Source Software) license. For more information, please see the OWASP Licenses page. Some other items to consider when choosing a license:

  • For tools and other coding projects, an approved FLOSS license is recommend as these were designed for software creation. Examples of FLOSS licenses for coding projects are:

When choosing a software license, the primary difference between licenses deals with the restrictions and permissions enforced by the license. The restrictions and permissions enforced by the chosen license can have impacts on business adoption and contributions by the community at large. Consideration should be given to existing and well established licenses as these are much better understood by the IT and business community in general. For more assistance on selecting a license, here are some general references: