Tag Archives: student programs

Google Summer of Code 2016 wrap-up: Oppia

Google Summer of Code (GSoC) is an annual program that encourages university students to become open source contributors. This guest post is part of a series of blog posts from the open source projects and organizations that participated in GSoC 2016.

The Oppia project makes it easy for anyone to create lightweight, interactive online lessons that simulate personal tutoring. These activities, called “explorations,” can be shared with others around the world as standalone tutorials (such as Programming with Carla and Quadratic Equations), or embedded in websites to supplement an existing course (such as “Take Your Medicine” on edX and Computational Thinking for Educators).

2016 was Oppia’s first year participating in GSoC and it was a blast! More students flocked to our ideas page than we had expected, and our Gitter channel was full of people saying hello and looking for starter projects. Over the course of the summer, with the help of two capable and enthusiastic students, we were able to bring the following new features to the Oppia codebase:

A new creator dashboard -- Avijit Gupta


An important principle of Oppia is that lessons can be easily improved over time -- it’s hard to figure out all the possible ways a student can go wrong at the outset, but it’s much easier to respond appropriately to a new misconception that arises.

Each creator on Oppia has a “creator dashboard” which allows them to see the lessons they’ve created, as well as the feedback they’ve received from learners. Avijit completed a full revamp of this page, updating its design (for both desktop and mobile) and finding ways to display all the necessary information in an intuitive way so that creators can easily improve their lessons while getting feedback on their teaching.

The new creator dashboard.

In addition, Avijit added functionality allowing creators to view student misconceptions that were not well-addressed, to make it easier for them to improve the feedback for those answers. He has continued to help out with the Oppia open source project as a maintainer and reviewer, even after GSoC, and is mentoring other contributors who are working on further improvements to the creator dashboard. You can read more about the project in his GSoC writeup!

Speed improvements -- Vishal Gupta


In order to improve the accessibility of lessons for students with poor internet connectivity, Vishal’s project aimed to make Oppia speedier and less bandwidth-intensive. He started by implementing a performance testing framework to benchmark his efforts, and also integrated it with our continuous integration system in order to protect against performance regressions. He then turned his efforts to caching as many static resources as possible, implementing a cache slug system that causes new files to be downloaded only after a new release is made.

In addition, Vishal removed JavaScript code that was inlined in the main templates, and refactored it out into an external script which could then be cached for better performance. You can read more about this project in his post on the Oppia blog.

We’d like to extend our grateful thanks not only to Avijit and Vishal, but also to our many willing and enthusiastic mentors, and to Google for supporting our open source work with GSoC.

Join us in helping improve educational opportunities for students around the world. If you’d like to subscribe to news and updates about Oppia’s participation in GSoC, you can sign up to the oppia-gsoc-announce mailing list -- or, if you’re already feeling enthusiastic, you can start helping out with the project right away!

By Ben Henning and Sean Lip, Organization Administrators for Oppia

Rails Girls Summer of Code: Changing the face of tech

This is a guest post from Laura Gaetano who organizes Rails Girls Summer of Code, a global fellowship program inspired by Google Summer of Code.

Have you seen that picture of Margaret Hamilton, the NASA engineer who worked on the computer systems for the Apollo 11 launch? She’s standing next to the human-sized pile of listings of the Apollo Guidance Computer source code that she worked on. Do you know about Ada Lovelace, often cited as the very first computer programmer?

From World War II until the 1980s, women engineers and women computer operators were fairly common. There was a steady rise in women entering STEM fields, and young girls had role models and strong women to look up to. We're well acquainted with the drop in female engineering graduates worldwide after this time period, and the subsequent drop in the percentage of women entering the world of tech. We're here to help change that, and reverse the trend.

Rails Girls Summer of Code (RGSoC) aims to bring more diversity into the world of tech — specifically, into the world of open source software, where women make up a mere 11% of the community. The global program offers 3-month scholarships to teams of women to allow them to work full-time on an open source project of their choice – aided by local coaches and guided by the project maintainer (or a core contributor). The scholarships are funded through the support of the community as well as our sponsors, via a crowdfunding campaign.

