Why should you join the open-source community?
The goal of this article is to encourage people to join the open-source community. You will join me on the road to my first contribution and a story behind it — how a code review mistake led to the world of open software and back to tell the story and share personal take-aways.
Enjoy!
Open-source
Open-source software is a common way of thinking and collaborating in the creation of new software. The basic rules are transparency, cooperation, keeping promises, inclusiveness and a community-based approach. One of the well-known examples of open-source projects is Ubuntu — a fully open-source Linux operating system used on both servers and desktops around the world.
The open-source software community connects people from around the world. Some people are putting their first coding steps here. On the other hand, seasoned veterans continue contributing and help junior members getting up to speed. You can find side projects with a single developer and the ones supported by top technology companies with huge budgets behind them. The big companies need commercial support for all software they use, even if it is open-source. There are companies actively developing open software projects and providing commercial support for them. The world of open-source software is enormous. It runs most of the world’s IT projects. Every one of us got to use it at some point — knowingly or not.
Motivation
Few times in the past I wanted to contribute to one of the projects used frequently by our team. There were always some “obstacles” — high learning curve, project selection or leaving partial work to jump onto a new pet project. This time, the story started with my mistake, which gave me additional motivation to deliver the resolution.
Just a few days before this publication my PR (Pull Request) was approved. Pull Request is a way to ask to merge your code into the main codebase. It is a good way of reviewing the implemented solution. Pull Request approval means that my code changes became part of the main codebase and were released as a new version. It’s a success!
Task at hand
Before the Story begins we had a task — a day like every other. The task was to automate infrastructure creation in the AWS cloud. We wanted to deploy a new AWS Lambda function for the NLP project. The function will translate a text to English for further processing. The python code was ready and we wanted it to be on production as soon as possible. With DevOps principles at heart and automation on our minds, we created all infrastructure using Infrastructure as Code tool — Terraform. It offers plenty of modules ready to be used by developers. The module is a reusable piece of code — few lines of code instead of hundreds. Most of the modules are open-sourced. We wanted to use the aws-lambda-module to deploy AWS Lambda from Python code. This way operations like code packaging and uploading would be handled by it.
Story begins
This story could only happen on Monday morning.
I did a code review for a junior member of the team. Screening through code took me more time than expected. I was pretty sure that the module provides single line build and deployment using Docker Images functionality. I was dead wrong — she was right and confronted me with it. Thank you! Our discussion led us from code review findings to the fact that both of us wanted to have this functionality in this module.
The solution came to me suddenly — why don’t we implement it ourselves. The code was stored in the Github repo and actively developed by Anton Babenko and fellow maintainers. In the repository, there is a contribution guide helping newcomers. It can point you to how to propose a functionality change and which tools to use when implementing it. The first step was to create an “Issue” describing what we would like to have in the proposed change. The template of it was quite big, but feel free to remove all sections that you do not need. This is a helper not a gatekeeper for your initiative.
The issue was posted at 12:36. I have never thought that just after lunch the answer will be waiting for me in the mailbox. It contained a detailed description and a code example. Smooth start created a great, long-lasting impression for the project and was encouraging. After exchanging few messages I was ready to jump into the code. This is what developers love the most!
Implementation
The first code “try” was not in line with what we discussed (and it was not working properly for all cases). The feedback was crushing — this is not what is needed in this module and it impacts too much the rest of the code. It was backed with arguments, comments and a code sample. The adjustments proposed made the solution much simpler and solve the problem completely. I had to redo the code. The first time you got rejected might be hard, but do not get discouraged — keep on going!
In most projects during daily work, you call people directly and talk for extended periods. In an open-source project, like in distributed teams, most communication is done via PRs, Issues or messages on Slack. This teaches you how to phase your intentions in short written messages. You need to contain all the needed information inside of it. What a valuable skill in today’s remote-work world!
Implementation again
After few iterations, the code was improved into a satisfactory state. Checking manually if your recent change did not impact the rest of the system, every time you add few lines of code would be cumbersome. Automation is a key here. It improves contributor experience when cobbled together with good documentation of the contribution process and makes people want to get involved more.
In my case, a single line in the shell tested the whole solution, generated documentation and format properly all files. Less manual, fewer errors, more time for valuable contributions!
Pull Request
When you submitted your PR, do not get discouraged that it could be left without being taken care of for some time. My PR waited for 7 days after that it was merged and the new version was released in a single day. In many projects reviews are done every few days before a new release is prepared.
After our code was shipped as a released package we updated our project’s codebase. We used newly introduced code same as the rest of the open-source project. That felt great!
Summary
You have joined me on my way from a problem to a contribution to the open-source project. The journey was fun, challenging and taught me new skills.
This was not my first try to contribute to an open-source project. Based on past experiences and present success my advice for beginners would be to select a project carefully. You will be looking at it for some time. Go for the project you use frequently and is actively developed by a rich community. The most important, do not give up — there are lots of kind people who will help you on the way.
Personal takeaways:
- new tools and approaches
- good practices
- in-depth knowledge of the used module
- harness fear of exposing my code
The same you can gain by contributing yourself!
Next time you do not find functionality in your favourite open-source library, implement it yourself and share it with others!
One of the sources that can help you before starting the contribution is https://opensource.guide/how-to-contribute/. The guide is describing many possibilities and ways to contribute to an open-source project. Coding is not your only option!
I would like to thank everyone who is contributing to open-sourced projects. You are all helping the world move around!
For MLOps Hands-on guides, tutorials and code examples, follow me on Medium and contact me via social media.
