From Code to Community: Collaboration in Open Source

Hello, and welcome to my blog! Today, I wanted to talk about how my partner in code, Aryan Khurana and I helped each other become better open source developers through different modes of communication and collaboration. Specifically, Aryan and I had a chance to work both synchronously and asynchronously when working on our open source projects.

Aryan and I are both software developers at Seneca Polytechnic and are taking Professor David Humphrey's course on Open Source Development.

This week's requirements were fun to work on, but were also quite challenging.

Each student in our Open Source Development class, including Aryan and myself, was tasked with:

Creating a working copy of a command-line tool that gets an LLM model to provide some type of useful information.
- The source code for my command-line tool, gimme_readme can be found here
- The source code for Aryan's command-line tool, github-echo can be found here
Creating at least 3 GitHub issues on their partner's repository.
Resolving the 3 GitHub issues that our partner made for us.
Writing a blog explaining our development process of our command-line tool and how to use it
- See my gimme_readme 0.1 release blog
- See Aryan's github-echo 0.0.1 release blog
Writing a blog pertaining to our experience on collaborating, our understanding of our partner's code, the issues we filed, and our preferred mode of collaboration after having completed some open-source development (i.e., synchronous vs. or asynchronous)
- See Aryan's experience blogging with me here (he was very nice, you should give him a follow)!

Learning about Aryan's tool gh-echo

Aryan and I share a passion for learning, and if there's anything we have in common, it's that we both learn extremely well through teaching others and by seeing multiple examples.

We collaborated frequently over Discord, to demonstrate our code, and to discuss key points of each other's project.

Both Aryan and I wanted to ensure that our code could run on multiple platforms and that our code would be easy to access. For Aryan, this meant getting his github-echo project published to the open-source Python registry, PyPi.

Since Aryan has his code published to PyPi, downloading his CLI tool is as easy as:

pip install gh-echo

Aryan has unique steps to saving the environment variables needed for his program to run, for each operating system.

While Aryan is on Mac, I am on Windows the instructions he published seem to work for me now (though this wasn't the case earlier on in development). Nevertheless, I got to say good job Aryan :D!

Before Aryan's code was published to PyPi (that might have been at least 50 commits ago!), I had filed some GitHub issues to ensure he had some ideas on what to work on next, and in a similar vein, he filed issues so I could have some ideas on how to progress.

Filing issues for Aryan's code

Both Aryan and I focused on making our repositories easier to contribute to. As such, we focused on filing issues that when completed, would make it easier for others to contribute to each other's code bases.

The first issue I filed was an optional feature that could be added to his tool to meet one of the requirements we needed for release 0.1.

The second and third issues that I filed for Aryan in hopes of making his project easier to contribute to:

In response to one of the issues I filed, you can see that Aryan was quick to make a git branch pertaining to the issue.

After adding the fixes to an issue branch, Aryan made a pull request to the main branch, and closed the issue.

All in all, Aryan is well-organized with his usage of Git and GitHub!

Responding to Aryan's issues for my code

On my end, Aryan also filed several GitHub issues:

You can see the similarities in our issues. We filed issues that would help our development overall as well as filed issues to meet the requirements for the specs of our 0.1 Release. This similarity in issue filing was ultimately due to our synchronous communication on Discord.

While I addressed the issues that Aryan suggested, I had some pre-existing branches where I had already begun development, and closed out his issues after merging my changes back into my main branch.

One of his suggestions to publish gimme_readme to the npm registry was only done after my code was successfully publish.

My thoughts on Synchronous vs. Asynchronous communication in Open-Source

Let's start by saying this. My opinion is that Synchronous communication is the quickest way to get things done (this is precisely why many businesses have call centers to get things done), but this does not mean I dislike Asynchronous communication; in fact, I think it's absolutely necessary to have Asynchronous communication since I believe it to be a bigger driver in getting more people working on an open-source project.

I found that working with Aryan synchronously made it easier to address what we needed to complete and to feel less overwhelmed with learning all the different tools and technologies of each other's projects. Being able to quickly tell each other where we're stuck at helped speed up our development times at the present moment. That is the benefit of synchronous communication, we can address a few individual's issues on the fly.

That said, being able to communicate asynchronously is valuable, because there will be times when you simply cannot communicate synchronously. In such cases, you need to be able to communicate asynchronously in an easy-to-understand fashion.

For example, while I said that I was able to make Aryan's code work earlier, I initially struggled with installing his code (to my fault, I had not gone through his documentation from start to finish). However, Aryan, being the good developer that he is, saw that perhaps the point I was stuck at would be hard for other developers to digest as well. As such, he's stated he would make an attempt to improve his documentation further.

Aryan's documentation serves as an asynchronous mode of communication/collaboration where, others can try to pick up his code and battle test it in their own time by following his instructions. I would say that if we improve the asynchronous mode of communication, we can get more people contributing to his project, and lower the need for synchronous communication.

But when the need arises and we need to communicate synchronously, we will be able to get the job done faster than if we relied on asynchronous communication.

Conclusion

In conclusion, this week was a really good learning experience. Outside of creating our own command-line tool, we got to use GitHub in a way that facilitates open-source development (i.e., make issues, making branches for issues, and merging feature/issue branches back into our main branch).

The opportunity to get feedback through GitHub issues, has given us an opportunity to learn how to adapt to the needs of our partners and to our community. Learning how to give feedback and learning how to take feedback will help us make each other's code easier to contribute to, which will facilitate better open source development.

In the future, I look forward to creating commits in our forked repositories and attempting to get these commits merged into to the main branch of another's repository through a pull request.