GSoC Student Application Template

From OpenCog

Before we get to the actual application form, here are some important remarks about the application process -- please read them carefully.


Submitting the application form is only part of the deal: we expect a few other things on top of that. Following the recommendations below will make your application much stronger, and help it to stand out from the other applications submitted.

Naming your application

Please give your application a useful title. In many cases, you can simply copy it from the project ideas list. Although some ideas are quite broad and will require you to make the title specific to clearly convey the projects aim.

If you are proposing a project not on the ideas list, you'll have to find a useful title yourself -- but surely this won't be too difficult given that you were able to come up with your own project idea!


One of the things we expect is that you contact us directly as soon as possible (preferably even before you send the application form), on our OpenCog mailing list, details of which are on the Discussion page (please join the mailing list before posting to save us manually moderating messages). Don't be afraid -- we won't bite.

Contacting us as soon as possible is crucial, as regular communication is the single most important factor for a successful GSoC project. We need to see that you are able and willing to talk to us regularly. Your communication will also allow us to get to know you much better than the application form alone does.

You shouldn't be at a loss for reason to contact us. In particular you'll want to discuss your project and application with us. This will allow you to gain a much better idea about the project, along with our expectations. -- in short, you will be able to submit a better application right from the beginning, with a better chance of acceptance.


The other thing that will strongly support your application is submitting a useful patch to some part of the OpenCog code (whether the core framework, RelEx, MOSES, PLN, or other part or project related to OpenCog). Our Ideas page is worth checking, but if you are not sure where to start, ask us! We can assist with questions on version control and on the process of generating a patch.

If you want your submission to count towards your application, patches should be submitted well before the close date for the submission of student applications. Patches earlier than this date are encouraged, as the sooner we get them the sooner we notice your contribution. A wave of patches at the submission date makes it hard to distinguish between applicants.

This is aspect of your application is important, as it shows that you have everything set up to start hacking on the project (source code, tool chain, testing environment etc.), and that you have the qualifications necessary to successfully finish the project: general programming abilities; working in the OpenCog environment; submitting patches and reacting to feedback; finding and/or asking for any information you need; and so on. You'll also want to be aware of our development standards for code formatting.

Don't get us wrong though, we do not demand that you know how to do all this up front. After all, the idea of GSoC is to introduce you to free software development in general. We are willing to help you with anything you will need to create the patch -- you just need to ask!

We actively encourage you to contact us whenever you have any doubts. Don't be afraid that we will think worse of you when you ask too much. On the contrary: this is an occasion for you to show us that whenever there is something you don't know yet, you are able to learn quickly, and know how to ask for help. Active contributors are constantly asking each other questions about how the code and different tools work. Asking questions is a great way to learn.

As for the kind of change we want, it would ideally be some real improvement (bug fix or new feature) in a part of OpenCog related to the specific project you want to work on. Other useful patches may add missing documentation to our code (we use Doxygen) or fixing spelling mistakes.

Note that we do not place any demands on the size of the change. Even a very simple modification suffices to show you can contribute. Although the more involved your changes are, and the more you send us, the more impressed we'll be ;-)


Now to the actual questions in the application form. Please answer all questions, otherwise we'll end up asking you to complete the questions you missed anyhow.

If some of these questions look strange to you and/or you don't quite know what to answer, don't despair. This is not some kind of exam -- we do not expect you to have good answers for all of them up front. The idea is more that you learn the answers before the end of the application process -- with our help.

And now that you are prepared to face the enemy, here we go!

Note: Please do not copy the template text (below) into your application. It is a guide only.

