BAVC Open Source Software class visits Google

The continuing mission of the Bay Area Video Coalition (BAVC) is to inspire social change by enabling the sharing of diverse stories through art, education and technology. One of the ways they pursue this goal is by offering classes to youth, such as their Digital Pathways: Open Source class. This program offers intensive media training for young people who want to learn skills related to careers in technology and the media arts.

Earlier this month the class was treated to lunch and a tour of Google’s headquarters in Mountain View, CA. During lunch, the students had a chance to sit down with members of the Open Source Programs Office and ask questions about working in open source. They talked with Junio C Hamano, maintainer of the GIT project, Ian Hickson, writer for the HTML5 spec, and Carol Smith, administrator for Google Summer of Code and Google Code-in.

The students range in age from 13 to 19 years old and most had never coded in any language before they started. If you know someone in the San Francisco Bay Area who wants to learn more about open source, this class is a great introduction. More photos and information about the class are available on the BAVC Digital Pathways: Open Source blog.

By Ellen Ko, Open Source Team; Photo by kingobie1

Student applications now being accepted for Google Summer of Code

Today marks the start of the 2011 Google Summer of Code student application period.

Google Summer of Code is a global program where university students are given a stipend to write code for open source projects over a three month period. Through Google Summer of Code, accepted students are paired with a mentor from the participating projects, gaining exposure to real-world software development and the opportunity for employment in areas related to their academic pursuits. Best of all, more source code is created and released for the use and benefit of all.

Google Summer of Code is a highly competitive program with a limited number of students being accepted. We are pleased to announce that this year we have enlarged the program so that we can accept as many as 150 additional students. We hope all interested students will apply!

Now it is time for the students to submit their proposals to the accepted mentoring organizations via the Google Summer of Code program website from today through Friday, April 8th 19:00 UTC. For the past 10 days students have had the opportunity to review the Ideas pages for this year’s 175 accepted projects and to research which projects they would like to contribute to for this year’s Google Summer of Code.

Every year we have thousands of students who apply for the Google Summer of Code program but due to the limited number of slots many students are not able to be a part of the program. The quality of your proposal is what will make you stand out from your peers. Students should consult the Google Summer of Code student manual for suggestions on how to write a proposal that will grab the attention of the mentoring organizations. Multiple proposals are allowed but we highly recommend focusing on quality over quantity. The mentoring organizations have many proposals to review, so it is important to follow each organization’s specific guidelines or templates and we advise you to submit your proposal early so you can receive timely feedback.

For more tips, see a list of some helpful dos and don’ts for successful student participation written by a group of experienced Google Summer of Code administrators, our user’s guide for the program site, Frequently Asked Questions and timeline. You can also stay up-to-date on all things Google Summer of Code on our Google Open Source blog, mailing lists or on IRC at #gsoc on Freenode.

Good luck students and remember to submit your proposals early–you only have until April 8!

By Stephanie Taylor, Open Source Programs Office

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

As Google Summer of Code mentoring organization administrators, we are the people who ensure Google Summer of Code runs smoothly within our organizations. Over the past 6 years, contributors to our four open-source projects (Gentoo, KDE, XMPP, and X.Org) have read more than 1,000 student applications and mentored hundreds of successful, and unsuccessful, students.

Based on our experience with Google Summer of Code, we’ve built cultural and community practices that strongly favor successful student projects, integration of code, and conversion of students to long-term contributors. We’ve also seen a lot of things go wrong—repeatedly. We’d like to share these tips and antipatterns with you to raise awareness and help students avoid the same mistakes when taking part in the program. For even more advice, check out the student guide.

