Recruiting and working with student developers

by Scott Wilson on 9 September 2014

Introduction

This article was originally written by Mike Jackson and published by the Software Sustainability Institute under a CC-BY-NC license. It has been updated by Scott Wilson of OSS Watch.

It’s frustrating when you have an idea for improving your software, but lack the resources needed to realise it. Not all is lost! Your idea might be the perfect basis for a student project. Student projects are generally a win-win situation for you and the student. You get to investigate ideas with relatively little outlay and the student gets highly valuable work experience in a professional environment.

“There is too much work!” must be one of the most common complaints heard in any project. Coping with a large workload means that there is little time to explore ideas (especially the kind of riskier ideas that can be highly valuable to your software). You could recruit more developers, but it will be difficult to recruit over the short time period needed to explore your idea. Instead, you could turn to a source of keen, hard-working and intelligent workers: students.

In this guide, we explain how to recruit students, what they can contribute, how students themselves can benefit and some important things to bear in mind.

Where to recruit student developers

There are a number of options for recruiting students to work on your project. Which one is right for you, of course, will depend upon your project and organisation.

Employ a student

If you have the resources, you can simply employ the student. They could work part time in addition to their studies or on a temporary basis during breaks between semesters. Some organisations provide the infrastructure for recruiting students in this way, so it is advisable to ask whether such a programme exists.

For example, at the University of Oxford there are student summer internship programmes, both from the Careers Service and also directly from departments such as IT Services.

Student projects

Undergraduate and Master’s students generally complete a three to six month project as part of their study. The idea that you want to explore could become the basis for one of these projects. This idea is easier to implement if you work within a university. However, it’s not impossible to recruit students if you work outside of academia. In fact, projects from outside the university often hold more kudos and could attract the best students.

Topics for student projects are decided by academic staff at the students’ university. Since there are usually more students than interesting projects, you will typically find that academic staff are very grateful for your ideas. To be accepted, your idea will need to incorporate elements from the students’ course (for example, a course in human-computer interaction could require a project that includes some interface design). It’s a good idea to look at the courses studied at your target university and see if any are related to your project idea, and then and approach the relevant course organisers.

Semester of Code

As well as working directly with a single course leader, you can also pool your ideas and make them available to a wider range of students, using a programme such as Semester of Code. This programme works in a similar way to Summer of Code (see below), but works with universities to incorporate the work the student does on the project into their academic studies or offer credit for industrial placement. Semester of Code is based in Europe and so involves mostly European students, but projects can be from anywhere.

UCOSP

The Undergraduate Capstone Open Source Projects programme has been running since 2009, and places students from Canadian universities with open source projects in a similar way to Semester of Code. Projects register with UCOSP, and are matched with a group of students (typically 5-6) who then work on the software for a single academic term. Unlike Semester of Code and Google Summer of Code, UCOSP places more emphasis on having an early face-to-face code sprint, and has more teamwork aspects.

Google Summer of Code

How about a student being paid to work for you? Sounds too good to be true, but it’s possible through the Google Summer of Code (GSoC).

GSoC was started in 2005 to encourage involvement in open-source projects. Organisations suggest ideas for student projects and agree to mentor any students who are interested in them. Google then decides whether those organisations meet the requirements of a mentoring organisation. If you meet the credentials and can interest a student in one of your projects, Google will pay the student a stipend to work on your project over the summer.

GSoC projects last for three months and must involve work on code that is released under a recognised open-source licence. GSoC is described in more detail below.

What you get

Since students generally work for a short period of time or are employed part time, the work they are most suited to is reasonably short projects with a definite deliverable, such as a prototype feature, a refactored component, bug fixes, a software demonstration, a design, performance figures or a usability assessment. Students are also highly suited to providing feedback on your software and documentation. Your student could also help make changes based on their feedback, such as commenting code, increasing test coverage, clarifying documentation or writing tutorials.

Recruiting a student also leads to less obvious benefits. By giving them the opportunity to work on your project, you may convert the student into a power user - someone who will continue to contribute to your software even after they’ve moved on from your project. And when they move on, your ex-student might just convert other people into users too. Working with a student on a short-term project allows you to assess the quality of their work and how they work with your team. It’s an in-depth job interview that might lead to them studying a PhD with your group or starting work as a contractor. A student of sufficiently high calibre may even find themselves employed full time at the end of their studies.

What the student gets

Students get a lot from working in professional development projects. Experience in a real project is highly important. Not only does it give the student a taste of life outwith their usual studies, it is also gives them relevant work experience and a referee who knows their work. This might be the only thing separating two good students at job interview. It also gives them the chance to work on the skills that are needed to work in a development environment, such as best practice, team working, understanding client requirements and delivering to deadline.

Working in a real project also gives the student prestige. They can say that they have made a contribution to a live software or research project. This is especially if it’s well-known software and they gain an acknowledgement for their contribution.

A student as part of your team

It’s best to bring the student into your team rather than treat their project as a separate, outside entity. If they feel like part of the team, the student will be more likely to contribute.

Invite them to project meetings, encourage them to get involved in discussions, give them access to the project management tools (such as mailing lists and issue tracker) and internal project resources.

This gives the student experience and insight into how software projects are run day-to-day, and it will show them that they are indeed contributing to a live project.

If you aren’t already operating the project in a distributed and open manner, this may be a good opportunity to change your working practices to follow the open development approach.

Communication, communication, communication

