For those not subscribed to the GSOC mailing list: How does google allocate the slots for organizations? Our first cut at student allocations starts based on an organization's popularity. E.g., if an organization receives 20% of the total applications for the program, then they'll receive ~20% of the student slots for the program. However, we always cap the number of applications an organization will receive at the total of their requested number of projects, since we don't want to assign an organization more students than they can support. Additional students beyond an organization's requested cap are reallocated among other organizations, again based on popularity. Regardless of an organization's popularity, we allocated a minimum of two students per project in 2007, though some projects ended up with only one, either by request or due to lack of assigned mentors. Once we have this base sorting done, we begin manual tweaking. We do manual tweaking based on several factors, including but not limited to: 1) Successful track record with the program, meaning most of your students passed their final evaluations. If we know that you'll deliver, chances are we'll bump up your allocation towards your requested maximum. 2) Organizations that produce committers get more students. It's important to us that students finish their GSoC projects, but it's more important to us that you folks get long-term contributors. If we heard from you that your students are still engaged and, better yet, are now full developers or committers, chances are we bumped up your allocation accordingly. 3) Umbrella organizations get more students. If an organization is acting as an umbrella for other projects, e.g. the Python Software Foundation for 2007, chances are we'll allocate more students to you simply because there's a great deal of different types of work to be done, and we're hoping our students will end up with something that appeals to them among this wide offering. 4) Mailing list and IRC participation. Are you answering student questions non-stop on IRC or providing helpful advice on the mailing lists? If you are, that shows us that you're committed to the success of the program and that you're already highly engaged. Chances are that we'll bump up your allocations if we can. 5) Failure to complete your organization profile. If you didn't take the time to let us know how many students you're looking for, chances are we gave you the minimum, no matter how many you could reasonably support. Desired number of projects is critical data for us, and if you don't provide us with at least an estimate we'll estimate for you. Usually at low numbers. 6) Issues from previous years. This point refers specifically to larger, well-established organizations that we know we want to keep inviting back due to the volume of their contributions to open source. If you required more support than everyone else - and not in the "hey, this isn't documented, what do I do?" way - or more than one or two your students evaporated, chances are we dialed you back a bit. Each time we adjust the allocation for one organization, the remaining student pool is reallocated amongst the other organizations, based once again on popularity. This next reranking can adjust an organizations slot allocations by +2 to -2 or so, but doesn't vary much more widely than that. Once we're satisfied with our initial allocations, we publish them to the organizations so you folks can assign mentors to the best N of your applications. From there, we do more twibbling based on duplicate acceptances (usually, the organization losing the student gets the next one down on the list, but if there's no mentor assigned that a -1 on slot allocations) and on whether or not mentors are assigned (no mentor assigned in the final stages before final announcement means that your organization loses allocated slots).