Coding all summer long in OpenStack

What it takes

Participating in an internship such as GSoC will allow you to learn about the latest technologies and to contribute to an open source organization project you choose. Every project is different, so the previous knowledge you 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 need 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 is 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. Finally, you have to start working on your contribution—and 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 collect all the resources you can find—and make your own decisions—it is better to be wrong about something and then fix it with the feedback submitted by the reviewers, than to waste time poking people to ask their opinion on a subject they may not be so familiar with.

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 found it difficult to work on the feature I was assigned.

Confronting blockers

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 tends 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 do you 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 these 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.

Working with a mentor

I want to emphasize how important is to find a good mentor and to get along with them. The human part of these internships are worth discussing 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 speed on 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 of their 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. On the other side you have a person with your same interest, but with a wider experience, one that can help you improve a lot, not only on the project you are currently working on, but also with the way you work and communicate. And if you are as lucky as I was, you will find a friend in your mentor too.

What to expect after the internship

Once you have 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 to do 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, met great people, and 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.

Working on the OpenStack Messaging Service (Marconi)

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 task suggestions in the OpenStack GSoC wiki and started preparing my application.

My proposal was about developing a new storage backend driver for Marconi. At that moment, I didn't specify which it was going to be, so I made 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 research on that.

It turned out that it couldn't be done with the current Marconi API specs—an extensive description of this can be read in "Marconi to AMQP: See you later" by Flavio Percoco—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 command line interface and adding support for the API v1.1 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 these implementations are going, please contact me: vkmc on IRC at irc.freenode.org in #openstack-marconi.

In short

• GSoC is an incredible opportunity. 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 is 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 it would 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 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 their 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.

Read more articles like this one about young professionals in open source.