Difference between revisions of "Summer of Code/Application/2008"

Jump to navigation Jump to search
m
(distribute text according to the 17 questions in the gsoc faq)
 
(19 intermediate revisions by 2 users not shown)
Line 10: Line 10:
|Applications for prior SoCs: || [[Summer_of_Code/Application/2007]]
|Applications for prior SoCs: || [[Summer_of_Code/Application/2007]]
|-
|-
|Organization administrator: || fingolfin (max AT quendi.de)
|Organization administrator: || Eugene Sandulenko (sev.mail AT gmail.com)
|-
|-
|Backup administrator: || sev (sev.mail AT gmail.com)
|Backup administrator: || Max Horn (max AT quendi.de)
|-
|-
|Project License: || GPL
|Project License: || GPL
Line 26: Line 26:
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com
* [[User:LordHoto|Johannes Schickel]], Google Account: lordhoto AT gmail.com
|}
|}


= Application organized according to program FAQ =
= Application organized according to program FAQ =
=== Describe your organization. ===
=== Describe your organization. ===
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works by either 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.
ScummVM is a collection of Virtual Machines which allow a variety of commercially available graphical point-and-click adventure games to run on modern hardware, often with improved features. 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 of each supported game engine in a structured fashion using the C++ language. 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 works on popular game consoles (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).
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 works on popular game consoles (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's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories:
ScummVM has a highly productive team of about 35 currently active developers (out of an all-time pool of over 60), who work together on a codebase almost 650,000 lines of code. In addition we have 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.
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,
# Engines, also called front ends internally, contain the actual game specific (VM) code, and
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.


The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:
=== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating? ===
* Porters: Responsible for a specific ScummVM port.
Drawing from our pleasant experience during our participation in GSoC '07 we feel compelled to apply again this year. Our goals for the gains to be attained through GSoC remain almost the same.
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.
* Documentation / web site management
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.


All of this enables us to be highly productive in a team of about 35 currently active developers (out of an all-time pool of over 60), who work together on a codebase almost 650,000 lines of code. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~10 million project web hits per month.
Firstly, we hope to gain some new active developers. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.


Furthermore, we have a list of self-contained tasks on specific aspects of ScummVM which have not been tackled yet. These tasks will improve the functionality of ScummVM, making them valuable to the ScummVM community. GSoC is a very good opportunity to have these implemented through the incentives the program offers. These tasks also present a good point of entry for new developers to ease themselves in the extensive ScummVM codebase.


=== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating? ===
=== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ===
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.
 
Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC.
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.


Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects, and so forth: knowledge that may turn out to be very valuable outside of the SoC, too.
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.


===  Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ===
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.
<FIXME>
 


===  If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? ===
===  If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? ===
<FIXME>
N/A
 


===  Who will your organization administrator be? Please include Google Account information. ===
===  Who will your organization administrator be? Please include Google Account information. ===
<FIXME>


Eugene Sandulenko (sev.mail AT gmail.com)


===  What license(s) does your project use? ===
===  What license(s) does your project use? ===
<FIXME>


GPLv2 with some parts dual-licensed under LGPL as well


===  What is the URL for your ideas page? ===
===  What is the URL for your ideas page? ===
<FIXME>
[[OpenTasks|http://wiki.scummvm.org/index.php/OpenTasks]]




===  What is the main development mailing list or forum for your organization? ===
===  What is the main development mailing list or forum for your organization? ===
<FIXME>
scummvm-devel AT sourceforge.net




===  What is the main IRC channel for your organization? ===
===  What is the main IRC channel for your organization? ===
<FIXME>
<nowiki>#scummvm at freenode.net</nowiki>
 


===  Does your organization have an application template you would like to see students use? If so, please provide it now. ===
===  Does your organization have an application template you would like to see students use? If so, please provide it now. ===
Line 106: Line 93:


===  Who will be your backup organization administrator? Please include Google Account information. ===
===  Who will be your backup organization administrator? Please include Google Account information. ===
<FIXME>
Max Horn. Google Account: max AT quendi.de
 
===  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


===  Who will your mentors be? Please include Google Account information. ===
Eugene Sandulenko, Google Account: sev.mail AT gmail.com
<FIXME>


Johannes Schickel, Google Account: lordhoto AT gmail.com


===  What criteria did you use to select these individuals as mentors? Please be as specific as possible. ===
===  What criteria did you use to select these individuals as mentors? Please be as specific as possible. ===
Line 119: Line 110:
===  What is your plan for dealing with disappearing students? ===
===  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.
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.
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. 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).  
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.


A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.  
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.
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? ===
===  What is your plan for dealing with disappearing mentors? ===
Line 137: Line 127:


===  What will you do to ensure that your accepted students stick with the project after GSoC concludes? ===
===  What will you do to ensure that your accepted students stick with the project after GSoC concludes? ===
<FIXME>
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 :-)

Navigation menu