While projects can have mailing lists for general communication, the Global Projects Committee needs to be able to contact the project leader directly for important communications about projects. Many opportunities for promotions and support have time constraints and deadlines and we can't always support projects that "didn't see the email go by". So please make sure you provide an email that you monitor regularly. We will try our best to minimize any fluff or superfluous communications on our part.
While we are transitioning to new project infrastructure, much of the OWASP project landscape still resides on the OWASP wiki. As a result, it will be prudent to have an OWASP wiki account. If you do not have an OWASP Wiki account, you can register for one at https://www.owasp.org/index.php/Special:RequestAccount.
What is the Name of the Project
Note that OWASP Project names will automatically be prepended with the name "OWASP" so there is no need to include this in your project name. For example, the "Moonbeam Project" will become the "OWASP Moonbeam Project'. If you do NOT want the OWASP name to be included in your title, please provide your rationale in the Additional Comments field and it will be reviewed by the Global Projects Committee.
What type of project would you like to create?
Code Library Project
Which open source license will your project be using?
Apache 2.0 License (fewest restrictions, even allowing proprietary modifications and proprietary forks of your project)
Creative Commons Attribution ShareAlike 3.0 License (best for documentation projects)
GNU GPL v3 License (allows commercial use, but requires that modifications to your code stay open source, thus prohibiting proprietary forks of your project)
GNU AGPL v3 License (similar to GPL but modified for use with web applications and web interfaces)
GNU LGPL v3 License (similar to GPL but modified for use with libraries that may be called by other proprietary programs)
Modified BSD, 3-clause License (we recommend you consider Apache 2.0 instead of this licnese. It is more up-to-date and provides a little more protection from software patent lawsuits)
The core principle of OWASP is openness. As a result, all projects MUST utilize an open source license. While we do not mandate any particular license, the overwhelming majority of projects at OWASP have chosen one of the licenses below. Feel free to specify an alternate open source license of your choosing listed on http://opensource.org/licenses/index.html. If you aren't sure which license to use, here is a great article to help you decide. http://itmanagement.earthweb.com/osrc/article.php/12068_3803101_1/Bruce-Perens-How-Many-Open-Source-Licenses-Do-You-Need.htm . And finally, remember, our notes and recommendations should not be taken as legal advise.
What do you expect to be your project's tangible deliverable?
The goal of all OWASP projects is to create a concrete deliverable that furthers the OWASP mission. That deliverable is something that will be "downloaded" by project consumers and can take many forms: a PDF document, an executable binary, a printable worksheet, a DLL or JAR library, a packaged VM, an ISO file, etc. If your idea does not have a concrete downloadable deliverable, feel free to submit your idea through this form anyhow. Keep in mind though that we may suggest other more appropriate directions for your contributions. The infrastructure and resources we have available at the Global Projects Committee is geared towards supporting concrete deliverables, whereas other elements of OWASP may be better able to support your idea.
How would you describe your project in 250 characters (or less)?
This description will be used to summarize your project on the OWASP Projects Portal. This description is meant to be a very quick overview (250 character limit) of your project that let's a consumer walk away with a "sense" of your project. Short concise descriptions are easily processed and skimmed by OWASP consumers and help generate genuine interest in a project. A more thorough explanation of your project can be provided in the Additional Comments field below.
What is the roadmap for your project?
The purpose of the roadmap is to help others understand what your vision for the project is and where the project is going. It gives the community a chance to understand the context and 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.
Any additional comments or items you wish to bring to our attention.
Click here to enter text
Need assistance with this form?