When contributing to open source projects and communities, one of the many benefits is that you can improve your tech skills. In this article, hear from three contributors on how their open source helped them get a job or improved their career.

Alexander Yurchenko, a developer at Yandex

By the time I found my first paying job, as an integrated systems developer, I had already been an official developer for the OpenBSD kernel for a year. By “official” I mean that I had write access to the repository. Before that, I spent a year as a spectator, sending patches to developers. Participating in such a project yields colossal experience. A good, large open source project has everything that is typically required from a developer at job interviews: good planning, good coding, use of versioning systems and bug trackers, peer reviews, teamwork, and such. So, after stewing in such an environment for a year or two, you have a good opportunity to grow to a senior developer level.

That is, in fact, what happened to me. I was hired as a senior developer without having any formal work experience on my service record. After the first week, my probation period was reduced from three months to zero.

Kirill Gorkunov, a developer at OpenVZ

You could say I joined OpenVZ by chance. Back then I mostly did application programming that had little or nothing in common with system programming. At some point I got my first 64-bit notebook (an Acer based on AMD Turion 64), and because I didn’t have a 64-bit Windows, I went with Gentoo. It worked more or less, but its standard installation lacked certain drivers so I had to build my own kernel from sources. That was where I stumbled on my first bug (not in the kernel, but in the configuration program). Searching the Web produced no solutions, so I decided to fix the issue myself. To do that, I had to sort out a lot of related tasks (how and with what tools to compile the kernel, etc.). Having made a patch, I sent it to the mailing list. The patch was really terrible (and I remade it later, in fact), but, to my surprise, the mainline/vanilla kernel maintainers were quite benevolent and didn’t refuse or ridicule me. Instead, they explained how to make proper patches.

Then, I started looking into how the kernel itself worked. From this standpoint, the project’s open source nature was invaluable because it allowed me to watch real problems get solved. I often wondered why things were done in a certain way, so the ability to contact code author came in handy. In fact, such open mailing lists not just let you ask questions, they serve as a kind of knowledge base that you can always search for solutions.

All in all, an environment like this is heaven for a newbie coder; it allows them to try their hand at programming and see if it’s worth it.

For a few years, I’ve been fixing the code, sending patches, getting scolded for bad code and complimented for good code. That experience was priceless. And you can be sure that as soon as you get good at it, job offers will follow. This is, in fact, how I met the kernel developers working on OpenVZ. Together, we decided to continue working on the OpenVZ kernel and related stuff as well as the vanilla kernel, of course.

One thing you have to understand is that while a project’s open source nature is crucial in learning how to write code, all projects are different and the openness, in and of itself, doesn’t guarantee that the code is any good. Bad code committed to GitHub remains bad. However, it also doesn’t mean that closed source code is good or safe.

Alexander Polyakov, a developer

I don’t consider my story original in any way. Typically people get involved because they start using a piece of software and realize that it’s buggy or certain features don’t work as expected. If the source code is open, you then have the opportunity to fix it yourself.

This is how it was with dwm (a dynamic window manager for X). I was really annoyed by having to configure it via config.h and recompile afterwards. So, I added configuration via xrdb, then click to focus, and so on. Those changes went beyond project’s minimalistic guidelines so I had to fork it.

The same thing happened with DragonFlyBSD. Texts on their website looked interesting, and I was bored with FreeBSD. Then it turned out that support for languages other than English were lacking, as was support for ACPI. So, I had to port the required parts of code from a newer version of FreeBSD. Fellow developers on IRC were a big help, providing explanations and helping solve problems. There I got some experience in kernel and system libraries development. I even made some money in the process—a customer found me via git log. He wanted to use DragonFlyBSD in production and needed better ACPI support and some RAID driver or something.

Another project I co-worked on was 9front. There I improved the WiFi driver and the already familiar ACPI. That community had probably the smallest working AML interpreter implementation. The kernel was also compact, so it was easier to understand.

In a nutshell, contributing to various open source projects is how you gain great experience. Don’t be afraid to send in bad code (happens to the best of us), keep calm (while being scolded for sending in that bad code), and choose projects you are really interested in. Then you’ll both gain experience and have fun while you doing it.