Zishan Ahmad

Posted on May 14 • Updated on May 16

Code and Community: A GSoC Diary

#opensource #community #gsoc #webdev

Entry 1: The Spark of Curiosity

In my final year, once I got through DSA and placements, I found myself wondering, 'Okay, what now?' With no specific plan in mind, I decided to dive deeper into software development. The idea struck me: why not get involved in real projects? Open source seemed like the way to go. Then, I stumbled upon some exciting opportunities like GSoC and LFX, which only fueled my excitement further, and thus began my journey!

Entry 2: The Quest Begins

It all started with the search for a project aligned with my existing skills. Selecting an organization and project to contribute to was no easy task. Despite exploring platforms like Good First Issue for initial guidance, I found myself still overwhelmed with options.

Turning to the official GSoC organization page, I used keywords to narrow down projects that matched my skill set. There, I discovered some awesome repos like Zulip, OHC, Rocket.Chat, and Circuitverse that seemed promising for my contributions.

Among them, Rocket.Chat stood out as the perfect fit. With its entire ecosystem built in JavaScript, from backend to frontend, it aligned with my interests and what I was looking for.

Entry 3: Setting Up the Stage

After selecting this organization, the next step was to set up the project. It proved to be quite challenging and took me several days to figure out. I diligently read through the documentation and attempted to set it up on my Windows system using WSL. Despite following each step outlined in the documentation, the build consistently failed. It made me lose hope. If I can't even set this up, how will I be able to make code contributions?

Every day, I persisted in my efforts, searching the internet for solutions to the errors I encountered. However, my attempts were met with repeated failure. It wasn't until one day, after a thorough understanding of the error patterns, that I realized the issue might be related to memory limitations on my system. Confirming this suspicion, I found that Rocket.Chat recommends a minimum of 12GB of RAM for setup, while my system only had 8GB, and running WSL on Windows likely consumed a significant portion of available memory.

In a bid to overcome this challenge, I decided to install Linux onto my system. I reasoned that while I would still have 8GB of RAM, a larger portion would be available for use without the overhead of WSL and Windows, and considered allocating swap space as a potential solution.

To my immense relief and joy, it worked! On that day, I was the happiest person alive. Despite the challenges and setbacks, I had finally succeeded in getting the project up and running.

In my view, setting up a project is crucial; it lets you really get to know the project, explore all its cool features, spot any problems or things that need adding, fix them up, and just really start to love what you're working on.

Entry 4: Crossing the Threshold

When I started exploring around Rocket.Chat, I found this little problem: the MultiSelect Component just wouldn't close when I clicked the cross button. Seemed simple enough, so I decided to give fixing it a go. I started by digging into the code, looking around the area where the bug was happening to see if I could spot what was causing it.

Playing with the code and searching for similar content near the bug location provides a good starting point for identifying the problem area and understanding its potential root cause, especially in a complex codebase.

I found out that they were using this fuselage design system for their components, which had its own repository. I was surprised they had a whole separate repo just for components, but hey, that's how it was. So, I set up that project on my system, fixed the bug, and sent in my first-ever pull request. It didn't get accepted in the end due to some internal reason, but it was an awesome experience to write.

I kept on helping out with Rocket.Chat by reporting issues, fixing bugs when I could, and then I started checking out other projects like Embedded Chat (kind of like a smaller version of Rocket.Chat that you can put on any website). This one was much easier to understand. I found a bunch of things that needed fixing, so I fixed them, sent in my PRs, and waited eagerly for review.

During the initial days, it was a little demotivating when my PRs were not getting reviewed. I felt bad about it and sometimes even thought about stopping my contributions, as I had raised so many PRs, but none of them were getting noticed.

Anyway, while I was waiting, I helped out other folks in the community who were having trouble setting up the project. I'd been through a lot of setup problems myself, so I knew how it felt. Eventually, I got to know a bunch of the common issues and how to solve them. I'd chat with people about it and help them get their projects going and make their first contributions. It was fun.

Then one day, the maintainer of Embedded Chat, Abhinav, asked me for help. He said, "Hey, lots of folks are having trouble setting up the project on Windows (it worked fine on Linux, even in WSL). Can you take a look?" It was the first time a maintainer had asked me to look into an issue, and I was happy. I jumped right in and worked on fixing the problem. I stayed up until 5:00 A.M. that night, putting all my effort into it. The issue had to do with how the code handled file paths differently between Linux and Windows, but I managed to sort it out. I sent in the PR and went to bed, hoping it would get merged the next day!

When I woke up, I went about my usual routine, not knowing what was waiting for me. In the afternoon, I saw that all my PRs had been reviewed, and many of them were merged. I realized that to build trust with maintainers, we need to prove our worth by fixing a significant issue first. It was one of the best days ever. I was so happy, just loving every minute of it.

It's essential to first build trust within the community to ensure maintainers feel confident that your contributions won't disrupt the project. Since maintainers are busy and can't review every PR, establishing this trust demonstrates that you recognize the potential for introducing bugs and are dedicated to the project's smooth functioning.

The entire discussion can be found on the thread and my first PR merged here.

Entry 5: Cultivating Connections

Days passed in their usual rhythm as I kept helping contributors, reviewing their code, discussing new features, testing the app to find bugs, and fixing them.

Reviewing others' code is a great way to show love for the project. If you can help others, do not dwell on any notions of competition, just do it. Review their code and ask them to review yours. It helps keep the project clean and reduces bugs.

