Mentoring Organization Applications Now Being Accepted for Google Summer of Code!

Interested in finding bright, enthusiastic new contributors to your open source project? Apply to be a mentoring organization in our Google Summer of Code program. We are now accepting applications from open source projects interested in acting as mentoring organizations.

Now in its 7th year, Google Summer of Code is a program designed to pair university students from around the world with mentors at open source projects in such varied fields as academia, language translations, content management systems, games, and operating systems. Since 2005, over 4,500 students from 85 countries have completed the Google Summer of Code program with the support of over 300 mentoring organizations. Students earn a stipend for their work during the program, allowing students to gain exposure to real-world software development and an opportunity for employment in areas related to their academic pursuits, thus “flipping bits, not burgers” during their school break. In return, mentoring organizations have the opportunity to identify and attract new developers to their projects and these students often continue their work with the organizations after Google Summer of Code concludes.

This year we’re excited to expand the scope of the program by encouraging experienced Google Summer of Code mentoring organizations to refer newer, smaller organizations they think could benefit from the program to apply to be mentoring organizations.

The deadline for applying to be a mentoring organization for Google Summer of Code is Friday, March 11th at 23:00 UTC (3pm PST). The list of accepted organizations will be posted on the Google Summer of Code site on Friday, March 18th. Students will then have 10 days to reach out to the accepted organizations and discuss their ideas before we begin accepting student applications on March 28th.

Please visit our Frequently Asked Questions page for more details. You can also check out the Mentor Manual and timeline for additional information. Good luck to all of our mentoring organization applicants!

By Stephanie Taylor, Open Source Team

Geek Time with Jim Zemlin

Jim Zemlin is the Executive Director of the Linux Foundation, and earlier this month he sat down with the Open Source Programs Office’s Jeremy Allison for a chat about the future of Linux. In addition to talking about the future, Jim shares insights on the history and significance of Linux. Some highlights:

• Jim explains the role of the Linux Foundation in Linux kernel development, including the work of Linus Torvalds. (0:18)

• Jeremy and Jim talk about the organizations that support the Linux Foundation, and their reasons for doing so. (2:21)

• Jim is well known for his presentations for the Linux Foundation, and Jeremy asks Jim to delve further into the topic of one of his talks, where he describes his vision of “Linux Everywhere.” (4:55)

• Jeremy poses one of his favorite questions: “Is this the year of the Linux desktop?” Jim responds with less concern about desktop computers and focuses his interest on mobile devices, which are becoming predominately Linux. (9:33)

• The discussion turns toward tablet devices and their impact on Linux. (13:25)

• Linux’s GPLv2 license allows DRM, and Jeremy wonders if this contradicts the ideals of freedom that Linux was built upon. Jim compares the controversy to the “Consume vs. Contribute” issue that Linux faced years ago. In that case, the collaborative nature of open source software development made it advantageous for everyone to contribute, so most commercial users eventually ended up contributing. In regards to DRM, Jim believes that consumers dictate the future of DRM products. (15:23)

• Jim recounts a conversation he had with a major electronics company about the importance and complexity of software on consumer electronic devices. Jim explains how these considerations direct manufacturers towards open source software. (20:32)

• Jeremy asks Jim about the feasibility of creating an operating system from scratch, or if Linux is the only viable option. The value of Linux was recently estimated at $10.8 billion, so the barrier to entry is extremely high. In addition, there are several incentives for using the existing Linux ecosystem. (23:07)

• Jim talks about how advances in one field of Linux has benefited other fields. For example, developers working on mobile devices helped reduce power consumption for those working on high-performance computing. (26:58)

• Jim shares how his career path led him to his current role at the Linux Foundation. (31:05)

By Ellen Ko, Open Source Team

Googlers at Tech@State: Open Source Technology Conference

Earlier this month two members of the Google Open Source Programs Office, Chris DiBona and Jeremy Allison, traveled to Washington, D.C. to speak on a panel about open source in government at the State Department’s Tech@State: Open Source conference.

