Google's Summer of Code 2008

Django is a sponsoring organization for the 2008 Google Summer of Code. (Read Google's page for more information on how the program works.) Django's SoC program is being run by Mark Choate (mark /at/ choategroup /dot/ com).


If you're interesting in mentoring -- supervising a student in work on Django-related activities -- add your name and email here, or email Mark:

  • Russell Keith-Magee (russell@…)
  • Ben Slavin (benjamin.slavin@…)
  • Jannis Leidel (jannis@…)
  • Joseph Kocherhans (jkocherhans@…)
  • Brian Rosner (brosner@…)
  • Justin Fiore (justin.fiore ... s/ ... /@/)


Student applications open March 24 and end on March 31; sign up over at Google and be sure to list Django as the project you want to work with.

If you'd like to get started on your proposal early, we'll be looking for a few things. You'll need to have a concrete task in mind (some ideas are below) along with a solid idea of what will constitute "success" (you tell us). We'll want to know a bit about you -- links to previous work are great, if any. You'll also need to provide us with a rough schedule of milestones so your mentor can know if and when to nag you :)

Note that none of the ideas below are good enough to be submissions in their own right (so don't copy and paste)! We'll want to know not just what you want to do but how you plan to pull it off.

And don't feel limited to the ideas below -- if you've got a cool project you want to work on, we'll probably be able to find you a mentor. We plan on approving as many projects as we possibly can.

Note: we're looking for projects that add value to Django itself - not application/CMS projects that use Django.


The django-gsoc Google Group has been setup to facilitate communication between students and mentors in the GSoC efforts.


Here are some suggestions for projects students may want to propose (lazyweb: please add to this list!). This isn't by any means the be-all and end-all of ideas; please feel free to submit proposals for things not on this list.

Try to scope ideas/proposals to the 4-month timeline -- simply proposing to fix a ticket or two will probably result in your proposal being rejected in favor of a more ambitious one. The SOC does not cover activities other than coding, so certain ideas ("Write a more detailed tutorial" or "Create demonstration screencasts" or "Add a pony?") are not suitable for inclusion here.

You should also try to avoid projects that are on the Django 'critical path' -- that is, projects that the Django core developers are working on as a priority for the v1.0 release. As much as we would like help working on newforms-admin or queryset-refactor, these projects aren't really good topics for GSOC projects. Of course, it also makes sense to avoid any project that would be seriously affected by the anticipated changes to the trunk -- for example, proposing a big change to trunk admin views would not be wise.

On the other side, though, be sure to be concrete in your proposal. We'll want to know what your goals are, and how you plan to accomplish them.

In no particular order:

  • Work on a database backend for some database not yet supported by Django -- MSSQL, Firebird, DB2, etc. In most of these cases work has already begun (django-firebird, django-mssql), so this project would involve a fair amount of interaction with an existing development team. Along the way you'd need to fix any bugs in Django itself that prevent use with said backend.
  • Improve static page support in the built-in webserver. Make it useful for testing sites that may include CSS.
  • Template language improvements including:
    • Namespaces for templates (fixing the template parser, filter expressions and load tag to use namespaces)
    • Generic Overlays for the Template DOM and/or Overlays for block tag
    • ... etc

For the following two, see

  • Add support for xapian, sphinx, pylucene, hyperestraier, grassy knoll or other search engines to djangosearch.
    • Search functionality should perhaps support db engine full text search facilities as well. Indexer is overkill for smaller things like e.g. djangosnippets, it should be easy to get going with db-based backend and later migrate to a real indexer only by modifying settings to activate a different backend --- mrts
  • Implement object history. See and . Audit Log, Temporal Object and Temporal Property patterns should be implemented and it should be possible to activate any combination of these. And there needs to be an intuitive way to access the snapshots.
Last modified 16 years ago Last modified on 04/10/08 15:12:26
Back to Top