Local vs. Global
We all cherish our local community and understand how strong of a support network it can be, especially for newcomers. The Rails Girls chapters worldwide emphasize that need: most coaches and organisers are local, and many alums go on to create their own study groups, or become coaches or organisers themselves. RGSoC also relies strongly on a global network of user groups — both Rails Girls chapters and similar organisations such as PyLadies or DjangoGirls.

Thanks to our connections with these different groups, we are able to reach people in remote or unlikely locations, and build the most diverse group of applicants possible. This is very important to us. Since the beginning, the program has provided the opportunity to bring together women with different experiences, backgrounds, locales and age groups to come together and be part of the same global initiative.

Our Structure
This year, we received over 90 team applications. When applying, each two-person team chooses from a list of pre-selected projects. These projects are maintained by people we either personally know, or who have reached out to us prior to the application period. We look for projects with patient, open-minded contributors who are active in their community, and projects that provide a lot of learning opportunities for applicants.

Project maintainers (also called mentors) are in touch with students in order to adapt the roadmap throughout the summer to the students' needs and check up on their progress. On a daily basis, students spend the majority of their time with coaches. The coaches help, support, and teach the students throughout the summer. Each team is also appointed a supervisor, who supports students on the organisational side of things. They are the glue that keeps the whole team together, and a way for the core RGSoC team to keep track of how every team is doing.

Our Stats
Our program started in 2013 with 18 teams, 10 of which were sponsored and 8 of which were volunteer teams. The following year, 16 teams participated with 10 sponsored spots. The real breakthrough came in 2015 when we were able to fund 16 sponsored teams, a substantial increase from the previous years. Not only did this enable us to have more impact — with a potential 12 more women entering the tech world and STEM workforce than the previous years — but it also shows the community’s trust in the program.

In 2016, the Ruby community awarded us with a Ruby Hero Award, and we managed to collect enough money to sponsor 16 teams from five continents with another 4 teams joining as volunteers. This year was also the first time we had teams based in Uganda, Egypt, Singapore and the Czech Republic.
Our stats from 2016 (Image: Laura Gaetano/RGSoC)
Last year, we contacted our alums from 2013 and 2014 to find out what they were doing after the program. The responses were impressive: out of 64 graduates, over 90% are now currently working in the tech field. A fair number of graduates have even founded their own startup. Not only that some of these women have found their calling, but we might have made a small difference in the community of open source, and are on the right track to really shake things up.

Where do we go from here
On the first of July, we kicked off our program with over 130 people participating — including coaches, supervisors, designers, helpdesk coaches and project mentors. We were incredibly excited to have 20 teams in 16 cities and 11 different countries, spanning time zones, from UTC+10 to UTC-7.
Our 2016 sponsored and volunteer teams! (Image: Ana Sofia Pinho/RGSoC)
We’ve seen in the past just how much of an impact we’ve had in our participants’ lives, and are hoping that this trend will continue to rise. We hope that some of this year’s teams graduated with the skills and confidence to become NASA engineers, web developers, or anything else they want to be. Hopefully someday they will become a young woman’s role model, and realise the important role they served in changing the future of engineering and of open source software.


By Laura Gaetano, Organizer of Rails Girls Summer of Code

Taking the pulse of Google Code-in 2016

GCI official horizontal_1372x448dp.png

Today is the official midpoint of this year’s Google Code-in contest and we are delighted to announce this is our most popular year ever! 930 teenagers from 60 countries have completed 3,503 tasks with 17 open source organizations. The number of students successfully completing tasks has almost met the total number of students from the 2015 contest already.

Tasks that the students have completed include:
  • writing test suites
  • improving mobile UI 
  • writing documentation and creating videos to help new users 
  • working on internationalization efforts
  • fixing and finding bugs in the organization's’ software 
Participants from all over the world
In total, over 2,800 students from 87 countries have registered for the contest and we look forward to seeing great work from these (and more!) students over the next few weeks. 2016 has also seen a huge increase in student participation in places such as Indonesia, Vietnam and the Philippines.

Google Code-in participants by country

Please welcome two new countries to the GCI family: Mauritius and Moldova! Mauritius made a very strong debut to the contest and currently has 13 registered students who have completed 31 tasks.

