Last week I had the privilege of attending the 2016 Google Summer of Code Mentor Summit in Sunnyvale California, as a mentor from the MariaDB Foundation. I came with no expectations of what was going to happen but went packed with chocolate to share (as the tradition dictates) and with a desire to interact with people working on completely different open source projects. The summit itself is a great opportunity to meet people with all sorts of different philosophies on how open source should be.
The topics discussed were quite diverse. There was a track on how to make sure your project survives, with questions such as where to get funding, when to start a non-profit foundation, when to join an umbrella organisation etc. There were also plenty of legal talks centered on licensing, wether to use GPL, LGPL, AGPL, BSD, MIT, Apache v2 or some other different incarnation. Not my quote, but this summit was one where the phrase "I am not a lawyer" was indeed surpassed in frequency by "I am not YOUR lawyer". Plenty of very knowledgeable people on copyright issues made a very clear case and the main direction to get from them is that a well known license is preferable to a custom or obscure one. Also, when you see code with no license, you should steer clear. The legal troubles associated with code that does not have a license are big enough to potentially end your entire project.
Seeing as this was a summit for GSoC mentors, I wanted to understand what their approach is to getting students involved into their communities. Luckly we had a track just for that as well. I have had quite some productive discussions that I will try to summarise.
How to have a successful GSoC as an organisation
There are many variables to take into account when applying for GSoC as an organisation. The key ingredients that you need to get quality contributions are:
It is important that mentors are always available to students. Students are often making their first steps into a large code base and are bound to have questions, lots of questions. Having unanswered questions on mailing lists or IRC is a really bad image that an organisation projects.
On top of that, sadly, a lot of students' questions go unasked as well. From many orgs' past experiences (Python Software Foundation for example), new students are reluctant to ask questions publicly, for fear of saying something "stupid". This makes it even more important to have available mentors and clear instructions on how to reach knowledgeable people about potential projects. Students often feel more comfortable asking questions in private emails or messages. If that happens, mentors should promptly provide a reply, as well as encouragement to move the discussion to an open channel.
Given that students are, in general, new to the whole open source ecosystem they may not be comfortable with the tools that we normally use. This brings us to the next main point.
Low barrier of entry
The first contact that a potential student has with an organisation is through the link present on the GSoC website, when they are first applying. This link has a lot of potential. It is important not to waste it. A very good example is set forth by Open Suse's Landing Page. The landing page has a very clear interface, giving the list of potential projects, the mentors in charge of them, ways to get in touch with mentors, as well as ways to get started with the related codebase.
Another interesting observation is that irc and mailing lists are generally a "scary" topic for new students. It may be the slightly impersonal aspect of it, or the lack of a concrete user interface, or the etiquette that has to be followed, but whatever it is, it does represent a bigger hoop to jump through. Interesting alternatives are discussion places such as GitHub's issue page or Gitter instead of IRC. My impression is that at least seeing a person's image next to their comments helps bridge this imaginary barrier of impersonality and makes the whole environment more approachable.
Another good thing to ensure students' involvement is a clear explanation of the requirements. This includes both expected project requirements like required functionality, technologies, overall scope as well as GSoC proposal requirements. Students are more likely to engage with the project if they know clearly what is expected of them, all across the program's duration (and beyond).
Well defined selection process
It is important to have a well defined set of rules for accepting students for GSoC. The goal of the process is to help both you as an organisation, but also students to find the best match possible. Many organisations set up a list of tasks that students must complete before their proposal has a chance of being considered. Such tasks include a small bug fix, an investigation on a buggy use case, or maybe just a setting up of a development environment. These tasks help in multiple ways. First, it gives any potential contributor a stepping stone into the project. It is always a daunting task to get started with a large code base. It becomes even scarier if the only bugs available are impossible to reproduce race conditions that senior developers have put on the back burner. Second, it weeds out the not-so-serious students and half-baked proposals. Stating clearly that without any effort on their behalf, they have no chance of getting accepted will make your job a lot easier even before the program starts.
An example of a bite-sized tasks include changing of return codes (patch). Documentation tasks are also great as well. Having such tasks is useful not only for GSoC but as a general community outreach approach. Making a habit of tagging simple tasks as community friendly can net you more contributors down the line.
One final point I would like to make is not entirely related to GSoC, but is a good approach to take. The organisation should have a set of rules and guidelines in place, starting from how to communicate, where and when to who has which responsibilities and how code gets merged. All this information should be easily available and always adapting to the projects' needs. It is very important that the people responsible take care of community contributions. Open source projects live thanks to the community's involvement. Having contributors ignored for long periods of time leads to having no contributors at all.
There is one organisation that has taken the responsibility to address community contributions to a whole new level. Jenkins go as far as automatically merging pull requests that have not been addressed by a maintainer after a set period of time. This does not mean that every bad pull request gets merged, but every ignored pull request (good or bad) gets merged. Their mentality is that if a maintainer is unable to keep up with the community contributions and at the same time the community is willing to contribute to the project, then perhaps it makes sense to give the community the power to dictate the feature set of that project and give the chance for a more active contributor to maintain it. Extreme? Yes! Does it work? Jenkins' success confirms.
To wrap it up, GSoC is an incredible opportunity for open source in general. It is a shame to waste potential long term contributors by making simple community facing mistakes. Many of the ideas presented here are easy to integrate into any project and will most likely improve your chances of getting accepted into the program, but also improve your interaction with students.
I believe there is always room for improvement and many of these ideas are compatible with the MariaDB project as well. In the coming months I will work on getting as many of these ideas implemented and see hands-on how impactful they are.
There are ofcourse many more things to mention, however these are the main ideas which I have found interesting, practical and general enough to be mentioned here. If you have more or better ideas, I would be very interested in knowing about them!