Google Summer of Code Student Project Wins Statistical Software Award

We are happy to report that one of the Google Summer of Code students from last year, Ian Fellows, has been awarded the John M. Chambers Statistical Software Award for his work with the R Project. This award will be presented at the annual Joint Statistical Meeting in August.

Ian’s project involved extending the scope of the Deducer cross-platform GUI interface to R by adding an intuitive plot builder for building up complex statistical graphics in a user friendly environment. Ian has described the plot builder as “a piece of software that simply wouldn't have been built except for the funding from Google.” In addition to the online documentation, Ian has put together a series of video tutorials on YouTube introducing the new software:

Deducer Video - Part 1

Console Video - Part 2

We’re also happy to report that once again Ian will be participating in the Google Summer of Code, this year as a mentor with the R Project.

I personally use ggplot2 frequently for visualizing complex data sets at Google, and I’m looking forward to utilizing the new GUI PlotBuilder for my work. Congratulations again, Ian.

By Murray Stokely, Software Engineering Team

Google Summer of Code Meetup in Belgium

On the 6th of April, Google Summer of Code veterans Vincent Verhoeven (student for both KDE and Thousand Parsec) and Bram Luyten (mentor for DSpace) gave a presentation about the Google Summer of Code 2011 program to an audience of interested students.

The Google Summer of Code schedule is quite challenging for Belgian students because of the large overlaps between the program and their examinations. However, the presenters made it clear that with careful planning in the application and transparent communication with mentors, successful participation is definitely possible. As an added bonus, if students are accepted in the Google Summer of Code program their participation can be counted as an internship for some of the master's programs at K.U. Leuven.

The presenters were struck by the fact that of the 30+ attendees, none of them had any experience contributing to open source projects. Each of the students used open source software on a daily basis (Firefox, Linux, etc.) so it seemed like a natural progression for this generation of developers to start contributing to the open source community and Google Summer of Code is a great way for that introduction.

Vincent's testimonial made it clear that participating in the Google Summer of Code can be just the start of a series of interesting experiences. Following up on his participation in the Google Summer of Code, Vincent and his buddies from the Thousand Parsac held a codesprint together at the GooglePlex. It's more than bits & bytes alone, it's about building relationships and friendships that last far beyond the span of one summer.

By Bram Luyten, past GSoC mentor for DSpace and Head of Sales and Marketing, @Mire

Students announced for 2011 Google Summer of Code

We have announced the 1,116 students that will be participating in this year’s Google Summer of Code program. Students will now start the community bonding period where they will get to know their mentors and prepare for the program by reading documentation, hanging out in the IRC channel and familiarizing themselves with their new community before beginning their actual coding at the end of May.

If you are interested in learning more about the 175 organizations that the students will be working with during the 2011 Google Summer of Code or important dates, please visit the program website.

Congratulations to our accepted students! We look forward to an exciting and productive summer of coding.

By Stephanie Taylor, Open Source Programs Office

The DOs and DON’Ts of Google Summer of Code: Mentor Edition

This is the final post in a series of three posts on the DOs and DON’Ts for Google Summer of Code students, mentors, and organization administrators. This post deals with mentors; the first post dealt with students and the second post with organization administrators.

The role of a mentor is to monitor the progress of each accepted student and to mentor them as the project progresses. Based on our experience with Google Summer of Code, we’d like to share these tips and antipatterns with you to raise awareness and help mentors avoid the same mistakes that have been made by many others. For even more advice, check out the mentor/admin guide.