Chris and Jeremy were joined by an impressive lineup of speakers who joined together to illustrate how open source software can improve the education, health, and welfare of the world's population. The video of their discussion is featured above, and more information about the event and videos from all of the sessions are available on the conference’s video page.

By Ellen Ko, Open Source Team

I Have Come From The Land Down Under....

Along with an unintended tan from the Brisbane sun and a serious sense of awe at how large golden silk orb-weavers are, I came home from linux.conf.au (LCA) 2011 with a bunch of new ideas from the plethora of terrific talks at the conference. You can find videos of most of the talks on the conference wiki but I have to call out some of my favorites here.

First and foremost, Vint Cerf, Googler and co-designer of the TCP/IP protocols, gave a thoughtful and humorous keynote on where he thinks the internet is going, and what we need to do to get it there. Despite widely held concern around the rapidly decreasing number of available IP addresses, his deeply informed take on the situation was characteristically upbeat.

While Google has released more that 20 million lines of open source code through the years, we’re always trying to release more. My colleagues, Dan Bentley and Daniel Nadasi, gave an extremely useful talk about Make Open Easy (MOE), their program within Google to make the process for Googlers to open source code as fast and easy as possible, and how this methodology might be used by other businesses.

They also talked about the challenges a project faces in trying to be useful to both the public and the internal teams that depend on it. Last but far from least, I was wowed on Thursday by Paul Gardner-Stephen’s talk on “The Serval BatPhone: Making Mesh Mobile Telephony Practical, Anywhere, Any Time.”

Especially in light of recent catastrophic weather events in Australia, the potential to free cellular phone communication from the constraints of significant and expensive infrastructure is hugely exciting. This LCA, completely relocated because of extensive flooding 10 days before opening, was one for the record books. As always, LCA was stimulating, exhausting, warm, and a wonderfully well-organized meeting of over 700 curious minds.

By Cat Allman, Open Source Team

Use Google Apps APIs without writing a program

Today we are releasing the Google Apps Shell Interface (GASI), a graphical user interface for administrators working with Google Apps APIs.

Google Apps administrators work with the APIs for a variety of reasons. First, there are a number of features that are only exposed to the administrator through the APIs. Second, the administrator may wish to save time by automating a task instead of repeating it for thousands of users. Traditionally, you’d write a program directly using the Google Apps APIs, use libraries such as gData, or write a shell script using third party scripts such as the Google Apps Manager (GAM).

Now you can also use the user interface in GASI to issue commands. GASI allows Google Apps administrators to make certain API calls through a graphical user interface without having to write a program. You can also execute commands dynamically generated with variables from a CSV file, for batch execution.

The commands available in GASI are listed in the documentation page for the Google Apps Shell (GAS), a library that comes with GASI. GAS can also be called from a command line interface. The current version of GAS contains commands to configure email settings, Google Groups, user nicknames, user accounts, and domain organizations. For example, there is a GAS command to move a user to an organization in the control panel. With GASI, you can programmatically run this command for a number of users listed in a CSV file. Other common use cases include renaming usernames or creating user nicknames.

If you’re looking for other ways to use Google APIs through a command line, check out the Postini EZCommand Shell and Google CL, two other open source projects from Google.

By Jeff Pickhardt, Enterprise Sales Engineering Team

Google Code-in Grand Prize Winners

Today we are pleased to announce the grand prize winners of the Google Code-in contest. We first want to thank all the participants for their work – we had over 2,000 tasks completed by more than 360 pre-university students from 48 countries! Every student who participated in the contest will be receiving a t-shirt and certificate of participation.

We decided that 10 grand prize winners weren’t sufficient to acknowledge all the hard work put into the contest, so we’ve accepted our top 14 finalists instead. For their excellent work with our mentoring organizations these finalists will be invited to Google’s headquarters in Mountain View with a parent or legal guardian and have a day to meet with Google’s engineers. They’ll also get another day to have some fun in the California sun.