The top five countries with the most completed tasks are:
  1. India: 982
  2. United States: 801
  3. Singapore: 202
  4. Vietnam: 119
  5. Canada: 117
Students, there is still plenty of time to get started with Google Code-in. New tasks are being added daily to the contest site — there are over 1,500 tasks available for students to choose from right now! If you don’t see something that interests you today, check back again every couple of days for new tasks.

The last day to register for the contest and claim a task is Friday, January 13, 2017 with all work being due on Monday, January 16, 2017 at 9:00 am PT.

Good luck to all of the students participating this year in Google Code-in!

By Stephanie Taylor, Google Code-in Program Manager

All numbers reported as of 8:00 PM Pacific Time, December 22, 2016.

Google Summer of Code 2016 wrap-up: Public Lab

This post is part of our series of guest posts from students, mentors and organization administrators who participated in Google Summer of Code 2016.


How we made this our best Google Summer of Code ever

This was our fourth year doing Google Summer of Code (GSoC), and it was our best year ever by a wide margin! We had five hard-working students who contributed over 17,000 new lines of (very useful) code to our high-priority projects.

Students voluntarily started coding early and hit the ground running, with full development environments and a working knowledge of GitHub Flow-style pull request process. They communicated with one another and provided peer support. They wrote tests. Hundreds of them! They blogged about their work as they went, and chatted with other community members about how to design features.

All of that was amazing, and it was made better by the fact that we were accepting pull requests with new code twice weekly. Tuesdays and Fridays, I went through new submissions, provided feedback, and pulled new code into our master branch, usually publishing it to our production site once a week.

I don't know how other projects do things, but this was very new for us, and it's revolutionized how we work together. In past years, students would work on their forks, slowly building up features. Then in a mad dash at the end, we’d try to merge them into trunk, with lots of conflicts and many hours (weeks!) of work on the part of project maintainers.

Screenshot_2016-08-26_at_11.44.16_AM.png
What made this year so good?

Many things aligned to make this summer great, and basically none of them are our ideas. I'm sure plenty of you are cringing at how we used to do things, but I also don't think that it's that unusual for projects not "born" in the fast-paced world of modern code collaboration.

We used ideas and learned from Nicolas Bevacqua, author of JavaScript Application Design and of the woofmark and horsey libraries which I've contributed to. We've also learned a great deal from the Hoodie community, particularly Gregor Martynus, who we ran into at a BostonJS meetup. Lastly, we learned from SpinachCon, organized by Shauna Gordon McKeon and Deb Nicholson, where people refine their install process by actually going through the process while sitting next to each other.

Broadly, our strategies were:

  • Good documentation for newcomers (duh)
  • Short and sweet install process that you've tried yourself (thanks, SpinachCon!)
  • Predictable, regular merge schedule
  • Thorough test suite, and requiring tests with each pull request
  • Modularity, insisting that projects be broken into small, independently testable parts and merged as they’re written

Installation and pull requests

Most of the above sound kind of obvious or trivial, but we saw a lot of changes when we put it all together. Having a really fast install process, and guidance on getting it running in a completely consistent environment like the virtualized Cloud9 service, meant that many students were able to get the code running the same day they found the project. We aimed for an install time of 15 minutes max, and supplied a video of this for one of our codebases.

We also asked students to make a small change (even just add a space to a file) and walk through the GitHub Flow pull request (PR) submission process. We had clear step-by-step guidance for this, and we took it as a good sign when students were able to read through it and do this.

Importantly, we really tried to make each step welcoming, not demanding or dismissive, of folks who weren’t familiar with this process. This ultimately meant that all five students already knew the PR process when they began coding.

Twice-weekly merge schedule

We were concerned that, in past years, students only tried merging a few times and typically towards the end of the summer. This meant really big conflicts (with each other, often) and frustration.

This year we decided that, even though we’re a tiny organization with just one staff coder, we’d try merging on Tuesday and Friday mornings, and we mostly succeeded. Any code that wasn’t clearly presented, commits squashed, passing tests, and submitting new tests, was reviewed and I left friendly comments and requests so it could be merged the following week.

