The Google Summer of Code Reunion

Google Summer of Code (GSoC) 2014 is over and the 2015 edition has been announced. A record number of 1307 students from 73 countries participated in 2014, working on 190 open-source projects. One of the traditions of Google Summer of Code is to host a Mentor Summit in the fall, which is an unconference that two mentors from each organization participating in GSoC can attend.

In celebration of the 10th year of Google Summer of Code, Google held a GSoC Reunion. Breaking tradition with the Mentor Summit, the GSoC Reunion was open not just to mentors, but also to students. Google allowed each of the 190 projects that participated in this year's GSoC to send two delegates. Additionally, Google held a lottery for additional places, bringing the total attendance to around 500. I was fortunate to attend as one of the representatives of Software Freedom Conservancy, which handles GSoC payments for multiple projects and also worked with a GSoC student of its own in 2014. We will look at some highlights from the dinner reception and cover two of the unconference sessions.

Musings on the history of GSoC and some surprise speakers

Friday started with a visit to California's Great America, which is an amusement park with roller coasters and other attractions. The park was only open to GSoC Reunion attendees, which meant that people got to enjoy the rides without any queues. In the evening, Google hosted a dinner reception at The Tech Museum of Innovation in San Jose. The dinner reception provided an interesting exhibition, food, and some surprise speakers.

The first speaker was hardly a surprise. Chris DiBona, director of open source at Google, talked about the history and significance of Google Summer of Code. He recounted a meeting with Google co-founder Larry Page, who lamented that computer science students spend the academic year learning about computers but often regress with their learning during the summer holidays because they cannot focus on coding. Page gave DiBona a simple mission: fix this problem.

DiBona thought it would be a great idea to get students to work on open source over the summer and asked several projects if they would be able to do anything with some students. The response was generally positive, as long as projects were not forced to integrate the code from a student if it didn't meet the project's criteria for inclusion, and this this is how Google Summer of Code was born. Thanking everyone for their work and contributions, DiBona stated that "we're all here for a reason"—people were not selected by chance, but because of the work they have done.

After two more speakers from Google, two GSoC mentors were introduced. They turned out to be Linus Torvalds and Dirk Hohndel. While Torvalds may be known for popular projects like Git and the Linux kernel, they were invited to the GSoC Reunion as mentors representing Subsurface, a piece of software for planning and logging dives. Torvalds was quick to point out that he was, in fact, not a GSoC mentor because he would only scare students away, but Hohndel confirmed his own role as mentor and organization administrator for Subsurface.

In a Q&A-style session, Torvalds was asked to give his insights on what it takes to become a good programmer. One of the key characteristics, according to Torvalds, is perseverance. Debugging is a good example because you have to drill down until you get to the bottom of the problem and understand what's going on.

Another key requirement is taste. Torvalds said that he couldn't describe what he means by taste, but that it's something he knows when he sees it. Taste allows you to make the right decisions. The good taste shown by certain developers enables Torvalds to trust them completely because he knows that they will do the right thing. It allowed him to hand the maintainership of Git over to Junio Hamano and to accept pull requests from certain Linux developers without looking at the code.

Torvalds argued that experience makes you faster, but is often overrated. He can frequently judge patches in seconds these days because of experience, but experience doesn't replace taste. Unfortunately, Torvalds didn't know how people can develop taste.

Hohndel also chimed in with his insights, recommending that students "think small". Instead of planning to design a completely new system, they should focus on their immediate needs—fixing bugs in software they use is usually how people get started.

Paid and unpaid contributors

The first unconference session I attended was on paid and unpaid FLOSS contributors. This session was suggested by Thorsten Behrens, chairman of the board of The Document Foundation. He observed that LibreOffice has a lot of volunteers as well as a lot of paid developers, and that the Document Foundation recently published a tender for paid development work.

While many developers are paid to work on open-source software these days, paying people as well as mixing volunteers and paid developers in a project can be delicate issues. There was a general feeling in the session that projects comprising both paid and unpaid contributors treat all contributors equally. The only exception are projects sponsored by a single company in which priority is often given to developers from that company, for example when it comes to reviewing patches.

Robert Kaye from the MusicBrainz project explained that its development process is driven by the community through a bug tracker. While companies cannot tell the project what to do, they can participate in the development process—just like anyone else. The MetaBrainz Foundation (which sponsors MusicBrainz) has a steady flow of income from companies such as Google and Last.fm that use MusicBrainz data; it uses that money to employ people. A key here is transparency, something that was echoed by others in the room. Perl, for example, has a grant process that allows developers to apply for funding. What works well is that the process of applying for grants is well described and open to anyone.

