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

Category:OWASP Project

From OWASP
Jump to: navigation, search




OWASP Project Header.jpg

So you want to start a project...

Starting an OWASP project is quite easy, and your desire to contribute and make it happen is essential.

HowToStartProjectoWasp.png

Here are some of the guidelines for running a successful OWASP project:

-Start exploring the actual OWASP projects Inventory. Many projects handle specific areas of security it is a good idea to start looking how other successful projects do this (LABS/Flagship)

-Place your idea or project on the Project Ideas Board. This phase will help you to define the project goals and also explore and exchange with other OWASP leaders and volunteers how to develop the idea into a tangible project

-Explore and research if your idea covers a unique segment in the Security arena. Think of your project as a product, if you really want people using it, think how this project will cover a necessity in the security area you are working on

-Define what kind of project you would like to start. Is it a code, tool or documentation?

-Communicate through the Project leader mailing list about your idea and get feedback and meet potential contributors

-Develop your project based on the type of project. For example if you are willing to start a documentation project, begin by defining a Table of Content and work it through with potential contributors. First of all begin by creating a Road-map for your project. This is essential to submit your project. We highly recommend to read documentation such as "How to start /run a successful Open Source Projects".

RoadmapIncubatorProjectExample2.PNG

Some recommendations on how to start a documentation project Document Guide Project

Importance of a well thought out Road-map

Many Incubator project leaders struggle with creating a realistic planning, which should be based on their available resources and time. A well thought out plan makes a difference between a procrastinating project and a successful one. The important aspect of this is, that the project leader is able to create a plan based on his situation. The following is an example of a Roadmap, which has focused to produce a Documentation first release in a year and a basic outline how they plan to cover 4 essential aspects which are Research & Development, Marketing, Planning and Goals.


"Your [project] roadmap should tell a coherent story about the likely growth of your product. Each release should build on the previous one and move you closer towards your vision. Your roadmap should be convincing and realistic: Don’t speculate or oversell your [project]. Be clear who your audience is: An internal roadmap talks to development, marketing, sales, service, and the other groups involved in making your [project] a success; and external one talks to existing and prospective customers." Extracted from : "[10 Tips for Creating an Agile Product Roadmap]"

  • Start defining a development, documentation and marketing plan for your project. Set short , medium and long term plans. Include promotion of your project, this is very important in order to engage users and consumers of your project. You can run a single person project, but it's usually best to get the community involved. You should be prepared to support a mailing list, build a team, speak at conferences, and promote your project.
  • You can contribute existing documents or tools to OWASP! Assuming you have the intellectual property rights to a work, you can open it to the world as an OWASP Project. Please coordinate this with OWASP by Contacting Us.
  • Available Grants to consider if you need funding - Click Here
  • You should promote your project through the OWASP channels as well as by outside means. Get people to blog about it!

Creating a New Project

Once you have passed the Project Ideas phase, then you will be ready to start a new project

Please submit a new project application here.'

2016 OWASP Project Process

Step 1: New Project Leader submits New Project Request Form it is logged in the system and an alert is sent to the Project Coordinator