Almost every problem that occurs when students work on software projects can be traced back to a failure of communication. While students are often self-motivated and can operate with a minimum of supervision, you have to ensure there is good shared understanding and shared expectations. In GSoC and similar programmes the usual expectation is that there is a student-mentor meeting (e.g. using Skype, phone, or face to face) every week. In the worst cases, failure to communicate can result in the student “drifting off” to work on other things, assuming the mentor has lost interest in the project.

You need to set clear expectations when it comes to answering enquiries, being available, and also set aside time for regular meetings to keep up to date.

Integrating code created by students

You have to decide how to integrate the student’s code into your software. There are two main approaches: integration at the end or continuous integration.

Integrating the student’s work at the end of their project gives you the chance to fully review the code before it’s integrated with your software. However, by leaving everything to the end of the project, the student may have left before the code is integrated and taken their understanding of the code with them.

We consider the approach of continuous integration to be preferable: this is where the student is given access to your code-base so they can contribute to your software from the outset of their project. This requires more frequent checking of their code to ensure that it is of sufficient quality, but it overcomes the rush to integrate code at the end of the project. This approach also means that the student will feel a trusted part of the team, which will motivate them to provide good code.

Some projects use GitHub as a way of managing code. This allows the student to create a fork, and then manage the contributions to the main codebase using pull requests. In this way a distinction can be maintained between the core codebase and the student contribution, but allow for continuous integration of reviewed code.

In other cases, you may need the student to create patches based on their local version of the code, that you then evaluate and commit against the codebase. Alternatively you may give the student commit rights; it is up to you then as mentor to ensure you review their code.

Words of caution

While students have the potential to make a significant contribution to your software, some problems could arise. Major pitfalls can be avoided by bearing a few important points in mind.

A student who is working on a project for their degree will primarily focus on what is needed to get their qualification. Keep in mind that apart from the code design and development, the student may also need to conduct a literature review and prepare a final report. Time will be needed to complete these extras (which do not directly contribute to your software). You might be asked to read their final report and possibly contribute to an assessment of the student’s work.

As with any new employee, time and effort will be needed to induct the student into your project and software. Time is also needed to support the student and answer their questions.

It might be tempting to give students tasks that no one else on your team wants to do! This is not a good idea. The task that you set the student needs to be interesting. If it is not, the student will lose interest and the quality of their work will most likely suffer.

The quality of the student’s contribution depends on the individual student. As with any recruitment, time invested in assessing the potential recruit’s knowledge and working practices will pay off in the long term.

Semester of Code

Semester of Code (SoC) was started as a pilot in 2014, and follows much the same model as Google Summer of Code. The main difference is that, rather than paying students a stipend, the programme focuses on integrating the work of the student into their academic achievement. For example, a student’s work on your project may form part of their dissertation, or they may receive credit for their involvement in a similar way to an industrial placement.

The process for engagement is quite simple from the point of view of a mentor or project lead as there are no financial aspects - you simply register the project and the staff willing to mentor students with SoC, and then add your ideas for student projects. Students then write proposals for how they will address the idea, and you can choose whether to accept them.

As with Google Summer of Code, students would normally be working remotely, so you must be comfortable with this way of working. Unlike GSoC, you also have to consider the communication and relationship with the student’s academic supervisor, as you would with a regular dissertation placement. The academic supervisor can also be a big help in communicating with the student and overcoming problems.

Google Summer of Code

Google Summer of Code (GSoC) was started in 2005 to encourage involvement in open-source projects. Google matches students to organisations and pay the students to work with the organisation for three months during the summer. The primary condition of GSoC is that the students must work on software that is released under a licence recognised by the Open Source Initiative. GSoC projects run from mid-May to mid-August, with an initial getting-to-know-each-other phase in early May.

Before taking part in GSoC, your organisation must be accepted as a GSoC mentoring organisation and you must propose some project ideas. Google decides whether to grant mentor status based on criteria such as the quality of your ideas and your work in the open-source field. If accepted, the next step is to register mentors with Google. It is a mentor’s job to supervise the work of students. Your organisation is assigned a number of student places based on the number of students who apply for your GSoC. Simply being assigned a student place is no guarantee of recruiting a student, you must wait for a student to select one of your project ideas.

Students register with Google and, if accepted, choose the organisations they want to work with. They can choose one of your ideas or they can suggest a project of their own. Students can express interest in multiple organisations so some negotiation might be required to keep a good student interested in you!

It is assumed that the student will work remotely from you, so you must be comfortable with remote working and have the infrastructure to do so. At a minimum, you will need to support remote access to your code repository, e-mail and also some form of interactive chat, such as MSN or Skype.

To assess how the project is progressing, both the student and the organisation complete a questionnaire midway through the project. This ensures that the student is doing the work and your organisation is being open, helpful and cooperative. If the student is rated poorly, they won’t be paid for the second half of the project. If a mentor is rated poorly, this will affect your organisation’s chance of participating in future GSoCs. At the completion of the project, both parties complete an end-of-project questionnaire.

GSoC projects may prove appealing to students. If successfully accepted, they can add Google Summer of Code to their CV, which is a prestigious accomplishment. And, students get paid! They can expect to receive around $5000 and a sought-after T-shirt. The benefit for participating organisations is both the prestige of having mentored such a project, $500, a T-shirt and an invite for up to two mentors to attend a mentoring summit at Google in California (including free travel and two nights accommodation).

For more information on GSoC, see Google’s GSoC website.

Here at OSS Watch we’ve been mentors at GSoC and on the Semester of Code programme, so get in touch if you need advice. Our colleagues at the Software Sustainabilty Institute have had experience in applying for and acting as a mentoring organisation for GSoC projects, so feel free to contact them for information and advice too.