DO	DON’T
Be an active member of the community you are mentoring for. One of your goals should be to integrate your student in the project community. You can do this best if you are a part of it yourself. Introduce the student to the people in your community and your communication media. Also familiarize the student with the rules and norms that your community abides by and that they might not be aware of yet. Apply as a mentor only after interacting with the community.	Apply as a mentor to organizations where you don’t contribute. Every year, a surprising number of people request to become mentors for nearly every organization in Google Summer of Code simultaneously. In general, this is treated as spam and you will be blacklisted for doing it. One of the goals of Google Summer of Code is to introduce the student to the community. You may be an expert in the code, but the goal is to integrate code and transform students into long-term contributors; if you don’t know the community, both of these are much harder.
Focus on one student. New mentors should concentrate on doing an amazing job mentoring one student instead of spreading themselves too thinly. Even experienced mentors should take caution when thinking about mentoring two projects—it’s not unusual for both projects to be mentoring-intensive. If that happens, you may not have the time to do your students justice, and it’s unfair to fail students because of your own difficulties. This is one reason backup mentors are critical.	Take on too many students. Mentoring more than one student in your first year is a recipe for failure. Even if it’s your second year, this advice still stands, as the amount of time needed to mentor a student varies wildly between students, projects, ideas, etc. People mentor multiple students successfully each year, but many people fail at it every year too. If you have experience and still want to mentor two or more students, plan to set aside time during your full-time job because your free time probably won’t be sufficient.
Communicate frequently with your student and org admin(s). You’ll need to answer to both your org admin and student— make their lives easier by being available when they need you. Most admins will periodically check in to make sure all your organization’s projects are on track; if you don’t respond in a timely manner, they may think your project is failing. Your student often has a regular stream of questions, some of which can’t be answered by Google, so be available to avoid wasting your student’s time and delaying the project.	Disappear. Some students will need constant access to their mentors. If you intend on being out of touch for even a relatively short period of time, even just a few days, let your student know ahead of time. Arrange it so that your student is able to reach a backup mentor during this time and having the student know about this backup mentor from the beginning of the project is also good advice. Although disappearing mentors are less common than disappearing students, they do happen. This can really put a strain on your org admin who has to replace you on short notice, maybe near a deadline.
Set aside at least 5 hours a week for mentoring. The student has to do the actual work over the summer but you’ve committed to help them along the way. Depending on how much help your student needs, this can be a significant task. Set aside at least 5 hours per week for mentoring unless you are certain the student is well integrated and supported by the whole community. And even then, plan for road-blocks along the way that you need to help with.	Underestimate mentoring effort. Mentoring takes time. No, really, it does. You might be lucky and have a student who needs little mentoring, but you probably won’t. If you don’t have at least a few hours per week over the course of the program, you have two options. You can either choose not to mentor or you can team up with another member of your team as a back-up mentor. Be aware that ‘a few hours’ can grow quite significantly if you or the student overestimated their abilities, underestimated the project, or they need more significant help than you planned.
Give your student frequent feedback on performance. Let the student know whether you are happy or unhappy with his performance. Chances are he can’t properly judge his own performance and abilities yet. Make sure your student sees failure coming a mile away; it should never be a surprise. You also want to ensure your student knows his work is high-quality, if it is. Give feedback regularly. This goes both ways—ask your student if he is happy with your mentoring and where you might be able to improve.	Provide zero feedback, then abruptly fail the student. The student depends on feedback from the mentor. This includes situations where things don’t go as planned. If it is the student’s fault, he should learn about it as soon as possible to be able to correct it, and more importantly, avoid repeating it. Failing your student by surprise is almost guaranteed to end up with bad feelings on both sides and can result in appeals to Google. It’s equally bad for a student to spend the summer frightened that they’re doing a terrible job because you haven’t told them that they are actually doing fine (or better). Communicate.
Ensure your student’s code is ready to integrate. Seeing code shipped in a release and then used by thousands of people is the ultimate motivation to continue being an active part of your community for many people. You should help and motivate your student to go those few extra steps and get their summer’s work into a release. You can jump-start this with small tasks and bug fixes before application time, or in the community bonding period. This way you can ensure your student has some code committed before even starting the project. Encourage students to keep code in a state where you can still integrate it if they leave the project immediately after, or even during, Google Summer of Code.	Fail to ship your student’s code. Your student might not have gotten the code into a state that’s ready to release or integrate by the end of Google Summer of Code. Do not wait too long with this—if the goal isn’t the next release, it may never happen. Committing the result is an expectation worth setting, so ensure your student understands this from the beginning of the project. If your student forks or branches early and doesn’t track any changes to trunk it can be hard to integrate. If your student develops in a non-agile style where the code doesn’t work at all unless the whole project works perfectly, the same problem can arise.
Prevent your student from going down dead ends with code. Your student will make mistakes and wrong decisions. It is your job as his mentor to intervene when he is stuck or heading in the wrong direction. Do this early. Google Summer of Code is too short for anything else. This requires you to keep a close eye on what he is doing. Some teams prefer short daily meetings to make sure everyone is on top of things and know what everyone else is working on. It’s also important to reinforce good practices so the student can continue to use them.	Review your student’s code for the first time at the end of the summer. Your student might be a genius and a mind reader but chances are that he isn’t. He probably won’t create an excellent design, write perfect code and deliver stunning documentation independently. He’s probably never done a project of this size before. If you don’t find problems early, they pile up and lead to a failed project with nobody to blame for it but yourself.
Promote your student’s independence. When your student encounters a problem and comes to you or the community for help, ask her to suggest a potential solution as well. This encourages your student to learn how to do research and to fully understand problems and how to get into the mindset of solving them. It also makes it much more likely that her questions are well-informed, giving the community a much better impression of your student. When possible, direct your student to participate directly in the community rather than acting as a conduit, because close ties to the community make it more likely that she will want to stay involved with the community after the summer.	Get between your student and the community or the code. It’s easy to fall into the trap of writing tricky code or solving every difficult problem for your student. This prevents students from gaining skill and confidence by solving their own problems, or at least making progress toward a solution. One of the best ways to ensure your student disappears at the end of the summer is to never invite her into the broader community of your organization. Without social ties, students are much more likely to move on to other things and leave your organization behind.

