GSoCStudentInfo

GSoC - Information for students

Here's the most important steps of applying for GSoC with GNU Radio:

• Read this entire page before submitting applications. We will not consider your application otherwise.
• Read Google's FAQ
• Take a look at our list of ideas
• Come up with project that you're interested in (be it on the list or not!)
• Write a first draft proposal and get someone to review it for you (perhaps one of the mentors)
• Submit it using Google's web interface
• Important: Make sure you have followed all the instructions on this page. Failing to do so will cause us to ignore your proposal, as we usually have many more applicants than we have slots!

For accepted students, we have guidelines in place for during GSoC, see our rules of conduct page.

Student/Contributor Eligibility

This year (2022), participants no longer need to be enrolled at a university to be eligible for GSoC.

The formal requirements are that you:

• must be at least 18 years old at time of registration.
• must be an open source beginner.
• must be eligible to work in your country of residence during the duration of program.
• must be a resident of a country not currently embargoed by the United States.

The Project

Choose a project that suits you. We have project ideas on our GSoC page you can choose from, but you can also submit your own ideas. If you do so, tell us early enough about that! It is also OK to use the ideas as a rough guideline for your project, but to vary from that.

Note that if you submit your own idea, even if it's awesome, there might be no mentor who has the technical know-how to supervise that, or simply no-one who want to supervise that specific project. If you post your idea early enough, this is usually not a problem, though.

Whatever you do, it is very important that you understand the project you'll be working on. Proving that you understand the problem is basically the first hurdle for you to get our attention.

You can submit several applications for GNU Radio, so if there are several projects you feel like doing, submit one for each project. Time has shown that it's usually better to eventually focus on one proposal, because it's already quite some work to get one excellent proposal finished.

The Proposal

The proposal, which you submit to the GSoC page, is the single most important part of your application.
In the time before the proposal submission, you should contact the GNU Radio mailing list.
The mentors (and other community members) will give you some feedback on your proposal, but that does mean you have to have to actually write a proposal on which you can get feedback.

It might seem odd to publically announce an unfinished proposal. You might be concerned that other students will read and copy your proposal. However, in the past, that has never happened. Students who submit early, and gather feedback, have always been the most successful students. We recommend having a proposal e.g. as a Google doc, or on an site like github, and treat it like open source software. Experience has shown that your chances are better if you start early with a publicly available proposal than developing your proposal trying to do it in private.

An example of a successful proposal from 2012 can be found here (filter design).

The following things must be in the proposal, or it is considered incomplete and will not be considered for acceptance! We will simply mark your proposal as 'incomplete' and ignore communications from you.

Topic background

If there's any theory necessary for your project, include some pointers and explain the basics. Prove to us that you know what you're talking about.

Something like this is good:

> Herring-Codes were initially proposed in the seminal paper "Herring-Codes in a fishy radio environment" [1]. They are based on the mathematical theory that...

Also, you should start getting a good idea about what's available in GNU Radio and other projects. This means you should have a look at the source code of GNU Radio. Here's an idea:

> In GNU Radio, there are codes available in the component gr-fec. Having looked at the available blocks, it is clear that the available blocks in gr-fec, such as the ccsds_27_bb blocks, cannot trivially be modified to include Herring-Codes. It therefore makes sense to add these to GNU Radio.

One major difference between some free software projects and GNU Radio is that the required technical background can be quite daunting, up to a point where some GSoC projects can't possibly be worked upon by people without a communications engineering background. However, we try to make GSoC accessible to all clever students, and have a variety of topics available.

Important: This is the summer of code, not the summer of research! Your first goal must be coded deliverables. If it is possible to get some research done at the same time, or even write a paper on the subject, that's fantastic. But don't forget the code!

The Deliverables

Inside the proposal, your deliverables are the most important thing.
Clearly outline what you are planning to code, including the platform (host or USRP?) and the programming language (VHDL, C++, Python?).
Don't be vague! The following is not a good deliverable:

• Deliverable 1: Include Herring-Codes in GNU Radio

Rather, write it like this:

• Deliverable 0: Create on out-of-tree module for Herring codes (gr-herring), using gr-modtool.
• Deliverable 1: Add blocks for Herring codes (written in C++). This will require two blocks (herring_X and herring_Y), with the specs shown in Fig Z.

Also, write what you're not doing if it's not explicitly clear. Something like this would be OK:

• Often, Herring-Codes are mentioned in connection with Trout-Codes. These will not be included in gr-herring.

License

In most cases, the code submitted must be GPLv3 licensed. In most cases, there is no choice about this (e.g., if you are adding to the GNU Radio main tree, or writing typical OOT-modules). If you want to use another license, do tell us and lay out the reasons. In any case, specify the licence you will be using. This also shows us you care about free software licences and know a bit about them.

Schedule

Check the schedule on the GSoC website. Then figure out how you want to spend the time allocated to coding. Again, be specific - this shows us that you've put some thought into planning your summer. Of course we are aware that plans often need to be changed, so the schedule is of course changeable during the course of GSoC (in coordination with your mentor!).

Don't forget to include time to write documentation, add QA codes and, most importantly, fix bugs! Don't leave docs etc. for the end.

Other things to include:

• How many hours per week are you planning to code? Be honest, and don't forget: we expect you to work full-time on this.
• Is there a period where you won't be coding? During 3 months, it is not unreasonable to have a week 'off' for whatever reason, be it exams or other issues. Just be honest about this, and tell us beforehand.
• Do you have other commitments during the summer that will take time away from coding? Tell us about that!
• How many hours in total (90, 175 or 350) is your project?
• How long is your coding period? It can be anywhere from 10 to 22 weeks. This number can be changed during the coding period, so don't worry too much about it, but you still need to include an estimate in your proposal.