DO DON’T Be on your best behavior. Clear, respectful communication is just as important to success today as it was 100 years ago. When you write email or chat on IRC, use complete sentences without any SMS abbreviations (but acronyms are allowed, especially on IRC). If you are unsure about your English skills, there are tools available to help you, such as spell checkers and grammar checkers. On a related note, people want to work with others whose company they enjoy. Be friendly and polite; it’s hard to be too much of either. Make a bad first impression: SMS speech, extremely poor English, rudeness/hostility, etc. These fall into two major categories: failure to communicate and inability to get along with other people. Poor first impressions can seriously damage your chances because both of these problems derail collaboration, which is vital to a successful project. Entirely adequate programmers fail Google Summer of Code because of failures to communicate. Read all the documentation, so you submit a useful application. Your application should provide all the detail necessary to convince people that you can accomplish your project, and you’re the best person to do it. That means showing you have experience, proving you’ve done research, and providing a concrete plan. Submit a useless application. Many varieties of entirely unhelpful applications exist: the one-sentence wonder, the proposal pasted directly from the ideas page, the free-form text that ignores an application template, and the application submitted to the wrong organization. Be transparent about other commitments. When organizations know about your commitments in advance, you can work with them to develop a plan that deals with your schedule. For example, you could begin your work at a slower pace during the community-bonding period. If another commitment comes as a surprise to your mentor during the summer, you might not be able to compensate for it. Disappear. If your mentor thinks you have disappeared during the summer, this tends to quickly result in failure. The most common problem is failing to mention long family vacations or class schedules in the summer. Disappearing includes taking the initial payment and running with it; if you’re tempted to do this, you might want to consider the damage to your reputation, or the excited students missing out on a slot so you can waste yours. Make Google Summer of Code your top priority. During the 12 weeks of coding time, nothing should take precedence over your project, and you should have no major distractions. If you have another job, decide whether you prefer it or Google Summer of Code and pick one. Make your choice early enough to leave your slot open for another student. Hold another major commitment. For example, if you have a second job without telling anyone until the start of coding, it’s a major problem. Anything outside of the program that takes more than 5–6 hours a week causes problems; this includes classes that extend through the coding period. Two simultaneous full-time jobs is unrealistic. Be realistic about your skills. Think through your past experience. If you have trouble fairly assessing your abilities, just write about your coding experience instead and your org can make its own judgment. Additionally, some orgs will gladly provide small sample tasks that you can perform to judge how easy you’ll find the summer-long projects. Over- or under-rate your abilities. As long as you have some programming skill and are able to communicate well (see above), you should be suitable for some projects. This doesn’t mean that every student is equal if they meet these requirements. Overselling yourself leads to disappointment; underselling yourself the same. Commit and publicize your code frequently. Discussing your code early and often, with your mentor and the broader community, is vital to the success of your project. Make small, easily recoverable mistakes early rather than huge ones when it’s too late to do anything about them. Make last-minute (or later) code drops. Showing your code in public can be scary. Some students wait until the very last minute to show their code to their mentor and other contributors to the project. Do this only if you have a burning desire to fail, because it’s too late for any review to fix holes in your code. Submit code that’s ready to integrate. The best thing about an open source project is seeing your own code shipped in a release and used by thousands or even millions of people. This requires some effort on your part, however. You should closely track how other developers change related code so yours can be easily added to the latest development branch as soon as—or even before—the summer ends. During the last few weeks, make sure your code is polished enough so it’s ready to add to the project’s main repository; this may require documentation or test suites. Don’t let your summer’s work go to waste. Finish the summer with code that’s “almost ready” but will take forever to ship. Many students leave their project in a state that is very close to being shippable but isn’t quite there yet. Since the mentor tends to be too busy to finish it, these projects ship very slowly, if ever. It’s your project—you need to make it see the light of the day. This can require you to keep driving the project, and not trust that the mentor will keep on top of it once the summer is over. Complete your project design before writing a line of code. Work with your mentor to define the architecture of your project before you begin coding. You don’t need to go as far as prototyping every function, but you should have a vision of how it will all eventually work at a reasonable level of detail, such as important data structures and algorithms. Determine the libraries and tools you’ll use, and be able to justify your choices. Start coding before finalizing design. You can hit major dead-ends when you haven’t yet finished working with your mentor to design the project, but you choose to begin coding anyway. For example, if you start coding for a NoSQL backend but your mentor and the rest of the community determine that a standard SQL database should be used, this can necessitate rewriting a lot of code for no reason. Changes on the architectural level can be even more disruptive to any code you’ve written prematurely. Use your resources wisely. Help is just an email away. Don’t be afraid to ask questions when you get stuck; we don’t expect you to be an expert, and we’re happy to answer your questions. On the other hand, remember to do some basic research on your own before asking, such as searching the project documentation, the source code, and Google. Refuse to ask for help. Throughout the whole program, you will encounter problems that need to be solved—some of them small and some of them large. You can waste days stuck on a problem that can be solved in an hour by talking to other team members. Remember that you’re part of a community. Very little in Google Summer of Code is 100% independent work. You may propose your project design, but you’ll develop it with the help of your mentor and community. You’ll write the code, but others will review it, and you’ll often build upon their previous work. Unlike school, where a grade could be your first feedback, in Google Summer of Code your grade (pass/fail) is your last feedback. By designing and developing your project in collaboration with your entire open-source community, you’ll get people excited about using your work and ready to integrate it. You’ll also give yourself the best chance of passing the program by receiving thorough reviews from your community and responding to them. Many students choose to continue contributing after the summer ends because of their interactions with the community. Consider it a solo project, like it often is in college. It’s not; you write the code, but your mentor is there to help with plans, designs etc. Your mentor is not like a lecturer or course leader at a college or university. There’s a whole community of people working on the project together, and you should interact with them as a whole. Don’t feel like you’re working for your mentor, you’re working for the community and your mentor is helping guide you, they are not your only point of contact. This has other implications too—other people will be working on the code base while you are, and you will see improvements happening around you as you code. You may need to keep your development branch up to date to take advantage of these.

