The end of Google Summer of Code (GSoC) is near, so I wanted to share with you how things worked out for me.
Precisely I wanted to let you know my perception about what it takes to participate to GSoC, the blockers you may encounter and how to overcome them, what to expect after the internship and a brief description of what I have been doing during my internship.
Participating in an internship such as GSoC will allow you to learn about the latest technologies and to contribute with an open source organization project you choose. Every project is different, so the previous knowledge you should have and the tools you are expected to use depends on the project plans.
You don't need to be hacker, but in my opinion you require a deep understanding of many computer sciences concepts.
The learning curve is generally high: you will need to get familiar with the project code - where are things located and how do they interact to make the application work -, you have to get used to the programming style of the community - every project has its conventions and it's important to stick to good practices to guarantee a high quality code -, you also require to understand the workflow - how do you submit your code for review, how the review process works and what is required to get it merged-, and finally you have to start working on your contribution - that can be harder than you think! -
This has to be done in less that three months. Generally, it is enough time... but when problems arise, it can get rough.
Because of that, you also need to be proactive - look for information about the things you don't understand and deplete all the resources you can find - and make your own decisions - is better to be wrong about something and then fix it with the feedback submitted by the reviewers than waste time poking people around to ask their opinion on a subject they may not be so familiar about -.
In my case I was already involved with OpenStack, so I was familiar with the workflow and with the community. But I required some time to understand the code base - it wasn't my area of expertise - and I also find it difficult to work on the feature I was assigned.
Well, the truth is that not everything works out of the box. Sometimes things can take an unexpected turn and you need to change the direction of your implementation.
Or maybe the task you took is more complex than it looked like or it depends on other projects to implement features on their side.
Or, even though you succeeded submitting your change, the review process take more time than you thought and you need to be open minded to explain the decisions you took to reviewers and accept changes that could make your code better.
This tend to be really frustrating and may end keeping you away from your goals. But you need to be ready to change and adapt, and you also have to be patient.
So... how to overcome all this? how do you find a workaround for that problem bugging you?
Communication is the key.
Having a mentor to guide you is truly important. And if you can also share with the rest of the community, even better! In fact, it's encouraged you talk with everyone, not only with your mentor.
Personally I faced many of this blockers, but thanks to my mentors and the community I could find ways to get around them and continue working with the same excitement as when I started.
Talking about them require an extra item. I want to emphasize how important is to find a good mentor and to get along with them. The human part of these internships worth to be discussed too.
It's essential that you share with them, what you feel good about and what is making you go nuts.
Given that GSoC is a remote internship, is always a good idea to keep your mentor up to what you are doing. Otherwise they cannot track your efforts and they won't notice if you are stuck with something.
Always try to find a balance: contact them, but don't expect them to devote all the time on you. They have their own projects and they also have deadlines. That is when the community comes in. If your mentor cannot reply your questions for some reason, you can also ask somebody else.
I also like asking them about themselves. In the other side you have a person with your same interests, but with a wider experience that can help you a lot, not only in the project you are currently working but also with the way you work and communicate. And if you are lucky as I was, you will find a friend in your mentor.
Once you walked down this path you have several options. You can stop contributing to the project you worked on and continue with something else that you like more, you can keep contributing as a volunteer or you can try to find a full-time job to keep working on it. What you decide is up to you, but at least you have built a strong basis that will be useful in your career.
Personally I feel that I've learned a lot, meet great people and that I'm confident enough to keep digging into the internals of the project I chose. I don't want to settle with the contributions I did as part of GSoC. Once you get to that stage in which you understand the importance of the project and that you can make stronger contributions to make it even better, you don't want to step out of it.
I've been interested in working on Marconi since its beginnings but, because of college, I couldn't find the time. When I heard that OpenStack had been accepted to participate as a mentoring organization in GSoC, I knew that it was my chance. So I went through the tasks suggestions in the OpenStack GSoC wiki [0] and started preparing my application.
My proposal was about developing a new storage backend driver for Marconi. At that moment, I didn't specified which it was going to be, so I make my own suggestions. I considered it was a good idea to wait until the internship period to discuss with the rest of the team which storage backend would fit better the project interests.
Adding support for the Advanced Message Queuing Protocol 1.0 (AMQP 1.0) was one of the options.
Given that AMQP is a standard protocol adopted by other messaging services and would enhance Marconi's interoperability, I decided to start a research on that direction.
It turned out that it couldn't be done with the current Marconi API specs - an extensive description of this can be read on "Marconi to AMQP: See you later" by Flavio Percoco [1]- so we changed directions and currently I'm implementing support for AMQP in the transport side.
Beside this work, I'm also contributing to the CLI for the Marconi client.
I'm expecting to have a basic implementation for both by the end of the release cycle.
If you want to know more details of how this implementations are going, please contact me - vkmc - on IRC at irc.freenode.org in #openstack-marconi.
[0] https://wiki.openstack.org/wiki/GSoC2014 [1] http://blog.flaper87.com/post/53a09586d987d23f49c777bf/
- <strong>This is an incredible opportunity</strong>, you will be able to learn about programming tools and practices used in real world deployments and it will allow you to build the experience and confidence necessary for a future job. It really worth the effort.
- You don't need to be a hacker, you only need to be interested in learning, have an open mind and do your best.
- I can't imagine how would it have been for me if I had not been familiar with the project beforehand. If you can get in touch with the project community and you contribute with a small fix, it will make it easier for you to apply later to GSoC.
- Share as much as possible with your mentor. You have to be certain that you will be working with someone that understands you.
- Interact with the community. Get to know them, it's important. Open source projects work because of their communities.
- When you find a blocker, try to solve it within 30 minutes. If nothing comes up, ask the community for they opinion. If they don't reply, drop your mentor an email and continue with something else to clear up your mind.
- Your contributions are as important as other people's. Review other people patches, submit feedback. You will learn a lot, and also, they will be more likely to review your patches.