So, drumroll please, here are our winners in order by last name:

1. Utku Aydin, Turkey
2. Fernando Brito, Brazil
3. David Czech, Canada
4. Aviral Dasgupta, India
5. Alexandru-Marian Florescu, Romania
6. Gautam Gupta, India
7. Daniel Kang, United States
8. Nolan Lum, United States
9. Daniel Marth, Austria
10. Florentina Musat, Romania
11. Pim Otte, Netherlands
12. Matt Rajca, United States
13. Furkan Üzümcü, Turkey
14. Tony Young, New Zealand

Congratulations to our Grand Prize Winners, and to everyone who participated, including the more than 350 mentors from the 20 open source projects who volunteered their time to help these young people get started in open source.

By Carol Smith, Open Source Team

UseR Meetup at Google San Francisco

Earlier this week, Google hosted the Bay Area useR Group at our San Francisco office. Over 40 attendees showed up to hear Dylan Beaudette from UC Davis give a presentation about investigating soil genesis and geography with R (PDF). Dylan has been using R to study and visualize large amounts of soil data and has made his routines available in the aqp: Algorithms for Quantitative Pedology package on CRAN.

Dylan Beaudette explaining his research.

Dylan's research also utilizes a number of Google technologies, such as Google Earth KMZ overlays of soil data and the Google Ngram Viewer for tracking Temporal Trends in Soil Science Jargon. In addition to open source and soil science, there were lively discussions at the meetup about reproducible research and the data sharing problem.

I’d like to thank our speaker, Dylan, all of the attendees, the Bay Area useR organizers who continue to put together interesting talks each month, and the Google Open Source Program Office for hosting the event. We’re looking forward to the R User Conference in England in August and more local Bay Area Meetups in the interim.

By Murray Stokely, Software Engineer, Infrastructure Quantitative Team

Google Code-In Final Statistics

Thank you to all of the participants in Google Code-In, a contest designed to introduce pre-university students from around the world to the many possibilities for participation in the open source community.

The contest was a great success with 361 students (ages 13-18) from 48 countries completing a total of 2,167 tasks during the 7 week contest period. The students completed 769 Easy tasks, 798 Medium level tasks and 600 Difficult tasks during Google Code-In. We are thrilled with the response and the quality of work completed for the contest and look forward to seeing more from these talented students in the future.

The top 10 countries with the highest number of participants were, in order: The United States, Romania, Bulgaria, The Russian Federation, India, Poland, Canada, Germany, Italy, and Australia.

We would also like to extend a huge thank you to our 20 mentoring organizations and administrators from all over the globe, who through their guidance and encouragement are introducing young coders to the numerous ways to contribute to diverse open source projects.

Please stay tuned as we announce the Google Code-In contest winners on Monday, February 14th.

By Stephanie Taylor, Open Source Team

Contracts for Java

If you’ve ever spent hours debugging your Java code, today’s blog post is for you.

Often bugs that are frustratingly elusive and hard to track down appear simple or even trivial once you have found their cause (the fault). Why are those bugs hard to track down? One possibility is that the fault is in a completely different part of the program than its symptom (the failure).


Contracted code reveals failures much closer to their fault, leaving you with a far simpler problem to solve:

Traditionally, Java programmers enforced preconditions using explicit parameter validation code in public methods, and assertions in non-public methods. Likewise, they enforced invariants and postconditions using assertions. This approach is described in detail here. Since then, new features in Java 5 have enabled a more convenient and expressive implementation of contracts.

Contracts for Java is our new open source tool. Preconditions, postconditions, and invariants are added as Java boolean expressions inside annotations. By default these do nothing, but enabled via a JVM argument, they’re checked at runtime.

• @Requires, @Ensures, @ThrowEnsures and @Invariant specify contracts as Java boolean expressions
• Contracts are inherited from both interfaces and classes and can be selectively enabled at runtime

Contracts help you turn interface documentation into code. For example:

