Summer Code Sprint2015

Revision as of 09:41, 20 May 2015 by Conpap (talk | contribs)

Jump to: navigation, search

OWASP Summer Code Sprint 2015


The OWASP Summer Code Sprint 2015 is a program that aims to provide incentives to students to contribute to OWASP projects. By participating in the OWASP Summer Code Sprint a student can get real life experience while contributing to an open source project. A student that successfully completes the program will receive in total $1500.

Program details

Projects that are eligible: All code/tools projects. Documentation projects are excluded.

Duration: 2 months of full-time engagement.

How it works

Any code/tool project can participate in the OWASP Summer Code Sprint. Each project will be guided by an OWASP mentor. Students are graded by their University, based on success criteria identified at the beginning of the project.

Projects are focused on developing security tools. It is required that the code any student produces for those projects will be released as Open Source.

Note on language: English is required for code comments and documentation, but not for interactions between students and advisers. Advisers who speak the same language as their students are encouraged to interact in that language.

How you can participate


Phase 1: Proposals Project leaders who want to include their project to the program should submit some initial proposal ideas on this page. These ideas serve as guidance to the students; they are things that project leaders would like to get done, like new features, improvements, etc.

Subsequently students are invited to submit detailed proposals that can (but do not necessarily have to) be based on these ideas. Students are strongly encouraged to engage with project leaders and each project's community (e.g. through the project's mailing list) in order to discuss the details of their proposal. Proposals should provide details about the implementation, time plan, milestones, etc.

Phase 2: Scoring of proposals After the submission of proposals, project leaders and contributors/mentors are required to review the submitted proposals and score them (on a 1 to 5 scale). Each proposal should receive at least 3 assessments/scores from different mentors. Each mentor, contributor or leader can score only proposals for their OWN project. All assessments should provide justification. Reviewers are strongly encouraged to provide constructive comments for students so that they can improve in the future.

Project leaders are responsible to attract a sufficient number of volunteer mentors to score proposals and subsequently supervise those that will get selected.

Phase 3: Slot allocation. When proposal scoring has been completed, each project leader requests a specific number of slots. This number should be based on: The number of truly outstanding proposals according to submitted scores. The importance of the proposal to the project's roadmap. The number of available mentors for the project. At least 2 mentors are needed for each proposal that gets accepted. If the total number of requested slots is less than or equal to the available number of slots, then all projects get the requested slots. If not, the following rules apply: All projects that have requested a slot get at least 1 slot, provided they have a high quality proposal and sufficient number of mentors. Two mentors are required per slot allocated to the project. The program's administrators get in touch with project leaders, especially those that have requested a large number of slots to receive additional feedback on the requested slots and explore any available possibilities for reducing the requested number of slots. A project leader might choose to donate one or more requested slots back to the pool so that other projects can get more slots. The program administrators can choose to initiate a public discussion between projects in need of more slots and projects that have requested a lot of slots in order to determine the best possible outcome for everyone. If all else fails, slots are equally allocated to projects, i.e. all projects get 1 slot; projects that have requested 2 or more slots get an extra slot if available; projects that have requested 3 or more slots get an extra slot if available, etc. When there are no more slots available for all projects that have requested them a draw is used to allocate the remaining slots.

In any case, the program's administrators should perform a final review of the selected proposals to ensure that they are of high quality. If concerns arise they should request additional information from project leaders.

Phase 4: Coding. This is the main phase of the program. Students implement their proposal according to the submitted timeplan and under the supervision of their mentors.


In the middle of the coding period, mentors should submit an evaluation of their students to ensure that they are on track and provide some feedback both to OWASP and the students.

If no/little progress has been made up to this point, the mentors could decide to fail the student in which case the student does not receive money. If successful, OWASP will pay half the amount ($750). The final evaluations are submitted at the end of the coding period and the second installment ($750) is paid to the student if all agreed deliverables are met. If the student has failed to demonstrate progress during the second period, then the second installment will not be paid and the student will get only half of the amount.


Mailing List


OWASP OWTF - VMS - OWTF Vulnerability Management System (FREE!)

Brief explanation:

Background problem to solve:

Expected results

You should be able to...


OWASP Mentors