Proof of your coding capabilities / prerequisite capabilities

Despite having close contact with your mentor, it will not be possible to work on a project if you're not already capable of writing code. Depending on the project, you will need different skills, typically C++ and/or Python to a good degree, and sometimes other skills, such as DSP, wireless communication, low-level processor architecture, or something like that.

Make sure your proposal gives us a way of knowing you're capable of doing these things. For code, the best way is to show us to previous projects of yours (e.g., your github page, contributions to other projects, something like that). For more theoretical subjects, a good way is to explain something in your proposal, in your own words.

Formalities

Include these things (again, these are not optional!):

• Your name, place of residence
• Your university and students status (are you a grad, undergrad... Note that university enrollment is no longer a requirement!)
• Tell us if your GSoC work is in connection with your university work. Are you getting credit for your GSoC project? (None of this affects whether or not you're selected, we're just curious. It still needs to be in your application).

Of course, check what Google requires you to reveal about yourself.

Note that the layout, language etc. of the proposal matter. Make it look good, both content-wise and literally.

Background on yourself

Tell us about yourself. In particular we're interested in your coding history. Also, remember that you will be working closely with one of our mentors for three months, so we want to know what it's like working with you. Show us that you're used to working with other people!

Also, remember that your mentor might be on another continent, speak another language, live in another time zone. How do you propose working with us? Are you on Skype, G+...?

Most of the time, you will be speaking English with your mentor (you might get lucky and get a mentor that speaks your language, but be prepared to end up with a mentor of another nationality). Is your English good enough? Tell us about that.

Proof of your technical proficiency is also required. Point us to your github, or show us any code you've produced in the past! Don't omit any of these questions:

• Have you participated in an open source project before? If yes, which one? (If not, explicitly say so! A lot of our previous participants have had little experience in the free software world. Be honest!)
• If you have, we'd like to see specific commits and contributions to those projects, please.
• What code have you written? Upload as much as possible to github before applying, so we can have a look. If there's no code at all, we assume you can't code (and won't consider your application).
• Which languages have you mastered so far?

Finally, we want to know about your relationship to the GNU Radio community, such as

• Have you participated in GNU Radio before?
• How are you planning to contribute to GNU Radio after GSoC?

A neat idea on how to present yourself is to upload a video of yourself explaining something.

Acknowledge the three strikes rule

On our rules of conduct page, we have outlined some rules including the three strikes rule. In your application, make a note that you have acknowledged and understood this rule.

The secret code word

Somewhere in your application, include the secret code word: "Cyberspectrum is the best spectrum". We will scan for this code word and simply not read the rest of your application if we can't find it.

Being a community member

First of all: You do not have to be an active developer of GNU Radio to participate! For us, it's just as important to get new people into the project as it is to actually see the projects being coded, maybe more so. Perhaps you just heard about GNU Radio through GSoC? That's fine!

However, we do want to get to know you, and see you integrate into our community. So, once you've decided you want to participate in GSoC, definetely sign up to the mailing list (which is the most important hub for the GNU Radio community).
Introduce yourself, tell us you want to participate and tell us about what you want to do.

Earlier is better than later. The more time you spend on the list, discussing your and other projects, the more familiar you will be with how the community ticks, and we will get to know you better, as well. We try to be objective when grading proposals, but if someone's already made a good impression and we all know she or he writes good code, that definitely counts in your favour.

Working with a mentor (before and during GSoC)

Mentors have the biggest say (next to Google) who participates in GSoC, so be nice to them. Also, mentors are volunteers, and don't get paid for GSoC, unlike you (if you're selected). This means they won't be working full-time mentoring you, so don't expect them to micro-manage your project.

For this reason, it is important you prove that you're able to work independently and autonomously (if you and your mentor live in different time zones, you might have a call once a week and some chats/emails in between).

Before the summer of code

• Contact the mailing list, ask for feedback on your proposal, become engaged in the community. Don't spam us, that doesn't look good.
• Make sure they know you're serious about GSoC by asking good questions.
• If necessary, brush up your coding skills and play around with GNU Radio.

During GSoC

• Make sure you have regular contact with your mentor.
• We require weekly updates that are publically visible for the entire community. A blog etc. is a good way to do this.

How we grade proposals

The following points are considered when grading proposals:

• How well do we understand what the student exactly is going to do?
• How likely is success with this project?
• How much does GNU Radio benefit from this project?
• What are the chances of the student becoming an active member of the community after GSoC?

Of course, all the other things on this page must also be considered.

GSoC is good for your education!

To be very clear here: GSoC is not part of your degree. If you want to apply in order to "clear GSoC" for your curriculum or whatever, go elsewhere. We want people who are actually passionate about this project, and free software. Sure, it will look good on your CV. But that's not a good motivation to apply here.

That said, GSoC will make you smarter. And if your university is cooperative, there's no reason for GSoC and your university education to be mutually exclusive. In the past, universities have often supported GSoC students by giving them access to their labs, or even awarding credit for the project. Being a student is no longer a prerequisite to joining GSoC, but if you are, feel free to talk to us about collaborating, and talk to your university advisor if they are willing to give some support.

Hints

There are some good hints on some of these pages from other projects:

• KDE GSoC page
• PostgreSQL GSoC
• Want to be selected for GSoC? (a generic but very thorough guide, not specific to any one organization)

Some more hints which have come up over the years:

• People tend to want to do signal processing stuff. We also like project diversity, and your chances will increase if you apply to work in other areas, such as improving user interfaces (if you do that, a lot of people will be affected by your work; they might buy you beers)
• The more we know about you, the better your chances. Make the proposal a personal matter
• Don't forget the secret code word.