/**
* @param left a sorted list of elements
* @param right a sorted list of elements
* @return the contents of the two lists, merged, sorted
*/
List merge(List left, List right);

Could be expressed as:

@Requires({
"Collections.isSorted(left)",
"Collections.isSorted(right)"
})
@Ensures({
"Collections.containsSame(result, Lists.concatenate(left, right))",
"Collections.isSorted(result)"
})
List merge(List left, List right);

The interface is now precise and every class that implements it can be checked at runtime.

Contracts are a powerful language feature and can provide great benefit if used correctly. We recommend that newcomers find an expert to learn from or spend some time reading around the subject to pick up good habits and avoid bad ones.

One point that often surprises people is that contracts must not be used to validate data. Contracts exist to check for programmer error, not for user error or environment failures. Any difference between execution with and without runtime contract checking (apart from performance) is by definition a bug. Contracts must never have side effects.

Another important point is that by convention module interfaces in Java are total, that is, they are defined for all input. In the case of incorrect input, they promise that a particular exception will be thrown. This behavior remains part of each method’s implementation and cannot be moved to the contract.

Contracts for Java is based on Modern Jass by Johannes Rieken. Rather than being a full time project it was conceived and developed in the 20% time of two software engineers and then developed further through an internship. The internship report (PDF) goes into detail about the work done and the methodologies used.

Contracts for Java was inspired by Eiffel, a language invented by Bertrand Meyer, which has built in support for contracts.

By David Morgan, Andreas Leitner and Nhat Minh Le, Contracts for Java 20% Team

Flip Bits not Burgers, the Student Guide

The Google Summer of Code Mentor Manual, published before the 2009 Mentor Summit, was an effort to help mentors choose the best students and get them involved in the open source community. The Mentor Manual had some extremely useful tips on how organizations can make the best use of the program, so in 2010 the authors printed a new edition that has tips for organization administrators as well!

When you have a manual for the mentors and org admins, it’s only fair and logical to have one for the students as well. After all, they’re the ones who need the most help preparing for and working on Google Summer of Code! So the authors of the Mentor Manual decided to write a Student Manual in the days before the 2010 Mentor Summit, and they realized it would be a good idea to get input from students. This is where I enter the scene–I was a Google Summer of Code student for the Systers organization in 2009, and a mentor for Systers in 2010. Jennifer Redman, my mentor in 2009 and co-author of the original Mentor Manual, suggested that I participate in the book sprint for the Student Manual so I could share my first-hand experience as a student.

We wanted the Student Manual to be the one stop shop for all the questions that students might have about Google Summer of Code. The manual has great insights for students before, during and after the program. These include:

• How to decide whether or not to apply for Google Summer of Code
• Getting code reviews and handling feedback
• Interacting with mentors
• Staying involved after the program ends

The book also has some very useful advice on making first contact with the mentoring organization, appreciating the open source culture, and most importantly, writing good project proposals.

Who can give better advice on writing good proposals for Google Summer of Code than the people who would actually evaluate them? I think the suggestions on how to write a good proposal, straight from the mentors, is something that makes the book extremely useful for the students. The book also has suggestions on selecting the projects that you should consider applying for, how to manage your time better, and how to get the most from your mentor and Google Summer of Code–there’s even a section on what to do if you’re not selected. This goes extremely well with the spirit of Google Summer of Code where one of the goals is to get students involved in open source projects irrespective of them being Google Summer of Code students or not. I guess I can go on and on about the book and the chapters, so a better option might be to check out the book and see for yourself: http://www.booki.cc/gsocstudentguide/

Google Summer of Code Student Manual Authors, photo by Selena Deckelmann

We have made a sincere effort to include as much useful advice and as many helpful suggestions in the book as possible, and in true open source style, there is an editable version available, so if you feel that something is missing in the manual, you can make a contribution to it!

By Malveeka Tewari, Google Summer of Code 2009 Student and 2010 Mentor for Systers