Making Google Summer of Code the best possible program requires a commitment to excellence from participants at every level. In addition to committing to the program, you must also be thoroughly prepared.

In this post we’ve provided suggestions for students, and in later posts in this series we’ll cover mentors and admins. 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 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

The Parrot Foundation Reflects on Google Code-in

A few of the folks at The Parrot Foundation, one of the mentoring organizations for Google Code-in this year, have offered their assessment of the Google Code-in program. They discuss the wonderful students they worked with over seven busy weeks this winter along with a note to the students that participated in the Google Code-in below.

At first, I was skeptical about whether Parrot should be part of Google Code-in 2010. I was worried that it would be impossible to create small doable tasks for high-school students related to Parrot, and whether it would take up too much developer time to get students up to speed.

Fortunately, I was completely wrong. I was blown away by the caliber of the students that did Parrot-related tasks. They actually rivaled the quality of Google Summer of Code students. Since Google Code-in focused more on mentorship and less on getting a summer stipend, I think it attracted different kinds of students.

Commits to the Parrot Github repo *exploded* during Google Code-in, they almost buried us in pull requests (which isn't a bad thing!) I couldn't believe that high school students were fixing bugs in our cryptography libraries, or improving integration with GDB or refactoring Parrot internals. And to top it off, Google Code-in students translated our README to at least five new languages! Google Code-in literally made the top high school students in the world crawl out of the woodwork.

Not to mention that in the time I have been a Parrot Core Developer, I have never seen such an increase in participation on our IRC channel. Google Code-in added more new faces to our community in a few months than we usually see in a year.

I highly recommend Google Code-in to any organization that is trying to draw in new people. I don't know if anything else can compete with it.

Jonathan “Duke” Leto, Organization Administrator for Parrot Foundation

-----

The most fascinating thing about the 2010-11 Google Code-in for me was the fact that during the peak of the competition we would have four or five Google Code-in students conversing with each other on the Parrot Project's IRC channel, #parrot. These students lived in at least four different countries (U.S., Brazil, France, New Zealand). There were many hours late at night (U.S. time) when all the regular Parrot developers had gone to bed -- but the Google Code-in students kept chatting and hacking away! If only we could harness that energy year-round!

Jim Keenan, Parrot Foundation Mentor

-----

This is a cross-post of part of a blog from the Parrot Foundation directed to the Google Code-in students that participated on their project. For the complete post please click here.

When we Parrot developers first decided that Parrot would be participating in the Google Code-in program, I was quite skeptical. Most of our initial tasks were for translations and many didn't seem to me like they'd help Parrot as a project, especially since Google Code-in was a new (and untested) initiative. If you'd asked me what I though before the start of Google Code-in, I'd say that I had low expectations but would be glad if proven wrong.

I'm glad to say that the amount and quality of the contributions we've received from Google Code-in students has proven me very wrong. We've had a few low-quality results, but the large majority have been of excellent quality. Over the course of Google Code-in, we've added thousands of lines of tests and code, squashed lots of bugs and had several reported, and have increased our test coverage by about 3.5%, all of which represents a great deal of work for a large project like Parrot. As Google Code-in progressed, we've even been able to bump up the difficulty of our "difficult"-rated tasks substantially to challenge our most ambitious students. Parrot is much better off because of the efforts of all of you.

I hope to see all of you continue to make contributions to Parrot after the end of Google Code-in. Your incentives will be different from now on, but they'll also become much more exciting. If you're interested and don't know quite what you want to do, we'll always try to help you find something awesome to keep you busy. Please stick around and keep on hacking!

Thanks,
Christoph Otto, Architect, Parrot VM

-----

Thank you Parrot Foundation and all of our other mentoring organizations and the amazing students for making Google Code-in a huge success!

By Stephanie Taylor, Open Source Programs Office

Googler Eric Clayberg joins Eclipse Foundation Board

Google Software Engineering Manager Eric Clayberg has been elected by the Eclipse community as a Sustaining Member Representative on the Eclipse Foundation Board of Directors for the 2011-12 term. The announcement was made yesterday at the Annual General Meeting during the kick-off of EclipseCon 2011 in Santa Clara, CA. As a member of the Board of Directors, Eric will help oversee the policies and strategic direction of the Eclipse Foundation.

Eric works on the Google Plugin for Eclipse (GPE) team at Google and he was formerly with Instantiations, a company known for its focus on Eclipse Java developer tools, that was acquired by Google in 2010. Eric is also a Project Lead for the new open source WindowBuilder project at Eclipse.org. “I have been involved with Eclipse since 1999 and have always been a strong supporter of Eclipse community interests. I look forward to bringing Google scale thinking and inventiveness to my new role as board member.”

Google has been a longtime supporter of the the Eclipse Community. In addition to open sourcing Eclipse tools, Eclipse Labs is powered by Google Project Hosting and we have hosted Eclipse Days at the Googleplex in 2010, 2009, and 2008. Several Googlers will speak at EclipseCon sessions this year, including:

• WindowBuilder 101 and GWT App start to finish – Eric Clayberg
• GWT App start to finish and Building the Google Plugin for Eclipse: What We Learned – Rajeev Dayal, software engineer on the Google Web Toolkit (GWT) team.
• Android Development with Eclipse – Xavier Ducrohet, Tech lead for the Android SDK and developer tools, and Tor Norbye, software developer on the Android team
• Effective Git – Sean Pearce, lead on JGit project
• GWT App start to finish and Graphical Editing Framework (GEF) 101 – Dan Rubel, software engineer on the GWT team and formerly co-founder of Instantiations and Jaime Wren, Software Engineer on the GWT team

We hope to see you you at EclipseCon 2011!

Bruce Johnson and Chris Ramsdale, Google Developer Tools Team

Now Playing: the YouTube Symphony Orchestra Augmented Reality Experiment

The YouTube Symphony Orchestra is built on technology and innovation–musicians audition by uploading videos of themselves performing, and then YouTube viewers select who they want to participate in the live-streamed performance. Yesterday the YouTube Symphony Orchestra 2011 performed their Grand Finale Concert* from the Sydney Opera House, which was live-streamed around the world on YouTube.

Even though the performance is now over, the music and innovation continues! The 2011 YouTube Symphony Orchestra's Augmented Reality “Experiment” is an interactive way for fans to make some music of their own. By waving an easily made marker in front of a webcam, users can create and record music on a virtual instrument, then share their creations with friends. This virtual instrument was created as a collaboration between YouTube, Tellart, and Hyundai, and in the spirit of innovation, the software for the performance interface (the augmented reality application that actually makes the music) is now open source. You can now download the source and build an augmented reality instrument of your own. More details are available on the YTSO AR Instrument Project website.

By Ellen Ko, Open Source Team

*The performance was accompanied by sophisticated projections on the interior and the exterior on the iconic sails. A helicopter was used to laser map the sails in 3D to make it happen!

Mentoring Organizations for Google Summer of Code Announced

We are pleased to announce the list of mentoring organizations that have been accepted for this year’s Google Summer of Code program. After reviewing 417 applications, we have have narrowed the list to 175 open source projects, 50 of which are new to Google Summer of Code. You can visit our Google Summer of Code 2011 program website for a complete list of the accepted projects.

Students wishing to apply for Google Summer of Code will have the next 10 days to learn more about the accepted projects before student applications open on Monday, March 28, 2011 at 19:00 UTC.

Students will want to pay close attention to the Ideas Pages for the organizations they wish to work with over the summer and consider how they would like to contribute to the project. Some of the most successful proposals have been completely new ideas submitted by students, so if you don’t see a project that appeals to you, don’t be afraid to suggest something. Organizations have listed points of contact on their Ideas Page so students can contact the organization directly to submit a new proposal. All organizations list their preferred method of communication on the organization homepage which is available on the Google Summer of Code program website. Please see our Frequently Asked Questions page for more information.

Congratulations to all of our future mentoring organizations! We look forward to working with all of you during this exciting 7th year of Google Summer of Code!

By Stephanie Taylor, Open Source Programs Office

Geek Time with Junio C Hamano

Junio C Hamano is a software engineer in the Google Open Source Programs Office who works on the open source project Git. Git is an increasingly popular distributed version control system that is used by many open source projects including Android, Chrome OS, and the Linux kernel. Jun is the maintainer and one of the primary authors of Git, with 4426 commits!

Jeremy Allison, co-creator of Samba and fellow Open Source Programs Office team member, recently sat down with Jun for some quality Geek Time. Samba uses Git, so there was plenty to talk about! Here are some highlights:

• Jun and Jeremy discuss how Jun began working on open source after the maintainer of GNU’s source control system RCS, Paul Eggert, began mentoring him. (0:56)

• Jun explains why he prefers working within the open source software development model. (2:50)

• Jeremy asks Jun how he became interested and involved with Git. (3:27)

• When Jun first started working on Git, he had to balance his time between working on an open source project with a day job. Jun reveals his secret for making this balance work, and also how he eventually integrated Git into his day job. (7:00)

• Jun and Jeremy discuss the growing popularity of Git in comparison to older version control systems, and Jun gives an overview of some of Git’s features that set it apart. (9:28)

• Jeremy shares his one criticism of Git, which is that it’s hard to use. Jun responds and offers some suggestions for those who are new to Git. (12:48)

• Jun reveals some longer-term goals for Git as well as some new developments for future releases. (17:44)

• Jeremy asks Jun how he ended up at Google and they talk about Git’s growing role within Google. (19:24)

• Jun gives advice to developers who are new to open source and want to get involved. (21:50)

By Ellen Ko, Open Source Team

Googlers are Everywhere

This is a very busy week for Googlers talking about open source at conferences. In addition to having lots of Google employees headed to Atlanta for PyCon USA 2011, members of Google’s Open Source Programs Office will also be heading out to Chicago, IL and Dallas, TX for DrupalCon and SIGCSE, respectively.

Cat Allman will be at SIGCSE, where she will talk to attendees about open source in Google’s computer science education initiatives. On Friday March 11th, from 1:45 - 3:00 PM, Cat will present information about Google Summer of Code alongside Google colleagues who will also talk about App Inventor for Android, Computer Science 4 High School (CS4HS), and Computational Thinking. Directly after the talk, there will be a chance to meet with Cat and members of Google's education team from 3:45 - 5:00 PM, followed by a reception from 5:00 - 6:00 PM.

Carol Smith will be at DrupalCon to talk at a panel discussion titled, ”Paying for the Plumbing” today at 4:30 PM. During this talk, Carol will discuss how participation in a program like Google Summer of Code can provide financial support for open source projects.

If you’re at PyCon, DrupalCon, or SIGCSE this week, make sure to look out for us and say hello!

By Ellen Ko, Open Source Team

See you at PyCon 2011

As many of you may know, Python is one of the official languages here at Google. Guido van Rossum, the creator of Python, is a Googler too—so naturally we’re thrilled to be supporting PyCon 2011 USA, the largest annual gathering for the community using and developing the open-source Python programming language. The PyCon conference days will be March 11th to the 13th, preceded by two tutorial days, March 9th and 10th. For those of you with coding in mind, the Sprints run afterwards from March 14th-17th. All-in-all that’s nine days of Python nirvana!!

In addition to having many Googlers in attendance, some of us will be presenting as well.

• On Wednesday, March 9th at 2 PM, I will be leading a Google App Engine tutorial with fellow teammate Ikai Lan. Tutorials have gotten so popular at PyCon, they’ve now been expanded into a two-day affair!

• On Friday the 11th, the very first day of sessions, App Engine engineer Brett Slatkin will kick things off with his talk, “Creating Complex Data Pipelines in the Cloud” using the new App Engine Pipeline API at 10:25 AM.

• After lunch on Friday, I’ll take my Google hat off momentarily to discuss Python 3 in my talk subtitled “The Next Generation is Here Already” at 1:35 PM. It is mostly a repeat of the well-received talk I gave last year but with updates. The main point is to introduce folks to the next version of the language and discuss how its backwards-incompatibility will affect users, when users should port their apps to Python 3, what the differences from Python 2 are, etc. My job is to calm and soothe, dispelling any FUD (fear, uncertainty, doubt) about Python 3.

• On Saturday morning at 9:25 AM, Python creator, BDFL, and App Engine engineer Guido van Rossum will do his annual Q&A session for all conference attendees in a fireside chat session.

• Later Saturday morning at 11:05 AM, I’m looking forward to speaking about “Running Django Apps on Google App Engine.” This is exciting for me, not only because it’s a relatively new topic, but it represents a major change for Django developers: being able to write Django apps that run on NoSQL or non-relational databases -- it’s been only RDBMSs all this time. Furthermore, with Django-nonrel, you can move Django projects/apps between traditional hosting and App Engine, helping to break that “vendor lock-in” issue that many have had concerns about when hosting apps in the cloud. A good part of my talk does focus on porting apps from App Engine to Django however.

• Right after my talk, at 11:45 AM comes another famous Googler, author of Python in a Nutshell, co-editor of the Python Cookbook, and a long-time member of the Python community, Alex Martelli. Alex’s invited talk on “API Design anti-patterns” will be insightful and cerebral, sure to cause many future hallway discussions.

• Late Saturday afternoon at 4:15 PM, Google engineer Augie Fackler will deliver his talk entitled, “HTTP in Python: which library for what task?” There are many libraries that do HTTP. Which ones should you use and when? What are the benefits and tradeoffs?

• Finally, several members of the Google App Engine team, App Engine forum gurus, and experienced App Engine users are attending PyCon this year. I’m hoping to establish an OpenSpace session one of the conference evenings where we can meet other users, chat about best practices, and do some informal Q&A letting people ask anything they want (except “When will you support newer versions of Python?”). :-)