Making Google Summer of Code the best possible program requires preparation and a commitment to excellence from all participants. Now that we’ve provided suggestions for mentors, org admins, and students, you should know how to avoid the most common problems at every level. Whatever role you would like to play in Google Summer of Code or a similar program, read everything you can so you are fully prepared for the experience. Good luck, and have fun in your endeavors.

By Donnie Berkholz, Lydia Pintscher, and Kevin Smith, Google Summer of Code Administrators for Gentoo & X.Org, KDE, and XMPP Standards Foundation, respectively

Former student pays it forward as a mentor for Google Code-in

Charlie Gordon was a student participant in the Google Highly Open Participation Contest, an earlier version of Google Code-in that pairs high school students with mentors in open source projects. Here he discusses his recent experience as a Mentor for the 2010-2011 Google Code-in.

There were so many great stories from Google Code-in that it's hard to pick out just a few. I'm always so excited to get young people involved in open source - I remember how excited I was when I participated in the Google Highly Open Participation Contest myself back in 2007-2008. The program opened many exciting doors for me, including going to Drupal conferences, becoming involved in Drupal core development, and even eventually going to college at MIT, where I am now. It brings me great joy to be able to help open the same doors for the next generation of bright young open source enthusiasts.

Now for the stories! I'm always impressed when students, who are used to doing only what they're specifically told to do for school assignments, go above and beyond. Especially in the format of a contest where the incentives lead students to do the bare minimum, I find those students who put in a real effort to go above and beyond are those who really care about the open source project, and are those who are most likely to stick with it after the contest ends. Here are some of these students:

A student from Thailand, "chalet16", worked on five complex coding tasks for Drupal's style guide module. Over many iterations with the tasks' mentor, the quality of chalet16's code improved, and he also became more comfortable with using drupal.org's issue queue, a key part of our development process. Not only were the tasks well done, but when chalet16 encountered software bugs in parts of the code that he wasn't working directly on, chalet16 had no problem taking the initiative and opening new issues for the bugs, even submitting additional patches to those issues that fixed the problem. That's exactly the kind of participation that we want to attract to our project, and to open source software development in general.

Despite not having very much experience in PHP, “aantn,” a student from Israel, found ways to contribute to the Drupal project, such as by writing a Python script to survey test coverage statistics for Drupal core and the top 50 or so modules. We now have a much better idea of where and to what extent our automated testing system is being used, and making such statistics public will hopefully encourage module maintainers to write more test coverage for their code.

We specified a task that called for a Drupal core patch to allow a "full preview" button on the content submission form. Halfway through the task, Romanian student "bluman," encountered big roadblocks to that patch. After discussing the issue, we realized that the task would not work as a patch for Drupal core, but would have to be rewritten from the ground up as a contributed module. However, rather than give up, bluman worked hard to redo the task as a module, and came up with fantastic results.

Finally, we set a task to translate a small to medium sized module into another language. Another student from Romania, “ungureanuvladvictor," went way above and beyond the task description, translating one of the largest and most widely used contributed Drupal modules into Romanian. The translation file had more than 1,000 translations in it, a very impressive feat for such a short period of time. I had to scramble to find a Romanian speaker willing to review such a large translation!

Really, there are so many impressive students out there.