I enjoyed it a lot, and without realizing it, I made many great connections. I got awesome friends through GitHub and LinkedIn. While I was reviewing someone's code to ensure the project stayed bug-free, Sidharth, another Embedded Chat maintainer, noticed me and said he really liked the authority and love I was showing for the project. We had some great discussions about the project and new ideas.

I also started contributing to an RC app (like an extension to extend functionalities of Rocket.Chat). At first, it was hard to understand, but after reading the docs and attending workshops, I got the hang of it. I tried contributing to Apps.Notion, and Nabhag, the project maintainer, and I had amazing discussions. We talked like friends, discussing general topics, open-source opportunities, and even college life. Nabhag and Devanshu were the ones who helped me a lot in understanding how RC-app works and how different things can be implemented. Combining all of it, I see it as great days building connections.

Assisting fellow community members, chatting with project maintainers, asking thoughtful questions (not lazy ones), sharing ideas on various projects, and making friends through open source are excellent ways to build lifelong connections.

Entry 6: Crafting Proposals

With the GSoC application period beginning, it was time to put my experiences and lessons into words. Rocket.Chat had listed its project ideas on GitHub. As I went through them, I took my time to choose which ones interested me. It took me a few days to settle on three ideas within Rocket.Chat: Embedded Chat 2024, News Aggregation App, and VSCode extension for Rocket.Chat.

I spent time learning about the issues each project wanted to solve. Once I understood them, I thought about what extra features could make my proposals better. I talked about these ideas with friends, chatting with them every day for several hours, sometimes even losing sleep as I made notes of our discussions.

Since I was closely involved with Embedded Chat, I started working on its proposal first. To write my proposal, I looked at other proposals, asked many people, including project maintainers, searched on Google, and consulted friends who were previous GSoC participants for guidance on how to structure my proposal and what to include in it.

I started by sketching out the basics: my personal info, project summary, and such. While I worked on it, I wanted it to look professional and be easy to spot among the many proposals. I even matched the colors and icons to those on GitHub and Rocket.Chat pages, checking the HTML elements, extracting out the colors and SVG icons to make sure they were right. These details might not have been necessary, but I wanted my proposal to stand out in every way.

After setting up the basic structure, I started developing and coding prototypes for each feature. This aided me in gaining confidence in my ability to execute the proposed plans, as well as in giving my mentor confidence that I can build on what I am proposing. Using Figma for the first time, I created designs aligned with the proposed features.

Discussions with Sidharth, the project mentor, led to expanding the initially scoped 90-hour project to a more comprehensive 175-hour one. Thanks a lot to him for being so receptive to new ideas, like developing themes for Embedded Chat and integrating an in-app UI editor.

I regularly interacted with him, showcasing every prototype and discussing implementation details.

Next, I began working on a VSCode extension for Rocket.Chat. It was tagged as a "Hard" project, which often makes people less eager, as seen in the low enthusiasm in the project channel. However, I really liked the idea for that project. It took me many days to understand how an extension is made, spending sleepless nights implementing most of the important features for it. It was surprising to find that I was the only one who built and showed some prototypes for this project. The project prototype can be found here

Extending a similar effort to the final project, the News Aggregation App, I started learning about RC app development in depth by reading the documentation and seeking help from mentors, especially Nabhag. I successfully implemented most of the important features as prototypes. I wrote my initial ideas into the channel, discussed with Abhinav, asking for feedback. He suggested many improvements as well, all of which I implemented. He also really loved my proposals while reviewing. Recently, Sing Li also featured this project in a contributors' meeting, proposing to use this repository as a foundation to implement various features into their RC apps.

Writing three proposals with all features implemented as prototypes was no easy task. I wrote around 100+ pages and 8000+ lines of code. For a few days, my fingers were not responding properly and were in pain.

But my hard work paid off, as reflected in both the crafted proposals and my contributions. Securing the top position in the leaderboard was proof of this dedication.

I'm grateful to Sidharth, Abhinav, Nabhag and Debdut for their valuable feedback on the proposals, and to Sing Li and Devanshu for their thorough review of the proof of concepts (POCs) and insightful suggestions for improvement.

Looking back, it was a challenging yet rewarding journey. With all proposals submitted before the deadline, I felt a sense of fulfillment and looked forward to what came next.

If anyone is interested in reading my proposals, they can find each of them here.

Entry 7: The Wait!

After wrapping up my submission, I felt a sense of relief and took a few days to catch my breath. Then, I dove back into contributing to various projects. As the end-semester approached, I got occupied with exams and completing assignments. Once everything was done, I found myself in a phase of waiting eagerly for the selection results. During this waiting period, I took the opportunity to relax and hang out with friends and family, enjoying some leisure time.

Entry 8: Result Day

After days of hard work, the moment to see if I made it finally arrived. I felt confident about getting some projects but also had a bit of anxiety lurking within. I eagerly awaited to learn which project I'd be a part of. Around 11:30 PM IST on May 1st, I began incessantly refreshing my emails. There was a slight delay, then I received an email saying my proposal wasn't selected. It was disheartening, feeling like a blow to the chest. Another email confirmed the same for my second proposal. I figured they were sending rejections proposal by proposal. Hoping and praying, I waited for the final email. When it arrived, it was the news I'd been hoping for - my proposal for the Embedded Chat 2024 project had been accepted! I was overjoyed, sharing the news with friends, family, and mentors. Their congratulatory messages filled me with warmth. Now, a new chapter begins as I dive into working on the project and making it shine.