You can find the entire PyCon schedule online. It’s interactive if you log-in, allowing you to bookmark sessions you’re interested in attending. This will be PyCon’s biggest year yet, so hopefully you can join us in Atlanta next week! Keep an eye out on the PyCon blog to get the latest news, and be sure to follow the Twitter hashtag (#pycon).

We invite you to join Google team members at all our talks, plus stop by our booth to meet our technical staff as they demo select developer tools and APIs. We’ll have handouts there and also encourage you to try a short coding puzzle for a prize!

By Wesley Chun (@wescpy), Google Developer Relations team

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

Simian: Mac OS X package deployment via App Engine

Administration of software packages on the Mac platform can often be daunting. Google’s Mac Operations and Security teams evaluated several solutions for OS X package deployment, but unfortunately none of them met all of our required features. We decided to build our own solution to do the following:

• Deploy new or updated software by targeting a single Mac or tens of thousands.
• Push security patches, whether the Mac is on an internal network/VPN or not.
• Force mandatory installation of some packages, while allowing others to be optional.
• Tightly manage Apple-provided updates.
• Scale without deploying and maintaining additional server infrastructure.
• Obtain reports on all of this and the fleet overall.

Today we are open-sourcing Simian, our solution to enterprise-class Mac OS X package deployment. Simian uses App Engine-based hosting to scale with the needs of your growing enterprise, and a Munki-based client which will continue to evolve through the outstanding work of Greg Neagle and the Munki community. We hope this to be the first of many announcements in sharing Google's unique IT approach with the larger community.

For more information, please visit our Simian project page, join the discussion list, and download the code. For more information about Munki, please visit its project page.

By John Randolph and Justin McWilliams, Google Corporate Platforms Engineering Team

Google Summer of Code Announced at LCA

Despite the recent devastating floods in Australia, the open source community is converging on Brisbane this week for the annual linux.conf.au (LCA). The LCA team “encourages everyone to still come to Brisbane and support local business and the community - we need your support.” Monday during the introductory session at LCA, Carol Smith, member of the Google Open Source Programs Office, proudly announced Google Summer of Code 2011.

This will be the 7th year for Google Summer of Code, an innovative program dedicated to introducing students from colleges and universities around the world to open source software development. The program offers student developers stipends to write code for various open source projects with the help of mentoring organizations from all around the globe. Over the past 6 years Google Summer of Code has had 4,500 students from over 85 countries complete the program. We are excited to announce that we will extend the scope of the program this year by targeting a 25% increase in accepted student applications as well as accepting a larger number of mentoring organizations. Our goal is to help these students pursue academic challenges over the summer break while they create and release open source code for the benefit of all.

Spread the word to your friends! If you know of a university student that would be interested in working on open source projects this summer, or if you know of an organization that might want to mentor students to work on their open source projects, please direct them to our Google Summer of Code 2011 website where they can find our timeline along with the FAQs. And stay tuned for more details coming soon!

By Stephanie Taylor, Open Source Team

Googlers Down Under

Despite the recent flooding in Brisbane, Australia, linux.conf.au (lca) will proceed from January 24th to 29th, and Googlers from across the company will be there. LCA is a community-run technical conference for free and open source software enthusiasts, featuring but not limited to Linux. In addition to the many Googlers who will be attending, several Googlers will also be presenting at the conference.

The conference starts on Monday the 24th with a day of miniconfs, and Nóirín Shirley from Google’s Zurich office will be presenting “Open Source: Saving the World” as part of the Haecksen track.

Google’s Chief Internet Evangelist Vint Cerf will start the day on Tuesday the 25th with his keynote presentation, and later that morning he will present “In Search of Transmission Capacity - a Multicore Dilemma.” On Tuesday afternoon, Google Summer of Code Administrator Carol Smith will give a "Google Summer of Code Update" at the FOSS in Research and Student Innovation Miniconf.

On Wednesday January 26th, Google staff engineer and Linux kernel committer Ted Ts'o will explain “Making file systems scale: A case study using ext4.”

Andrew Gerrand and Nigel Tao of the Go team will give attendees “A Tour of Go” on Thursday the 27th, and Nóirín will present “Baby Steps into Open Source - Incubation and Mentoring at Apache,” which is based on her experience at the Apache Software Foundation.

On Friday the 28th, Carol will present her talk, “The 7 Habits of Highly Ineffective Project Managers” in the morning. A little later in the day, Daniel Bentley and Daniel Nadasi of the open source and Geo teams respectively will talk about “Opening a Closed World,” followed by Marc MERLIN, who works on infrastructure at Google. Marc will discuss “Saving Money with Misterhouse: Running Your Lights and HVAC System. Scaring your cat off the kitchen counter is just a bonus :)”