By Charlie Gordon, Drupal.org mentor

We always hope that the students who participate in programs like Google Code-in and Google Summer of Code develop a bond with the open source community they work with during the program and continue to contribute to the community long after the contest ends. Charlie Gordon is a prime example; he not only continues to be actively involved in the Drupal community but he is also sharing his experience and wisdom with younger developers and helping them become contributors to open source. Great job, Charlie!

By Stephanie Taylor, Open Source Programs Office

Googlers @ Women and Open Source: Panel Discussion

Last week the SD Forum held a panel discussion in Mountain View, CA entitled Tech Women: Women and Open Source. The discussion focused on explaining what open source is and how people can become involved in the open source community.

The Speakers included Google Open Source Program Office’s Cat Allman, Automattic and Wordpress hacker Beau Lebens, LinuxForce’s Elizabeth Krumbach, and MeeGo’s Alison Chaiken. The panel was moderated by Janet Fouts, founder of the Social Media Coaching Center and Senior Partner at Tatu Digital Media.

Some questions posed to the panel included:

Video 1

(3:45) What does open source mean?

(8:26) Which women do you view as role models or mentors. What women

are making a difference in the open source community?

(13:29) There is a huge community around open source. How would someone

who is new to open source get started in open source?

(23:39) What barriers to entry for women have you seen in the open source

community?

(32:25) How do you mentor others?

(44:33) Where’s the profit?

(50:20) How would you find a group or organization to join in open source?

Video 2

(01:02) Who are the main contributors to open source? Are they people

working on open source full time or in their spare time?

As an attendee of the meeting I found the overall message to be that anyone can become involved in open source with any kind of background, you don’t have to be a programmer to be an open source contributor. You can help with documentation, marketing, events, help with mailing list questions or a number of other roles that need to be filled in a particular project.

There are open source projects on just about any topic you can imagine so search the web for something you are interested in, whether it’s disaster relief, gaming, mathematics, translation software, music players, business applications and so on. Watch the IRC channel, join mailing lists and just hang out and absorb the knowledge and vibe of the particular open source project that interests you and you can quickly learn about the project and find your niche in the community.

Remember, there is something for everyone in open source. Join in the fun!

By Stephanie Taylor, Open Source Programs Office

Geek Time with Josh Bloch

In addition to being known as “The Mother of Java,” Josh Bloch is also the Chief Java Architect at Google. Josh sat down with fellow Open Source Programs Office colleague Jeremy Allison to chat about APIs, the importance of openness, and the successes and failures of Java.

Some highlights from their conversation:

(0:45) Josh describes what he does for Java and at Google.

(1:59) Jeremy expresses his disappointments with Java, based on the early potential that it showed. Josh responds with an explanation of some of the difficulties that Java faced.

(4:48) Josh and Jeremy talk about some of the factors that contributed to Java’s successes.

(9:51) Josh’s explains his philosophy towards creating APIs.

(14:30) Josh talks about the APIs that he’s most proud of.

(19:45) Josh and Jeremy discuss the importance of reading other people’s code, and the impact of Sun’s decision to put the code and bug database for Java on the web.

(24:00) Josh explains how he came to be in his current position and gives advice for others who are looking for ways to get started programming.

(27:32) Josh wrote the standard Java best-practices guide, Effective Java, and co-authored two other Java books: Java Puzzlers, and Java Concurrency in Practice. As a special treat for this blog’s readers, Josh is offering signed copies of his books for the first two people with correct responses to the following puzzle. Submit your answer as a comment on this post, then use the same Blogger ID to leave a separate comment with your contact info and inscription request (for your privacy, the comment with your contact info will not be published).

Josh’s Puzzle: “The Story of O”

The following Java program is not quite complete; it’s missing a parameter declaration for o. Can you provide a declaration that makes the program print “O noes!”? (The program must compile without generating any warnings.)

public class Story {
   public static void main(String[] args) {
       Object o = null;
       story(o);
   }

   private static void story(<you provide the declaration> o) {
       if (o != null)
           System.out.println("O noes!");
   }
}

Remember to leave your answer and contact info as two separate comments!

By Ellen Ko, Open Source Team

Introducing CityHash

We’re pleased to announce the new CityHash family of hash functions for strings. We’re releasing two functions today: CityHash64 and CityHash128. They hash strings to 64- and 128-bit hash codes, respectively. These functions aren’t suitable for cryptography, but our experience so far shows that they’re great for, say, hash tables.

