I first encountered and started working with Backend.AI through the 2022 Open Source Contribution Academy (hereafter OSSCA). After the program, I wanted to get more seriously involved in the project, so I applied for the OSSCA corporate-linked internship and had the opportunity to intern at Lablup for about two months. In that process, it wasn't easy for a beginner who had just set foot in such a large project to contribute code. Nevertheless, I want to talk about the contribution experiences I was able to accomplish little by little and what I gained from them.

Technical Challenges

Onboarding

The first hurdle in contributing to the project was onboarding. Since I had participated in the mentoring program with the Backend.AI team during OSSCA, I thought I could start the internship with a decent understanding of the structure. However, there were so many new things to learn that what I had seen so far felt like just a tiny fraction of the whole. I understood the role of each component, but the variety of technologies used within them made the code difficult to read. Around the time I was feeling this way, I was given an assignment as part of the onboarding process: to write an asynchronous web chat program. So, for about a week, I worked on the assignment using several tools like Python asyncio, aiohttp, and redis. In the process of trying to use the tools employed in the project, I naturally started to gain an understanding of them. Based on what I learned from the assignment, I was able to read the base code and understand its role.

Setting up the development environment

The second hurdle was setting up the environment. I had experienced this during OSSCA, but I inevitably faced it again during the internship. To contribute code, you always have to work with the latest version, not a stable one, so even if you set up the environment properly once, you might face new errors during an update. However, there was an area where I had improved. Before the internship, if an error occurred, it was difficult to figure out when and where it happened. But now, after learning about the libraries, tools, and technologies being used, I could identify which component's function was failing or where a conflict was occurring. To use an analogy, if before I didn't know what to do to untangle a knotted skein of yarn, now I felt like I had learned how to find the beginning of the tangled mess and unravel it bit by bit.

Tasks

Good first issue

After the onboarding period, I was assigned about three issues that are often called "good first issues," which are simple and don't require extensive work. One of them was to implement the 'feature to selectively load plugins,' which was already implemented in the agent, on the manager side as well. So, I started to break it down step by step. I looked at what the TOML-formatted configuration file could pass, at what point it was loaded into memory, and where type checking was done. I also referred to issues and code written by others to understand the logic for how plugins are loaded and blocked, and then I gradually wrote the code, contemplating how to apply it to the manager side. Since Backend.AI is a real product in use, I was very cautious at first, even when writing a single line. I was very concerned about whether there might be better code than what I wrote, or if it would be difficult for others to read due to poor readability. However, as I worked on this issue, I inserted my own code into hundreds of lines of existing code, and I revised and improved the code based on the code review. Going through the entire process up to the merge made it feel much more natural.

Monitoring

After finishing the "good first issues," I was looking for what I could improve next. I saw an issue about improving the monitoring-related infrastructure and found it interesting, so I chose it as my topic. Before my internship, when I imagined working in the field, I used to picture someone whipping up amazing and complex code in a flash. But in reality, a significant amount of time is spent reading existing code to understand its context or researching and studying the technical aspects used in that part. I also spent a lot of time researching the monitoring infrastructure and reading the existing code for my newly chosen issue. After that process, to monitor the resource usage of processes, I wrote agent backend code that gets a list of processes running inside a container using cgroup or the Docker API and collects metrics for resource usage like CPU and memory using third-party modules. The amount of code and the logic to be written became larger than expected, so I repeatedly contemplated how to integrate it well with the existing infrastructure, and later I made revisions based on the reviews I received. In that process, my interest in program monitoring deepened, so I later created and sent a PR for code that monitors the resource usage of Kubernetes nodes in the agent, a topic that wasn't part of an existing issue.

Conclusion

The simple yet profound insight I gained from my internship and direct work experience was: "In the end, good code is not written by struggling alone!" No matter how much you think or research, the code written by one person ultimately stays within that person's perspective and field of vision. Even a program written by a true genius is bound to have errors. The process of communicating with other colleagues, sharing opinions, and filling in and improving what was lacking is necessary. I believe this is why code with good readability is emphasized. This reinforces the idea that you should write easy-to-read code so that both you and others can continuously develop the program, and that even a raw idea or code that might be a bit embarrassing is improved when it's the result of seeking help from colleagues and creating it together.

For me, as someone who was experiencing their first job, Lablup was a surprisingly horizontal and communicative place. Through daily all-hands meetings, everyone could learn about the company's business progress. When a problem arose, people helped each other and suggested new ideas to improve the situation via messenger, regardless of their position. I think that being able to participate in a project and work together in such a place for two months was a very precious and valuable experience.