Step 2: New Project Request is received and reviewed by Project Coordinator for complete information .It must contain the following information to qualify as an acceptable submission: You will need to gather the following information together for your application:

  • Project Name,
  • Project purpose / overview,
  • Project Roadmap,
  • Project links (if any) to external sites,
  • [[Guidelines_for_OWASP_Projects#Project_Licensing|Project License],]
  • Project Leader name,
  • Project Leader email address,
  • Project Leader wiki account - the username (you'll need this to edit the wiki),
  • Project Contributor(s) (if any) - name email and wiki account (if any),
  • Project Main Links (if any).
  • ==>For Documentation: A table of Contents
  • ==>For Code: A prototype hosted in an open source repository of your choice.

Step 3: If all information is completed following the minimum criteria for Projects (Code/Tool/documentation), The Project Coordinator notifies the Project Leader that the request has been accepted, and at the same time notifies the Review team that a new project has been submitted, including all the information requested in the project criteria

Step 4: Project Coordinator proceeds to create a new Wiki page for the project including all the information sent by the project leader. project coordinator uses one of these project wiki template:

Also Project coordinator creates a mailing list for the project leader and sets him as admin

Step 5: Project Coordinator notifies project leader and Review team about the created wiki page, providing the link to the wiki page.

  • Review team might provide comments for further improvement of the wiki page if necessary
  • Project leader should request a wiki account to be able to update his own wiki page afterwards if he has not one yet

Step 6: Project coordinator updates the Wiki project inventory, Dashboard and open hub with the information regarding the new created project

Step 7: Project is set in the agenda by the Project Coordinator for monitoring over the next 3 months to check how has been developing.

Step 8: Every 3 months, project coordinator monitors the activity on the wiki page for new updates and on the Openhub for commits and level of activity . Findings are then reported on the Dashboard as comments and CC through email to the review team

Step 9: if the project has not been updated and has no activities after six months of creation, project coordinator sends an email to the project leader requesting an update and status to see how has been developing, CC: project review team regarding the lack of activity .Findings are then updated on the dashboard.

Step 10: Over the next 6 months the project is monitored again for activity. If no updates have occurred since its inception after 12 months, project is then set as inactive and project leader and review team is notified about the status. Project coordinators updates :

  • Wiki page of the project is labeled as 'inactive' (inactive banner)
  • The Project is set under the 'inactive category'
  • Dashboard is updated with comments and set as inactive

Reference Material

Openhub

Dashboard

Project Review Guidelines

GITHUB OWASP

Projects Slides

OWASP Recommended Licenses

Why are you recommending these licenses?
Which other open source licenses are eligible for an OWASP project?

Choosing a license under which an artifact is distributed and enforcing the license are prerogatives of the copyright holders over that artifact. By default, each contributor is copyright holder over the contributed piece. Contributors must all agree on the license and cooperate in enforcing it or must assign their copyright to the entity which becomes responsible for choosing and enforcing the license.

OWASP is a collaborative initiative for the public good and most of its output is expected to be functional, rather than aesthetic. The problem OWASP tackles is so large that OWASP acknowledges a need to collaborate with the commercial world. Therefore, in order to become an OWASP Sponsored Project, you should be comfortable with:

  • Allowing arbitrary uses for your work, for example for commercial purposes. (If you disagree, consider using CC-BY-NC.)
  • Revealing to the world your project's source code (its form preferred for modification).
  • Allowing your work, under certain conditions (see below), to be modified by others and redistributed. (If you disagree, consider using CC-BY-ND.)
How to choose a license for artifcts of your OWASP project
Artifact Under what conditions can your work be modified and redistributed?
As long as modifications are licensed in the same spirit If credit is appropriately given to you Under any circumstances
Standalone Tool Run locally
GPL (newest version as of 2016 is 3.0)

The "General Public License" protects users' four essential freedoms, among other things by requiring someone who distributes software derived from yours to also publish the source code for the modifications. Anyone can charge money for distributing copies of the software, but cannot prevent its recipients from redistributing it for free. The GPL allows the copyright holders to distribute the software under additional licenses, too, which can be a way to make it proprietary-friendly.
Apache License (newest version as of 2016 is 2.0)

Has the fewest restrictions, even allowing proprietary modifications and proprietary forks of your project, and is more up-to-date than the BSD license.
CC0 (newest version as of 2016 is 1.0)

The "Public Domain Dedication" means that anybody can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
Consumed over the network
AGPL (newest version as of 2016 is 3.0)

The "Affero General Public License" extends the GPL to SaaS: users of the modified software must be able to obtain the source code of the modifications.
Library
GPL or LGPL (newest version as of 2016 is 3.0)

The "Lesser General Public License" relaxes the GPL for libraries: if the library is not modified, just integrated (function calls, global variables,...), with other software, it does not require the source code of the other software to be published. The Free Software Foundation recommends the LGPL only for libraries which have established competitors for the same functionality, otherwise they recommend the full GPL.
Document (includes E-Learning, presentations, books etc.)
CC-BY-SA (newest version as of 2016 is 4.0)

The "Creative Commons Attribution-ShareAlike" is like the GPL, but for documents.
CC-BY (newest version as of 2016 is 4.0)

The "Creative Commons Attribution" is like the Apache License, but for documents.

Funding your Project

An OWASP project does not receive any funding for development at project inception; however, a new project does have the opportunity to submit a request to receive funds if they are available for the year. Additionally, project leaders have the option of seeking sponsorship from outside organizations, but project leaders are required to seek funding through their own initiative.

Project Release

As your project reaches a point that you'd like OWASP to assist in its promotion, the will need the following information to help spread the word about your project:

  1. Short 5 sentence paragraph outlining what your project is about, what you hope to accomplish with your project, what value your project brings to software security, and contributor and project leader names and contact information.
  2. Link to your wiki page.
  3. Link to your code repository or a link to where readers can download your project.
  4. Latest Release description answering the following questions: What is it?, What does it do?, Where can I get it?, Who should I contact if something goes wrong?.

Project Process Forms

These forms were created to help project leaders, and those interested in a going through a process in the OWASP projects infrastructure. They facilitate the management of each query based on the specific task an applicant will need help with. The forms are described below, and they are linked with their designated online application form.

  • Project Transition Application:The OWASP project transition form gives current project leaders an easy way of handing over project administration information to individuals wishing to take over a project.
  • Project Review Application:This form is for current project leaders to request a review of their project based on OWASP graduation criteria. The aim is to designate an OWASP volunteer to review these projects within 3 months time.
  • Project Donation Application:This form is for projects outside of the OWASP project infrastructure. Project Leaders for these open source projects can choose to partner or give their project to OWASP directly through this form.
  • Project Abandonment Request:The OWASP project abandonment form gives current project leaders an easy way of letting the OWASP Foundation know that they wish to resign their project leader duties. This form should be used when no replacement project leader exists to take over these duties.

Subcategories

This category has the following 132 subcategories, out of 132 total.

A

B

C

D

E

F

G

H

I

J

L

M

N

O

P

R

S

T

V

W

X

Y

Pages in category "OWASP Project"

The following 200 pages are in this category, out of 419 total.

(previous page) (next page)

 

A

B

C

D

E

F

G

H

I

J

K

M

O

(previous page) (next page)
Retrieved from "https://wiki.owasp.org/index.php?title=Category:OWASP_Project&oldid=254864#Starting_a_New_Project"