At first I felt bad rejecting PRs, but we had such great students that they got used to the strictness. They got really good at separating out features, demonstrating their features through clear tests, and some began submitting more than two PRs per week - always rebasing on top of the latest master to ensure a linear commit history. Sweet!

Wrap-up and next steps

The last thing we did was to ask each student, essentially as their documentation, to write a series of new issues which clearly described the problem and/or desired behavior, leave suggestions and links to specific lines of code or example code, and mark them with the special “help-wanted” tag which was so helpful to them when they first started out. We asked each to also make one extra-welcoming “first-timers-only” issue which walks a new contributor through every step of making a commit and even provides suggested code to be inserted.

This final requirement was key. While I personally made each of the initial set of “help-wanted” and “first-timers-only” issues before GSoC, now five students were offloading their unfinished to-dos as very readable and inviting issues for others. The effect was immediate, in part because these special tags are syndicated on some sites. Newcomers began picking them up within hours and our students were very helpful in guiding them through their first contributions to open source.

I want to thank everyone who made this past summer so great, from our champion mentors and community members, to our stellar students, to all our inspirations in this new process, to the dozen or so new contributors we’ve attracted since the end of August.

By Jeff Warren, Organization Administrator for PublicLab.org

Google Summer of Code 2016 wrap-up: CSE@TU Wien

Every year over a thousand university students work with more than a hundred open source organizations as part of the Google Summer of Code (GSoC). This post is part of a series of guest posts from students, mentors and organization administrators reflecting on GSoC 2016.

CSE@TU Wien is a loose interest group at the Technische Universität Wien (TU Wien) focused on developing, providing and utilizing free and open source software for research. We’re an umbrella organization for several open source projects and we participate in Google Summer of Code (GSoC) to ensure that future generations continue building open source software for scientific computing.

We’ve participated in GSoC most years since 2011, and in 2016 we had ten successful projects. The thematic areas are -- befitting an engineering-focused university -- very diverse. Let’s take a look at the projects and what students accomplished:

Carbon Footprint for Google Maps is a browser extension that calculates CO2 emissions that users would incur by driving on routes suggested by popular mapping services and displays this information alongside time and distance. The aim is to raise awareness of the environmental impact of driving cars.

Kolya Opahle brilliantly re-factored the extension, making it much more modular. This enabled expansion to include other map services and port to other browsers, with browser-specific implementations reduced to a minimum. Building for specific browsers was made easy through a Gradle build script. He took on the Firefox port himself, which turned out to be more challenging than expected due to incompatibilities between the extension API’s of Firefox and Chrome. Overcoming this challenge required ingenuity. 

Prateek Gupta completely re-designed and reimplemented the extension’s user interface, optimizing the storage of user options and allowing localization. He added support for more mapping services and calculations of additional greenhouse gases. He added new features to give the user more information about greenhouse gas emissions, including: 
  • a page with air quality index using an API from the World Air Quality Index
  • a page with tips to reduce emissions; a calculator to compute CO2 absorption by trees
  • another calculator for the benefits of walking and cycling instead of driving
Chirag Arora ported the extension to the Safari web browser. Like the port to Firefox, this proved challenging due to discrepancies between the Chrome and Safari extension API’s. Chirag also implemented several new features, including: 
  • more unit systems in the options page
  • automatic configuration of fuel price based on location and the Global Petrol Prices API
  • approximate calculation of CO2 emissions for public transportation
The Colibri project focuses on smart building energy management. Intelligent control strategies are becoming more and more important for efficiently operating residential and commercial buildings, as buildings are responsible for a significant amount of global energy consumption.

Georg Faustmann implemented a connector for Open Automated Demand Response (OpenADR) networks. OpenADR information and signals can now be processed and stored in the Colibri data store. One challenge for this student was comprehensive handling of the OpenADR specification. Based on the specification, Georg identified a set of relevant use cases which were finally realized in this Colibri component.

Josef Wechselauer worked on a connector for gateways based on the OASIS Open Building Information Exchange (OBIX) standard. This connector links physical devices and data from building automation systems to Colibri. Josef was very enthusiastic and he implemented the connector with an additional graphical user interface for browsing through available OBIX objects. The system test with real hardware was challenging, but he solved all of the problems.