We tried to optimize for CPUs that are common in Google’s datacenters, but it turns out that most PCs and laptops have the relevant features as well. The important ones are 64-bit registers, instruction-level parallelism, and fast unaligned memory accesses.

We were greatly inspired by previous work on hashing, especially Austin Appleby’s MurmurHash. The key advantage of our approach is that most steps contain at least two independent mathematical operations. Modern CPUs tend to perform best with this type of code.

The disadvantage of our approach is that the code is more complicated than most popular alternatives. We decided to optimize for speed rather than simplicity and even included special cases for short inputs.

Overall, we believe that CityHash64 and CityHash128 are exciting new ways to solve a classic problem. Under real-life conditions we expect CityHash64 to outperform previous work by at least 30% in speed, and perhaps as much as a factor of two. Also, as far as we know, these functions’ statistical properties are sound. Please don’t hesitate to try this fast new code!

By Geoff Pike and Jyrki Alakuijala, Software Engineering Team

Final hours to submit your Google Summer of Code student applications!

The student application period for the 2011 Google Summer of Code is almost over. All applications must be submitted into the Google Summer of Code site by Friday, April 8th at 19:00 UTC to be considered for this year's program. Don't wait until the last minute!

By Stephanie Taylor, Open Source Team

Linux Foundation Collaboration Summit 2011

This week marks the fifth annual Linux Foundation Collaboration Summit, which will be held from April 6th to 8th in San Francisco, CA. Many Googlers will be attending, and several Googlers are presenting at the Summit as well.

Andrew Morton will be in a panel discussion on The Linux Kernel: What's Next at 11 AM on Wednesday April 6th.

Michael Rubin, Technical Lead for Google's Kernel Storage team will be presenting a keynote on File systems in the Cloud at 3:30 on Wednesday.

Ian Lance Taylor will be discussing the Go Programming Language at 2:15 on Thursday the 7th as part of the Tools track.

Later on Thursday, Jeremy Allison of the Open Source Programs Office will explain Why Samba Switched to GPLv3 at 4 PM.

Although the event is invitation only, live video streaming is available for free, so everyone can watch the keynotes and panel discussions. Tune in to the video stream, or if you’ll be attending, introduce yourself after any of the talks!

By Ellen Ko, Open Source Team

The DOs and DON’Ts of Google Summer of Code: Organization Administrator Edition

This is the second in a series of three posts on DOs and DON’Ts for Google Summer of Code students, mentors, and organization administrators. The first post dealt with students while this post features mentoring organization administrators. Organization administrators (org admins) oversee the overall progress of a mentoring organization and its students throughout the program. Based on our experience with Google Summer of Code, we’d like to share these tips and antipatterns with you to raise awareness and help other org admins avoid the same mistakes we’ve made. For even more advice, check out the mentor/admin guide.