LCA always closes with Open Day, a free day-long event where the general public can learn about open source, open data - all things “open.” The Open Day is on Saturday the 29th, and Cat Allman of the Open Source Programs Office will be presenting her talk, “What is Open Source?” there.

Come learn more about the latest happenings in open source, and join us in showing support for Brisbane’s recovery. We hope to see you there!

By Ellen Ko, Open Source Team

Make quick fixes quicker on Google Project Hosting

Have you ever noticed a bug or typo in your code but not been in a position to fix it? Perhaps you were browsing the code online from your Cr-48, or perhaps you just didn’t have Subversion or Mercurial handy. Today the Google Project Hosting team is announcing a new feature for you: the ability to edit your source code files directly in the browser, in our online editor powered by CodeMirror. Just look for the “edit file” link on files in the online source browser:

As you edit, you can preview the diff of your changes, so you know exactly what you are committing:
And if you don’t have commit privileges to the project? No problem. Instead of committing your changes, you can file your changes as a patch in the project’s issue tracker.

By lowering the barrier to entry for everyone — project members and users alike — we hope to make it easier for projects to grow and improve. Enjoy!

By Jacob Lee, Google Project Hosting Team

OSUOSL’s Code-in results are in!

The Oregon State University Open Source Lab (OSL) participated for the first time in the Google Code-in contest, and we're pleased to report that the results of the contest were incredibly valuable for us. We had eight students actively working with us during the contest, from as far afield as Australia and Poland. Of these eight students, two have let us know they plan to keep working on projects with the OSL and one even let us know that he's hoping to attend Oregon State University so he can learn even more about open source and help out at the lab.