Pratyush Talreja implemented a connector that enables the integration of MATLAB Simulink simulations. More precisely, the connector links to the MATLAB environment and can read and write data over interfaces provided by the simulation. Pratyush had some initial troubles with the system design and the role of the connector in the overall system. However, he tackled those challenges and succeeded in the end.

Mind the Word is a browser extension that helps users learn a new language. It randomly translates a few words per sentence on websites as the user browsers. Since the user sees the translated words in context, they can infer its meaning and thus gradually learns new vocabulary with minimal effort. The extension uses Google, Microsoft and Yandex translation APIs.

Ankit Muchhala re-factored and modernized the code base to ES6 using JSPM, fixing critical bugs in the process and setting up a test environment in Karma and Jasmine. After that, he redesigned the user interface, making extensive use of Bootstrap 3 along with AngularJS. He also implemented various features to make the extension more usable, such as: 
  • dispersed word translation
  • (automatic) blacklisting and easy whitelisting of words and websites
  • and the ability to backup and restore the user's configurations
Rohan Katyal ported the extension to Firefox and implemented several new features, including: 
  • speech of translated words
  • generation of quizzes with the translated words
  • search for visual hints, similar words and usage examples, and more. 
R/sdcMicro is the state-of-the-art R package for data anonymization and is used by national and international institutions. Data privacy has become a hot topic in research and requires serious effort to ensure that individuals cannot be identified.

Probhonjon Baruah improved the code quality of sdcMicro. He wrote unit tests that should help other contributors keep the package consistent and free of bugs. The main challenge for the student was understanding the object-oriented implementation of sdcMicro that goes beyond typical R packages. The student learned that standardized tests are too general to be useful, and that more problem-oriented and specific tests are more effective.

Classilist is an open source visualization dashboard for probabilistic classification data.

Medha Katehara of LNMIIT India developed Classilist, an interactive system for visualizing the performance of probabilistic classifiers. Additionally, she developed plugins to pull classification data from machine learning frameworks such as RapidMiner, WEKA and R.

In conclusion, we are -- again -- very happy with Google Summer of Code. Students advanced themselves and our research software, a clear win-win. Our large team of experienced mentors performed well and we’re grateful for their continued dedication and the support of our university. We hope to participate again in 2017!

By Josef Weinbub and Florian Rudolf, Organization Administrators for TU Wien, Austria

Google Summer of Code 2016 wrap-up: AOSSIE

We’re sharing guest posts from students, mentors and organization administrators who participated in Google Summer of Code (GSoC) 2016. This is the seventh post in the series.


AOSSIE (Australian Open Source Software Innovation and Education) is an organization created by the leaders of four research-oriented open source projects at the Australian National University. This was our first year in Google Summer of Code, but one of our projects had already participated three times as part of another organization.

We had 6 students and they surpassed our expectations. It was a great experience to mentor these students and provide them the opportunity to get involved in our cutting-edge research. We expect that their projects will lead to several publications and will be the starting point for long term collaborations.

Here are some highlights of their contributions:

Extempore is a programming language and runtime environment that supports live programming.

Joseph Penington adapted some cpp fluid dynamics code to show how live programming could be used to improve the workflow of scientific simulation. Joseph's project builds a series of increasingly complex fluid solvers in Extempore, allowing the programmer to make interesting and non-trivial changes to the simulation at runtime, including switching the way the fluids are solved in the middle of a simulation.

PriMedLink is software for matching similar patients in a way that preserves privacy (i.e. only using masked or encoded values of records without compromising privacy and confidentiality of patients) for health informatics applications such as clinical trials, advanced treatments and personalized patient care. The initial version of PPSPM software included masking and matching techniques for string, categorical and numerical (integer, floating point and modulus) data.

Mathu Mounasamy developed a module for PPSPM for masking and matching textual data which commonly occur in patient records (such as clinical notes and medical reports containing text data). The TextMM module developed by Mathu extends the functionality of PPSPM by allowing advanced privacy-preserving matching of similar patients based on various features containing textual data, thereby improving the quality and scope of PPSPM.

