10 reasons why contributing to open source is better than an internship

College students often look for internships. Here in India, these are typically for 5-6 months (one semester - required for the degree) or 2 months (if done during the summer)

While some organisations have limited slots available for the former - a lot of students still struggle to get one. The latter is actually quite difficult to find - mostly because there’s not much someone can get done in 2 months without costing the organisation a lot (in $ and time).

I believe it is better for students to instead use the time to contribute to an open-source project, than go hunting for internship opportunities.

All the skills that you will learn while working on an open-source project are directly transferrable to an organisation and will make you effective and productive much faster than your peers. And you know what they say about first impressions - right? So why not jump-start your career by working on and contributing to an open-source project.

Here’s how it will help -

1. Choice of project

At most organisations, you won’t be given an option to choose the project. With open-source, you have a HUGE variety of projects to choose from. So why not choose a project/technology/language that you are interested in? It could even be a tool or software that you already use!

2. Version Control

Version control in a professional setup - an organisation or an open source project - is critical and I doubt there’s any organisation that doesn’t have it in place. For open-source projects, it is the core part of the collaborative process. But college students typically don’t use or require it if all they do is short, throw-away programming assignments. Thankfully, this is beginning to change with the advent and popularity of GitHub and students are using this while in college itself.

3. Navigate a large code base

Sir, where can I find main() in the code?

A fresher once asked this question to a colleague of mine. He wanted to read the code starting from main(). The question was honest and well-intended. But, as we know, it’s not possible to do this with most code bases that you get to work on in organisations because of the sheer size of the code base.

You have to necessarily use tools like ctags, cscope, opengrok or IDEs to navigate around.

A lot of open source projects’ code will also be reasonably big in size (at least compared to the short programs students tend to write in college), so it’s an opportunity to learn these tools and skills that will be relevant when you start your career.

4. Learn to find and isolate areas of code

Related to the previous, to troubleshoot and debug the first step is always to localize the area of code that you need to look at. And this is a skill that comes with practice - how to quickly identify the potential area of code to look at from amongst the ocean of code.

A must skill in an open-source project or in an organisation.

5. Read code ‘coz there’s no documentation

Most organisations hopefully will have some documentation - spec, design etc. However, even if they do, code changes fast and documents almost never keep up. So you have to read the code as the single source of truth. How does a feature work? Read the code and figure out!

Guess what? Open-source projects are no different - they have even less documentation than organisations. Get all the practice you can!

6. Community Interaction

When you try and contribute to open source, you may get feedback from the community. While most projects will try and be nice to you (a lot of projects even have a code of conduct that requires this), you may still face brickbats or curt replies. That’s practice to develop a hard shell and not take it personally.

A valuable skill in an organisation and in life.

7. Write better - emails and docs

While progressive organisations have probably moved on to Slack et.al., email is still prevalent and relevant. You need to learn how to write emails that communicate effectively but succintly. How to write a good subject line. Etiquettes regarding to: and cc:. Format the body of the email correctly e.g. using mono-width font for code/log snippets. End with a call to action - indicating if something is expected from the recipients.

Most interaction on open-source projects happens over the mailing list or in bug reports. So you get to practice your writing skills.

As any writer will tell you, the only way to be a better writer is to write more. And that’s true for emails too! And as you will discover - being a good communicator is sometimes even more important than your programming chops.

8. Showcase your work publicly

When an internship ends what you have usually is a short section in your resume describing the project. But access to any docs, code etc. cannot be shared because it is proprietary. So any future recruiter has only that short blurb in the Resume to look at and make a judgement on.

With open-source projects, all your work is in the open for anyone to view allowing them to make better and more informed judgements on your actual work. So if you did a good job and are proud of the work, showcase your work by including a link to the project and your contribution.

In the US including your GitHub username in your Resume is almost required these days especially for entry level positions.

9. Gratitude from the project maintainer

Open-soure project maintainers are a harried lot, buried under ever-piling mountains of bug reports and feature requests.

They will be thankful for any contributions that you make. Just be mindful of the fact that you may fix a bug or develop a feature for the project, but in all likelyhood they helped you by answering your (multiple) queries, reviewing your code etc. - all of them things that take non-trivial amounts of time - the one commodity that maintainers have in limited supply.

The most important thing you can do to justify their time investment in you is #10

10. Continue to work on project

Once the internship is over, you no longer have access to the code or organisation. Not so with open-source projects. You can continue to work on the same project - new bugs or new features and become a regular contributor to the project.

Being a regular contributor is not just a big boost to your credibility (and Resume), but it also means you get into the habit of Ship early, ship often - a trait that organisations love (but hinder with their process overhead)

Convinced?

Good!

Where do I start, you ask?

Start with finding your first open source project or bug to work on or open-source friday