We had a total of 42 tasks completed, all improvements to Ganeti Web Manager, a homegrown project of the OSL. For those who aren't familiar with the project, it's a Django based web application that helps administrators better manage their Ganeti-based clusters. Our students completed a total of 42 tasks: 23 coding tasks, 18 user interface tasks, and one outreach task (logo design). We were especially excited that our students found several unknown bugs in our code base and proceeded to send us fixes for them. You can take a look at all of the tasks proposed by the Lab and all those completed by our students on the contest website.

As a result of participating in Google Code-in, several major features were implemented in Ganeti Web Manager, including:

•HTML5 VNC Support
•Creating a Status Dashboard for Administrators and Users
•Creating an Object Change Log

Of all these major features, creating the status dashboard was the most difficult of our tasks. We required a very concise layout for the feature and the student working on the task was not a native English speaker, but he did an outstanding job. In fact, if you'd like to get to know the student who worked on the dashboard, we've already published an interview with Piotr for your reading pleasure.

Overall, we were incredibly excited to be a part of Google Code-in and extremely pleased with our results. We certainly hope to continue mentoring for the contest, assuming Google chooses to run it once again. Many thanks to all of our students for their great work and many thanks to Google for doing awesome work to promote student involvement in open source! A full post about the OSL’s experience with Google Code-in is available on the OSL blog.

By Leslie Hawthorn, OSUOSL Open Source Outreach Manager

Chrome enables open innovation

Earlier this week, Google announced that Chrome’s HTML5 <video> support will change to match codecs supported by the open source Chromium project. Chrome will support the WebM (VP8) and Theora video codecs, and support for the H.264 codec will be removed so that resources can be directed completely towards open codec technologies. This is in line with Google’s continued support of the open web.

For more information, check out the original post.

By Ellen Ko, Open Source Team

Google Code-in Wrapup

This was a great year for Google Code-In. We had a total of 361 students complete at least one task during our contest period. We are still compiling the statistics on our participants and plan to post a follow-up once we are done reviewing tasks soon. We are quite proud of the participation in the contest this year and hope many of our student participants will go on to continue contributing to the organizations for which they completed tasks.

Grand prize winners will be announced on February 14. Stay tuned to this blog for the announcement!

Thank you to all our organization administrations, mentors, and students for your participation this year!

By Carol Smith, Open Source Team