Rogas is a platform which integrates a collection of graph analysis tools and algorithms into a unified framework in order to support network analysis tasks.

Mojtaba Rezvani added the local community search (also known as local community detection) capability to Rogas. He has implemented several state-of-the-art algorithms proposed for local community detection, such as: k-core, k-truss, k-edge-connected, γ-quasi, and k-cliques. He has also designed a new algorithm for local community detection, which can efficiently identify local communities in large-scale networks.

Yan Xiao redesigned the GUI of Rogas in order to improve usability. He also implemented several visualization techniques to support the graph primitives of Rogas, including cluster, rank and path finding. These developments support dynamic network analysis at different scales so as to predict trends and patterns.

Skeptik is a Scala-based framework for proof theory and automated reasoning.

Ezequiel Postan generalized a challenging proof compression algorithm (the Split algorithm) from propositional logic to first-order logic and implemented it. This enables Skeptik to execute this algorithm not only on proofs output by SAT- and SMT-solvers but also on proofs output by resolution-based automated theorem provers. Ezequiel also implemented parsers for the TPTP and TSTP formats for theorem proving problems and proofs, and implemented a random proof generator to allow comprehensive experimental evaluation of the algorithms.

Daniyar Itegulov implemented a theorem prover for classical first-order logic using Skeptik's data structures and based on a novel logical calculus recently proposed by his mentor. This new calculus, called Conflict Resolution, is inspired by the propositional conflict-driven clause learning procedure used by SAT- and SMT-solvers and generalizes it to first-order logic. Daniyar also went further, conceiving and developing a concurrent proof search strategy for this calculus using Akka actors.

By Bruno Paleo, Organization Administrator for AOSSIE

Google Summer of Code 2016 wrap-up: STE||AR

This is part of a series of guest posts from students, mentors and organization administrators who participated in Google Summer of Code (GSoC) 2016. GSoC is an annual program which pairs university students with mentors to work on open source software.


This summer the STE||AR Group was proud to mentor four students through Google Summer of Code. These students worked on a variety of projects which helped improve our software, HPX. This library is a distributed C++ runtime system which supports a standards compliant API and helps users scale their applications across thousands of machines.

The improvements to the code base will help our team and users of HPX around the world. A summary of our students’ projects:

Parsa Amini – HPX Debugger

Developing a better distributed debugging tool is essential to increase the programmability of HPX. Parsa’s project, Scimitar, aims to facilitate the debugging process for HPX programmers by extending the features of GDB, an existing debugger. The project then complements it with new commands for easier switching between localities across clusters, HPX thread debugging, awareness of internal HPX data structures, and semi-automated preparation for distributed debugging sessions. Additional functionality such as locating an object and viewing the queue information on each core is provided through using API provided by HPX itself. His work can be found on GitHub.

Aalekh Nigam – Implement a Map/Reduce Framework

This project aimed to expose a Map/Reduce programming model over HPX. During the summer, Aalekh was able to develop a single node implementation of HPXflow (map/reduce programming model) and laid the groundwork for the further multi-node version with database support. Although the initial task was limited to implementing the Map/Reduce model, he was also able to implement an improved dataflow model as well.

Minh-Khanh Do - Working on Parallel Algorithms for HPX::Vector

Minh-Khanh’s task was to take the parallel algorithms and add the functionality required to work on the segmented hpx::vector. Under his mentor John Biddscombe, he implemented the segmented_fill algorithm, which was successfully merged into the main codebase. Additionally, Minh-Khanh implemented the segmented_scan algorithm which includes inclusive and exclusive_scan. These changes are included in a pull request and have been merged. Using the segmented scan algorithm it is possible to perform tasks such as evaluating polynomials and to implement other algorithms such as quicksort.

Satyaki Upadhyay - Plugin Mechanism for thread schedulers in HPX

