Starting with Open Source
For many developers, contributing to open source is one of the most impactful parts of being a developer or in tech. The ability to contribute to high-impact projects which help thousands, even millions, of people build software systems is an amazing thing to be a part of. They also tell me that they’ve grown by leaps and bounds in their skills by working on open source projects.
As a developer who is early in my career, I’ve always had an urge to jump on the open source train and start making contributions. But my main hangup has always been the time it requires. For me, working 8+ hours at my day job as a developer at DigitalOcean is pretty tiring and it’s been difficult to balance adding open source to my schedule while also making time to recharge and relax. Additionally, I’ve found myself floundering a bit in finding which project to contribute to given the huge number of projects out there. And so for the past year I’ve mainly been focusing on my work and have put off diving into open source until “the right thing comes along”.
That perspective changed recently when I met a coworker who had just started on-boarding at my work. He had found his way to joining DigitalOcean through his open source contributions, which immediately peaked my interest. It turns out that while he when he joined his last company he had to switch programming languages, and he didn’t want to get rusty in his prior language (C++). So he looked for an open source project to contribute to and found Envoy, a load balancer created by Lyft that was made open source.
For over a year, he put a few hours a week into working on Envoy which was the only open source project that he contributed to. The project had an extremely high bar for pull requests & testing, and it could take several months for a pull request to be accepted and merged. But through this experience, he kept his C++ skills sharp and leveled up as an engineer until one day he got an email from a recruiter at DigitalOcean. Our load balancer team had an open position and they knew the quality of engineering involved in Envoy, so they started reaching out to contributors, and 2 months later he had joined the load balancer team here!
I thought this was an awesome story and ask for his recommendations on getting started with open source. He laid out several points that I thought were really insightful and should be shared with the Dev community:
Pick just one project. It can seem like you’re limiting yourself, but if you are squeezed on time it’s best to focus the time you have on learning one codebase, it’s testing methods, & how to debug issues. If you’re working on multiple projects, it can be slow to make progress since you’re mentally
juggling several codebases.
Look for a project that is regularly used and has the backing of one or more major companies. These projects will likely have several engineers from these companies that work mostly, if not solely, on the project because it is vital to the company. This means that it will have consistent work done on it.
See if the project has a high standard of engineering. Indicators include rigorous testing, plenty of healthy discussions or debates on pull requests & issues, and an established process for contributing to the project and rolling out releases.
Thinking back on these points, it’s clear that not everyone who wants to contribute to open source will want a project displaying these features. Some developers may want to work on smaller projects or not face so much rigor in getting contributions accepted. Some of us may want to keep “serious work” with our day jobs and work on something more lighthearted, even silly, in our off-hours.
For me, I want to grow my skills as a developer and work on projects that not only demand a level of rigor, but also see a high amount of use. So I started looking around for projects that fit the above points and found several listed below (majority are in Go since that’s the language I use the most):
And with that, I’ve decided that for next year I will pick one project (likely one from the list above) and commit to it for the whole year. I hope that by doing so, I can be able to dive into the codebase and get several contributions accepted in the time I have available. I plan to report back at the end of the year with my progress and thoughts!
What do you all think about the points here that my co-worker made regarding open source? What projects are you currently contributing to and how did you decide on them? I’d love to hear everyone’s thoughts!