Someone in the audience suggested that paying people who have been long-term volunteers works well. However, when money goes to newcomers, it can lead to distortions because these people may come in with a different motivation compared to people who started out as unpaid volunteers. Someone noted that only paying people who have a history of unpaid contributions makes it hard for certain groups to get started. She acknowledged that many people start doing open source as their second shift (meaning work done at home in their spare time), but creating more opportunities to work on open source on the first shift (i.e. as paid work) can have a positive impact on diversity.

When a project wants to pay developers, the big questions are how much and what for. The salary question can be complex since many projects are global. If you have a fixed budget of $60K, this salary figure means something completely different to someone living in San Francisco than it does to someone in a low-cost location. In answer to the question of what to pay for, someone from FreeBSD suggested that paying for activities that are extremely complex and hard to perform in someone's spare time works well, such as legacy build systems and kernel video drivers. These tasks are "almost impossible if people don't get paid". Similarly, paying people for tasks considered boring, such as code review or documentation, has worked well.

There are some issues with paying people, though. One is that other people often avoid a particular area when they see that someone is getting paid to work on it, even though the activity could benefit from more contributors. There's also the phenomenon of "cookie licking"—marking a particular area as yours and getting offended when other people want to work on it.

There was a general agreement in the room that paying students through GSoC works well, although some noted that there can be resentment when the work of a student who gets paid to work on a project doesn't meet the project's quality standard—why is the student paid for something an existing volunteer could have done better? However, this is generally not a big deal since it's not the organization's money that is being spent on the student.

As open source is getting increasingly popular, the majority of projects will consist of both unpaid and paid contributors. Projects have to ensure that all participants can co-exist without resentment, particularly if the project itself starts paying certain developers. Projects are increasingly gaining experience with questions related to paying developers and we can all benefit from sharing those experiences.

Making your project more approachable to new contributors

Another session I attended was on making projects more approachable to new contributors. This session was led by Angela Byron, a former GSoC student, and Chandan Singh, a GSoC 2014 student working on Drupal. Together, they presented several blockers that contributors often face. Byron explained that she installed Debian many years ago, but that she never considered contributing to the project at that time because she thought that she wasn't skilled enough.

When GSoC was launched, Byron applied as a student, thinking that you're not expected to already know how everything works as a student. This worked out really well and Byron is now a Drupal core committer. Another assumption that stops potential contributions is that you have to be a developer in order to contribute. There are many other ways to make significant contributions and projects should offer tasks that require diverse skill sets.

Singh observed that newcomers are often overwhelmed by the scale of a project and don't know where to start. When you find a problem, it's hard to know where to begin if you want to fix the problem. A representative from Eclipse in the audience noted that people often don't even know that they can contribute.

A good way to make things easier for new contributors is to post clear signs on how to get started. A LibreOffice developer mentioned LibreOffice Easy Hacks, which highlights bugs and tasks that are easy to tackle, as a good initiative that made it easier to get started. Other projects have similar initiatives, such as Drupal's Novice tags; a student in the audience confirmed that highlighting easy tasks "really helps".

There was general agreement that it's important to make it as easy as possible to get started. Someone suggested providing a complete environment, such as a VM image, that includes the tools required to hack on a project. Byron mentioned the Drupal Ladder, which breaks down the tasks required to get started into simple steps, such as installing Git, getting familiar with the issue tracker, and eventually submitting patches. Each step is accompanied by a tutorial, which makes it easy to take the step and advance on the ladder. It's important to think about the steps required to become proficient at something; in the process you should try to eliminate as many steps as possible. After all, "nobody wants a 27-step ladder", Byron said.

Good mentoring can make a real difference to newcomers. Drupal has taken mentoring to its heart, according to Byron. The project offers core mentoring hour—twice a week, mentors are available on IRC to help new contributors get started. Mentors curate lists of issues that newcomers can work on and guide them through the steps required. A representative from Ceph noted that they host quarterly online developer meetings through video chat, which allow new contributors to interact with developers. He observed that the "human element is huge".

Overall, many good ideas were discussed in this session and there was an understanding that projects can drive many activities to make it easier to get started.

Conclusions

I found the GSoC Reunion to be quite a stimulating event. What's unique about the event is the diverse nature of attendees. I cannot think of another event that brings contributors from so many different projects together. Open-source communities are different, but at the end of the day we often face similar issues. We can all benefit from sharing experiences—positive as well as negative—with each other and the Google Summer of Code gathering is an excellent venue for this.