Be Foresighted: Include a full plan of action with your proposal, about one half to a full page of what you're going to do and how you think you will do it, and possibly even what you will do if your initial approach does not work.

Be Documented: Include academic references, as links or brief quotes, which back up your ideas. That kind of stuff impresses us. On the other hand, do not include 15 pages of reference materials; we won't read it. Summarize.

Be Known: If you know anyone in open source who can vouch for your code quality and/or diligence, use them as a reference.

Begin: Projects related to research already in progress at your school are good; it allows us to evaluate your approach, as well as giving us the assurance that you are serious about your topic and have already done background work.

Be Involved: Several students have already pitched their ideas to the pgsql-hackers mailing list. We like this; it shows that the student already understands how our community works, and is more likely to get their patches accepted.

Be Early: We expect to receive 50 to 100 applications for five to eight spots. Applications which we get on the first day of the application period will get more attention from the mentors, and thus more chance of being accepted, than applications which show up on the last day.

Be Specific: Your proposal should include specific, well-defined deliverables and timelines. "Fix the query planner" is bad. "I expect to take 10 weeks implementing a new n-distict algorithm for better rowcount estimation and integrating it into the PostgreSQL planner." is good.

Be Bold: suggest innovative and ambitious approaches to solve hard problems. Ultimately, we're looking for new major contributors for our projects and a bold proposal makes us think you might be a candidate. Yes, we offered up the TODO list as ideas, but stuff that we'd never thought of before got moderated up even if it didn't get accepted.

Be Realistic: SoC requires you to complete a project in 3 months or less. So don't be so bold that your proposal can't be finished. One proposal we rejected almost immediately said "As a whole, I think this idea is too large to be pulled off by one person in 3 months." We agreed.

Be Original: Many students submitted nearly-identical proposals based on recent "hot" papers on ACM and similar academic publications. For example, we got 3 separate proposals for an XML datatype using CTrees. If you do make a proposal based on a current "hot area" in CS/DBMS design, the make sure to make another unrelated proposal as well, because you'll have plenty of competitors.

PostgreSQL Summer Projects

The PostgreSQL Project is excited to take part in the Google Summer of Code 2007 program. This program endeavors to fund students to contribute to an open source project over the summer break.

Example Proposal Ideas
Possible Mentors
Proposal Guidelines
Previously Accepted Projects
Frequently Answered Questions

Example Proposal Ideas

The PostgreSQL Project has a wide range of opinions on what it feels are acceptable SoC projects. The examples listed here are meant only as a suggestion of things we would likely find useful, but you should not feel obligated to pick from this list by any means. If you have just discovered a new algorithm as part of your thesis work, we would love to see a proposal implementing that in PostgreSQL. The point is that all proposals will be evaluated on thier own merits, so be creative.

Core Source Code

TODO Items: A number of the items on our TODO list have been marked as good projects for beginners who are new to the PostgreSQL code. Items on this list have the advantage of already having general community agreement that the feature is desireable. These items should also have some general discussion available in the mailing list archives to help get you started. You can find these items on the TODO list, they will be marked with a percent sign (%).
PITR Improvements: Allow point-in-time recovery to archive partially filled write-ahead logs and automatically archiving them when pg_stop_backup() is called or the server is shutdown. Allow stand-by server to allow read-only queries to be run concurrently while replaying wal logs
ECPG Enhancments: Enable ECPG to generate calls directly for libpq rather than calls to its own libraries.
DDL Functions: Create a SQL-callable function capable of generating DDL scripts for objects within the database.

Infrastructure

Enhance Buildfarm to test external packages, patches, or performance: The PostgreSQL project maintains a public buildfarm that continuosly communicates with several machines that checkout and build the PostgreSQL source on a regular basis. The idea behind this project is to extend the current buildfarm code to allow it download external modules and report back on their build status, to download unapplied patches and test them, or to run performance tests.

External Applications

pgAdmin III / phpPgAdmin Enhancements: PostgreSQL supports a number of popular GUI Tools that are not distributed with the core project. Projects like these often have thier own TODO lists and compatability issues with the core PotgreSQL that need development.
Procedural Language Improvments: PostgreSQL provides support for more than a dozen different procedural languaes, however the level of support varies depending on the language implementation. Enhancing support of these procedual languages might include fixing build issues, adding SPI support, adding trigger support, adding support for IN/OUT parameters and more.
Replication: PostgreSQL provides a wide range of replication solutions for varying types of replication needs. Many of these projects need assistence with building against different versions of PostgreSQL, installation and setup, administrative tools, and general bugfixing.

Additional projects may be found by browsing the PostgreSQL Development Projects website.

Mentors

PostgreSQL follows an open community development model, so student projects are likely to be reviewed and commented on by any and all members of the PostgreSQL community. This also means that we may be able to find mentors for additional projects by reaching out to this community. If you are interested in working on a project not explicitly mentioned above, you may want to contact one of the Summer of Code liasons below about writing a proposal.

Andrew Dunstan (andrew @t dunslane.net), PostgreSQL Community, USA
Dave Page (dpage @t pgadmin.org), EnterpriseDB, England
Josh Berkus (josh @t agliodbs.com), Sun Microsystems, USA
Oleg Bartunov (oleg @t sai.msu.su), DeltaSoft, Russia
Robert Treat (xzilla @t users.sourceforge.net), OmniTI Inc., USA
Zdenec Kotala (zdenec.kotata @t sun.com), Sun Microsystems, Czech Republic
Mark Wong (markwm @t gmail.com), PosrgreSQL benchmarking, USA

If your project is not selected for funding by Google, but you still think you have a feasible project proposal, then please email our developers mailing list at pgsql-hackers@postgresql.org.

Proposal Guidelines

Students are responsible for writing a proposal and submitting it to Google before the application deadline. The following outline was adapted from the Perl Foundation open source proposal HOWTO. A strong proposal will include:

Benefits to the PostgreSQL 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
Project Schedule - How long will the project take? When can you begin work?
Bio - Who are you? What makes you the best person to work on this project?

Please also see our additional Advice to Students before submitting a proposal.

We would prefer that development discussion occur on our project mailing lists when possible, with special recognition being given to those students who vett thier proposal with community developers before submitting thier proposal to Google SoC. This is not required, but can have a largeimpact on the chances of your proposal being accepted, so please don't be shy. In any case, you will be required to keep open lines of communication with your mentor should you be accepted, so if you have circumstances that may effect this, please explain them up front in your proposal.

Previously Accepted Projects

Enhanced Aggregate Support
Full Disjunctions
Hashing DISTINCT Clause Implementation
ECPG Cleanup
Initial support of XMLType for PostgreSQL
phpPgAdmin improvements
xlog viewer

More information on these projects can be found on Google's PostgreSQL SoC page.

Frequently Asked Questions

Am I eligible?

Please see the Google Participant FAQ for all questions about eligibility.
When is the proposal deadline?

According to the Google Summer of Code page, the deadline for submitting student proposals is March 24th, 2007. Please remember that proposals must submitted to Google themselves (via the student application form), although we are happy to discuss any proposals with you ahead of time.

Advice to Students on Submitting SoC Applications