In HPX, schedulers are statically linked and must be built at compile-time. Satyaki’s project involved converting this statically linked scheme into a plugin system which would allow arbitrary schedulers to be dynamically loaded. These changes bring several benefits. They provide a layer of abstraction and follow the open/closed principle of software design as well as allowing developers to write their own custom schedulers while conforming to a uniform API. The project proceeded in two steps. The first involved the creation of plugin modules of the schedulers and registering them with HPX. The second step was to implement the loading and subsequent use of the chosen scheduler.

We would like to thank our students and mentors for the time that they have contributed to HPX this summer. In addition, we would like to thank Google for the opportunity that they provided the STE||AR Group to work with developers around the globe as well as the ability for students to interact with vibrant open source projects worldwide.

By Adrian Serio, Organization Administrator for The STE||AR Group

It’s that time again: Google Code-in starts today!

Today marks the start of the 7th year of Google Code-in (GCI), our pre-university contest introducing students to open source development. GCI takes place entirely online and is open to students between the ages of 13 and 17 around the globe.
The concept is simple: complete bite-sized tasks (at your own pace) created by 17 participating open source organizations on topic areas you find interesting:

  • Coding
  • Documentation/Training
  • Outreach/Research
  • Quality Assurance
  • User Interface

Tasks take an average of 3-5 hours to complete and include the guidance of a mentor to help along the way. Complete one task? Get a digital certificate. Three tasks? Get a sweet Google t-shirt. Finalists get a hoodie. Grand Prize winners get a trip to Google headquarters in California.

Over the last 6 years, 3213 students from 99 countries have successfully completed tasks in GCI. Intrigued? Learn more about GCI by checking out our rules and FAQs. And please visit our contest site and read the Getting Started Guide.

Teachers, if you are interested in getting your students involved in Google Code-in you can find resources here to help you get started.

By Mary Radomile, Open Source Programs Office

Stories from Google Code-in: Sugar Labs and Systers

Google Code-in (GCI) is our annual contest that gives students age 13 to 17 experience in computer science through contributions to open source projects. This blog post is the final installment in our series reflecting on the experiences of Google Code-in 2015 grand prize winners. Be sure to check out the first three posts.

The Google Code-in contest begins on Monday, November 28th at 9am PT for students. Right now you can learn more about the 17 mentoring organizations that students will be able to work with by going to the contest site. To get students excited for GCI 2016, we’re sharing three more stories from GCI 2015 grand prize winners. These stories illustrate how global the competition is, the challenges students face and the valuable skills they learn working with these open source organizations.

IMG_20160614_152138.jpg
A group of Google Code-in 2015 mentors joined grand prize winners for a day of exploring
San Francisco including the iconic Golden Gate Bridge.
First up is the story of Ezequiel Pereira, a student from Uruguay who worked with Sugar Labs. Sugar Labs is the organization behind Sugar, the operating system for the OLPC XO-1 which the Uruguayan government has distributed to public primary schools. The XO-1 was Ezequiel’s first computer.

Ezequiel’s curiosity in computer science was piqued when a technician came to his school to solve a simple bug that was affecting most XO’s. The technician used the command line which, up to that point, Ezequiel thought was useless. Realizing that the command line offered him a lot of power, Ezequiel began his exploration.

He discovered Google Code-in by reading about another Uruguayan teenager, one who was a grand prize winner in Google Code-in 2012. Ezequiel jumped into the contest and participated for several years expanding his skills before finishing as a grand prize winner of Google Code-in 2015. Along the way Ezequiel got comfortable with IRC and began helping other students, even finding new friends among along the way.


Next we have Sara Du from the United States. Sara had been coding for six months when she discovered Google Code-in on Christmas Eve, halfway through the competition. She found lots of interesting tasks, but had trouble finding the right organization to focus on before selecting Systers.

Like many students, Sara was able to quickly jump into code but spent a couple days just getting acquainted with Git and GitHub. This is something we hear from a lot of students and it’s just one of the skills that they pick up by working on real-world projects, along with testing and communication.

Another challenge Sara faced was working with a mentor 16 time zones away from her, which meant that correspondence would often take a day or two. While this was a challenge, she found the long feedback loop encouraged her to get on the Slack channel and reach out to other contributors for help. Ultimately, this made her even more a part of the Systers community.