DO	DON’T
Track the timeline and projects closely. Most mentors and students need a helping hand, and you can only provide this if you’re aware of the deadlines yourself. Be sure both mentors and students are aware of their next steps. Also, keep track of the progress of each project, perhaps with a spreadsheet filled in by the mentors—this gives you time to deal with major problems before midterms/finals, when little choice exists besides failing the student.	Fail to follow up on mentors and students. It is easy to lose your perspective of deadlines and progress. If you don’t stay on top of them and make sure they are aware of their responsibilities it can result in unnecessary failure of students or embarrassment for your organization.
Start small. Everyone gets the most out of Google Summer of Code when the orgs are on top of everything and everyone knows what’s going on. You can achieve this most easily with only a small number of mentors and students. Successful orgs tend to be invited back, so plan for success; there is time to grow later. It’s much better to have a few overwhelming successes than many borderline cases and failures.	Take on too many students. Most new organizations try to get as many slots as they can. This is, however, rarely a good idea. They greatly underestimate the resources needed to mentor a group of students in a program like Google Summer of Code. Taking on too many students almost always leads to a poor project outcome and integration of the students in the community and thus low retention rates.
Ensure you can support the number of students you request. The requirements for project voting and ordering become much more severe as the number of students, mentors and projects increases; it’s nowhere near a linear scale. After coding starts, you still need to track projects to make sure your overall program is running well. Avoid methods that rely on significant time commitment from you, and instead distribute the effort to mentors and students.	Grow too quickly. Once you’ve succeeded with a couple of students, it can be tempting to think you’ve figured everything out. But things that work great on a small scale can fail wretchedly when scaled up. For example, asking every mentor to read every proposal might work fine when there are only 10 proposals, but it doesn’t function nearly as well when there are 100.
Plan for communication throughout Google Summer of Code. There are times throughout the program when you need to let the mentors and/or students know about certain things, like deadlines. Plan for this from the start of the program by, for example, subscribing everyone to a dedicated mailing list. Make it clear from the start that mentors and students can approach you to discuss nontechnical problems, so they know they can rely on you as a resource. Overall, you need to be visible and keep people motivated throughout the process—and follow up with students afterwards to encourage them to become long-term contributors.	Forget to keep clear lines of communication with the mentors and students. Discovering you need to get in touch with a student or mentor and finding you can’t reach them is trouble in the making. If you don’t have backup contact details for mentors, it’s easy for them to disappear—particularly if your primary method is an online chat like IRC or XMPP.
Work out your responsibilities in advance. If you’re a new org, it may not be obvious what you need to do to support the mentors and the students. Make sure both you and your mentors have the same idea about your role. Particular things could be: If your organization has IRC meetings, you need to make sure they run smoothly. If your organization requires blog posts, or mailing list updates, you have to make sure these happen. Once the program starts your enthusiasm needs to continue because it feeds mentors and the students. To maintain your excitement, think about the benefits your organization receives at the end of the program for every successful project: new code and new contributors!	Be enthusiastic in the application stage but stop when the projects start. It’s relatively easy to keep enthusiasm high when it’s early in the process as your tasks are obvious (apply for Google Summer of Code, get the ideas page sorted, get the mentors lined up, set up mailing lists, etc.). If mentors or students sense you are distracted or no longer dedicated to your role as organization administrator, their enthusiasm for the project will likely decrease. You are the glue that holds everything together and everyone will look to you to keep things moving forward.
Coordinate mentors early to get a high-quality ideas list. At the meetings for rejected orgs, the most common theme by far is “you can improve your ideas page.” Look at other orgs’ ideas pages for this year and for last year, as well as the mentoring guide. New organizations often ask whether their ideas are too long, but they usually aren’t; clarity and detail are highly desirable. To maximize student interest in your organization, you should have an ideas page well in advance of the deadline for org applications. Also be sure to give the students what they need to get excited about the projects and contact you; provide enough context to convince them why this idea matters. If there are specs for the projects, link to them and be sure to provide contact details for each idea. Handling student interest in the run-up to applications can be very time-consuming, plan accordingly.	Construct your ideas page at the last minute. Students look at the ideas pages long before orgs are selected; they’ll pass your organization by if you don’t have ideas ready when they first start researching the orgs. Failure to prepare early has particularly large consequences for umbrella orgs, where there is a logical disconnect between several developer communities, but it also holds true for individual projects. To avoid “writer’s block,” you can start with a high-level idea of what types of projects your org wants to sponsor and work from there.
Arrange infrastructure in advance. Most projects will require some infrastructure to be in place for students to work effectively—whether it’s a committer account, repository creation, students knowing where they should post their code, or simply getting them subscribed to relevant mailing lists and taught the proper protocols. Everything should be in place for students to make their first commits as a true member of your organization’s community on the initial day of coding. There’s also a brand-new mailing list for supporting new org admins called gsoc-veterans that you can turn to for advice (new organizations will be invited soon).	Block projects from starting on day one of the coding period. If technical difficulties prevent students from being productive when coding should have started, it instantly lowers the scope of what they can accomplish during the summer and may prevent them from finishing their projects. For example, if they don’t know how to use your version-control system or don’t have commit access, they’ll be mired in tangential problems instead of coding.

Making Google Summer of Code the best possible program requires a commitment to excellence and preparation from participants at every level. In this post we’ve provided suggestions for org admins, and in the last post in this series we’ll cover mentors. Whatever role you would like to play in Google Summer of Code or a similar program, read everything you can find so you know what you’re getting into. Good luck, and have fun this summer!

By Donnie Berkholz, Lydia Pintscher, and Kevin Smith, Google Summer of Code Administrators for Gentoo & X.Org, KDE, and XMPP Standards Foundation, respectively