Important: Externally sourced material in your application (anything you did not write or create yourself) requires a citation.

  1. Your contact details.
    Google won't provide this to us automatically. At a minimum we need your name and email address. In addition we'd appreciate your github username (since you'll need to use github to submit your code).
  2. In your own words, describe the task of the project you want to work on.
    Be as specific as possible. It's not sufficient to rephrase the description from the project ideas page; show us that you actually understand what this task involves! Read the available documentation (and relevant code) if necessary. And don't hesitate to ask us for clarification if you have any doubts!
  3. Give a preliminary schedule for your work. The exact dates will obviously be only guesses; but try to be specific about all the individual steps you will have to do to complete the task.
    Note: By the end of the summer session, the code is expected to be in a state ready to be merged to master. Experience shows that adding the "final touches" necessary for that, tends to take up quite a lot of time -- there are always some bugs here and there, some misunderstandings about how things are supposed to work, build system issues, missing documentation, forgotten bits, and so on. Thus, the schedule should suppose that a large part of the main implementation work will be done by midterm! Code must be checked into Github before the midterm evaluation to receive a passing mark!
    Also note that by the beginning of the summer session, you need to be able to work on the task at more or less full speed -- meaning that you need to get familiar with the code, think through the design (and discuss it with us) etc. in the interim period before the summer of code.
  4. What things will you have to learn to be able to complete the project? What do you already know?
    In case you wonder what this question is getting at: Again, we want you to show us that you really understand what kind of work the task involves. As always, we encourage you to ask us for pointers if you are not sure how to go about this.
  5. Why did you choose this project idea? What do you consider most appealing about it?
    We want to know your motivation and see how passionate you are about the topic. In our experience, people that are really excited about their work tend to work hard and not give up when a challenge presents itself.
  6. Please describe your previous programming experience in detail.
    What languages do you use? How long have you been programming, and how much? What kind of programs have you written? What kind of programming (and related) work are you enjoying most?
  7. Have you been involved in any free software ("Open Source") projects yet?
    Which projects, how long, and in what way have you been involved? Have you been active in OpenCog project/OpenCog community before?
  8. In your own words, briefly describe OpenCog, including the goals, architecture etc. Also, what makes you interested in OpenCog? Why do you want to work on it? What is your vision of it's future development?
    We ask this because we want to make sure that people working on OpenCog do understand the core concepts. For example, students should be at least passingly familiar with the concepts of the AtomSpace, PLN, MOSES, Nodes vs. Links, etc.
  9. If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor?
    In other words, how do you intend to deal with time zone differences with your mentor, since our mentors are distributed around the world.
  10. When does your university term end, when are your exams, and when does the next term begin?
    We need to know up front whether there are any overlaps with the GSoC time frame (especially the summer session) in relation to any other commitments. We can then develop a plan for how to deal with these.
  11. How much time do you intend to spend on your GSoC project per day/week during the summer months?
    We except the project to be your major occupation during the summer. In other words, you should treat it more or less as a normal full-time job.
  12. What other major activities will you engage in during the summer? (Moving apartments, longer vacations, other obligations, etc.) If any, how do you intend to make sure you will be able to dedicate sufficient time to your project?
    Please be open about this, and also mention things you are not yet sure about. We can be flexible about time arrangements; but we need to know about any possible obstacles up front.
  13. Are you able and willing to sign the OpenCog Foundation Individual Contributor License Agreement?
    Note, this agreement is based on the Apache 2.0 ICLA. The agreement's purpose is to allow the OpenCog Foundation to foster the development of the OpenCog framework and, in future, potentially license it to companies. Any revenue gathered from licensing the OpenCog framework will be purely used to support further research by the OpenCog Foundation into beneficial AI. The OpenCog Foundation which is a registered non-profit corporation in the state of Delaware.
  14. Are you willing to write weekly email reports of your progress to the mailing list?
    This allows to ensure progress is being made and if you get stuck on something other members of the team can help out if your mentor wasn't able to immediately give you the solution.
  15. How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program?
    We obviously have a preference for bringing in long term collaborators on the project. If you're here for the long haul you'll have an advantage.
  16. Anything else you want to add to your application?

Note: This template was originally based on a template by the GNU Hurd project. Thanks guys!