Sara said Google Code-in was one of the most awesome experiences she’s had and has this advice to offer future participants: “The organization you end up working with has a vibrant community of hackers from everywhere; try to interact with them and you will be sure to learn from others as they will from you!”


Last, but certainly not least, we have Ahmed Sabie, a student from Canada who also worked with Systers. Ahmed started coding competitively several years ago, focusing on graph theory, dynamic programming and data structures. He loved the problem solving, but knew that these competitions took place in a sandbox. To grow, Ahmed would need to explore.

Enter Google Code-in. Ahmed was most comfortable with Python and saw that the Systers Volunteer Management System used that language, so that’s where he started.

Ahmed, like many students and even professional developers, spent much of his first week setting up his development environment. It was a grueling process but with the help of search and the people in the Systers Slack channel he was finally able to see the project’s login screen.

As he completed easy tasks, Ahmed moved on to more difficult tasks and began to help other students, many who got stuck on the same issues he had encountered earlier. Ahmed found that each task provided an opportunity to stretch his skills a little bit more. He was excited about how quickly he was learning. Though Ahmed learned a lot on his own, he says the vast majority of what he learned was through the help of other people -- students, mentors and other project contributors -- and that he felt like he was truly a part of the Systers community by the end of the process. 

Ahmed’s favorite task was an appropriate finale for the competition: he added multilingual support to an application he had worked on and added the French translation.
“Overall, Google Code-in was the experience of a lifetime. It set me up for the future, by teaching me relevant and critical skills necessary in software development. I have contributed to a good cause, and met fantastic mentors and friends along the way. Open source development is not a onetime thing, it is an ongoing process. I hope to continue to be part of it, and to me it is a form of volunteering and giving back to the community.” - Ahmed Sabie

With that, we conclude our series of posts reflecting on Google Code-in 2015. We thank Ezequiel, Sara, Ahmed and all the other participants for sharing their stories and contributing to the software we all rely on. We hope you will join us in carrying on the tradition with Google Code-in 2016!

By Josh Simmons, Open Source Programs Office

Google Summer of Code 2016 wrap-up: Linux XIA

We're sharing guest posts from students, mentors and organization administrators who participated in Google Summer of Code 2016. This is the fifth post in that series and there are more on the way.


Linux XIA is the native implementation of XIA, a meta network architecture that supports evolution of all of its components, which we call “principals,” and promotes interoperability between these principals. It is the second year that our organization, Boston University / XIA, has participated in Google Summer of Code (GSoC), and this year we received 31 proposals from 8 countries.

Our ideas list this year focused on upgrading key forwarding data structures to their best known versions. Our group chose the most deserving students for each of the following projects:

Accelerating the forwarding speed of the LPM principal with poptrie

Student André Ferreira Eleuterio and mentor Cody Doucette implemented the first version of the LPM principal in Linux XIA for GSoC 2015. The LPM principal enables Linux XIA to leverage routing tables derived from BGP, OSPF, IS-IS and any other IP routing protocol to forward XIA packets natively, that is, without encapsulation in IP. For GSoC 2016, student Vaibhav Raj Gupta from India partnered with mentor Cody Doucette to speed up the LPM principal by employing a state-of-the-art data structure to find the longest prefix matching using general purpose processors: poptrie.

Upgrading the FIB hash table of principals to the relativistic hash table

Principals that rely on routing flat names have used a resizable hash table that supports lockless readers since 2011. While this data structure was unique in 2011, in the same year, relativistic hash tables were published. The appeal to upgrade to relativistic hash tables was twofold: reduced memory footprint per hashed element, and the fact they were implemented in the Linux kernel in 2014. Student Sachin Paryani, also from India, worked with mentor Qiaobin Fu to replace our resizable hash table with the relativistic hash table.

Google Summer of Code nurtures a brighter future. Thanks to GSoC, our project has received important code contributions, and our community has been enlarged. It was rewarding to learn that two of our GSoC students have decided to pursue graduate school after their GSoC experience with us: Pranav Goswami (2015) and Sachin Paryani (2016). We hope these examples will motivate other students to do their best because the world is what we make of it.

By Michel Machado, Boston University / XIA organization administrator