Developing and Managing an OWASP Project (Projects 101)

This high-level introduction is aimed at anyone thinking about launching an OWASP project. It starts with why people create projects, usually out of a love of open source, a wish to share application security knowledge, or a gap that needs tools or documentation, and notes that no security background is required. Before submitting a request, a prospective leader should gather a project name, a classification, an open source license, contact details for co-leaders, a short description and a roadmap. Descriptive names work better than acronyms or "Top 10" style labels.

The talk then covers project types, which are documentation, code and tools, and the builder, breaker and defender categories that a project can combine. Documentation projects usually use a Creative Commons license, while code and tools projects choose an approved open source license. Project pages are built on Jekyll and GitHub Pages from generated templates, and leaders must replace the placeholder text and keep the leader file in its required format. On funding, sponsorship money goes through the foundation, and leaders should get pre-approval before spending. A newer grant program lets projects request funds for specific deliverables. The speaker stressed vendor neutrality: leaders should come from more than one company, sponsors belong on a separate tab, and a project should not be used to upsell a commercial product.

Projects advance from incubator to lab to flagship, with a mature level under discussion, and a committee review decides promotions. Approved projects can use services such as code hosting, meetup tools, graphics and community translation help. A project ends either by passing leadership to another person, which is preferred, or by being archived. The talk closes with resources including the project committee, leader contacts and the community chat, and suggests that student chapters contribute to incubator projects that need help.