Summer of Code/Application/2009
Introduction & overview
This is the application of the ScummVM project for the Google Summer of Code. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.
| Project: | ScummVM |
| Participation in prior SoCs: | Yes |
| Applications for prior SoCs: | Summer_of_Code/Application/2008, Summer_of_Code/Application/2007 |
| Organization administrator: | Eugene Sandulenko (sev.mail AT gmail.com) |
| Backup administrator: | DrMcCoy (gmail addr)? |
| Project License: | GPL |
| Ideas page: | OpenTasks |
| IRC channel: | #scummvm on irc.freenode.net |
| Development mailing list: | https://lists.sourceforge.net/lists/listinfo/scummvm-devel |
| Mentors: |
|
Please address all items in RED ;-)
Application organized according to program FAQ
Describe your organization.
ScummVM is a collection of Virtual Machines for playing classic graphical point-and-click adventure games on modern hardware. Supported games include favorites such as Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, the Virtual Machines (called Engines) are complete reimplementations in C++ of the engines used in the original games. The development team works either by reverse engineering game executables (usually with the permission of creators of the game), or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X and most Unix variants (Linux, *BSD, Solaris), ScummVM also runs on popular game consoles (Wii, Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS, iPhone or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).
ScummVM has a highly productive team of about 35 currently active developers (out of an all-time pool of over 60), working together on a codebase almost 650,000 lines of code. In addition ScummVM has many non-developer contributors, and a huge and highly active community. ScummVM is among the top ranking projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~10 million project web hits per month.
Why is your organization applying to participate in GSoC 2009? What do you hope to gain by participating?
Yes! We like GSoC too much! We love it! We wait eagerly each year for GSoC to start!
What we hope to gain is valuable code contributions. In the past, we've had students take up and complete tasks which had been marked as "to-do", but the main developers were at a loss of time to implement them. The students have taken these up as self-contained GSoC projects and realized them. But also, some students have come up with new functionality, proposed and finally implemented it. These have been our favorite.
In addition, we hope to gain new developers in the project. We hope that after their projects, students will stick around and improve them or work on other interesting tasks. We hope that GSoC brings the students in touch with open source and in our case bring them in touch with game developing. We hope these students will add their piece of code in this project and will keep on contributing afterwards.
+++
Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.
Somebody with a stronger memory plz update these facts. We'll fix the text later
We have participated in the GSoC program last year, in 2007. We had an exciting time during the prep period, had some very good students and some very bad students during the main stretch, and we got some significant results in the end.
We had 7 students and 4 mentors in total. Two of our students have been promoted to active, regular developers in the team after having their respective code contributions integrated in the codebase. One other student's code contributions have also been integrated in the mainline. Two more have their code still in development to improve it and make it production-ready, either through optimization or extension and better integration. Two students failed to keep up with the schedule and/or produced inadequate code.
Ultimately, aside the valuable contributions the majority of our students achieved, two students failed. In their case, our mentors agree that there wasn't anything more we could do. Their involvement was minimal from the start and that's what we must identify early on, at the application stage.
If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?
N/A
What license(s) does your project use?
GPLv2 with some parts dual-licensed under LGPL as well
What is the URL for your ideas page?
http://wiki.scummvm.org/index.php/OpenTasks
What is the main development mailing list or forum for your organization?
scummvm-devel AT sourceforge.net
What is the main IRC channel for your organization?
#scummvm at freenode.net
Does your organization have an application template you would like to see students use? If so, please provide it now.
The following was adapted from the FreeBSD Proposal Guidelines.
- Name
- Project Title
- Possible Mentor (optional)
- Benefits to the ScummVM Community - a good project will not just be fun to work on, but also generally useful to others.
- Deliverables - It is very important to list quantifiable results here e.g.
- "Improve X modules in ways Y and Z."
- "Write 3 new man pages for the new interfaces."
- "Improve test coverage by writing X more unit/regression tests."
- "Improve performance in FOO by X%."
- Project Schedule - How long will the project take? When can you begin work?
- Availability - How many hours per week can you spend working on this? What other obligations do you have this summer?
- Bio - Who are you? What makes you the best person to work on this project?
Who will be your backup organization administrator? Please include Google Account information.
Sven Hesse, Google Account: ??? AT gmail.com
Who will your mentors be? Please include Google Account information.
Max Horn, Google Account: max AT quendi.de
Kostas Nakos, Google Account: knakos AT gmail.com
Eugene Sandulenko, Google Account: sev.mail AT gmail.com
Johannes Schickel, Google Account: lordhoto AT gmail.com
Sven Hesse, Google Account: ??? AT gmail.com
John Willis, Google Account: ??? AT gmail.com
What criteria did you use to select these individuals as mentors? Please be as specific as possible.
The mentors have all been contributors to ScummVM for a long time. They feel comfortable around the ScummVM code and can guide students to perform their tasks. The majority of the mentors have also participated in past ScummVM GSoCs so they know their way around the procedures and have also refined their mentoring style. Some of them are/have been part of the academia, guiding real students. We are drawing the best available from our pool of developers to mentor GSoC students this year.
What is your plan for dealing with disappearing students?
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too. Our plan this year is to use the application phase of the progam more efficiently. Ideally we would like to take up only students that are intimately interested to the project, have fresh ideas, propose a good looking timetable and are keen to execute it. That means more clarifying questions using the GSoC app, and setting up meetings with prospective students.
During the project, we are also planning to impose a more strict "activity update report" schedule. The students should report at least once a week. Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.
What is your plan for dealing with disappearing mentors?
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.
What steps will you take to encourage students to interact with your project's community before, during and after the program?
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to encourage them to work together.
What will you do to ensure that your accepted students stick with the project after GSoC concludes?
Our experiences last year show that guys who are genuinely interested in the project will stick around. And that's really the drive for open source: to be interested in the project one is participating. We will try to select students who best match this criterion. Other than that, we run a cool team with loose coding deadlines and a cheerful IRC channel and mailing list, so prospective team members should feel at home soon. We always welcome new contributions with pleasure. Spending some time before someone gets promoted to normal team membership is how we've always done it; GSoC gives us the chance to implement this again, with added benefits too :-)