Hi! My name is Peter, and if you don't know me, I'm a computer science student, currently taking Professor David Humphrey's Topics in Open Source 2024 class.

Since September of 2024, I've been working to build my presence in the open source community. If you'd like to follow my journey, you can find me on GitHub:

peterdanwan (Peter Wan) · GitHub

Full Stack Developer | Games and AI Enthusiast - peterdanwan

github.com

With my final semester and the Topics In Open Source course coming to an end, I want to share my progress as a budding open-source developer and my roadmap for future growth.

Where I'm at right now

Let me start with one key realization: I have a lot to learn. If you'd asked me at the start of the semester what I needed to learn, I would have said "Everything!"

Now? I'd say "Enough to get the job done."

As I near the end of both this course and my final semester, I'm incredibly grateful to have taken Topics in Open Source. Without it, I wouldn't have gained nearly as much practical experience with Git and GitHub. After months of hands-on work, I can confidently say I've mastered many aspects of these tools.

However, open-source is more than just Git and GitHub.

To me, Git and GitHub are just a means to an end of understanding a code base. With regards to Git, I no longer have problems with creating branches to work on, navigating between branches, resolving merge conflicts, rebasing my branch's commits onto the current changes on the upstream main branch, squashing commits, testing code on different branches, etc.

I'm pretty happy to say those things are second nature now! But once again - to me, Git and GitHub are just a part of what it means to be an open-source developer. Let me tell you how I want to improve as an open-source developer.

How I want to improve as an open source developer

Remember when I mentioned knowing "Enough to get the job done"? Let me show you what that actually means through my recent pull request for expressjs.com.

Understanding the project's scope

First step: understanding what I'm working with. expressjs.com is the official documentation site for express, one of the most popular web frameworks for Node.js. While this was quick to grasp from their beautifully designed website, the journey was just beginning.

Express - Node.js web application framework

Express is a fast, unopinionated, minimalist web framework for Node.js, providing a robust set of features for web and mobile applications.

expressjs.com

Understanding the issue at hand

After getting familiar with the project as it is, I looked for an issue I could tackle. I found this one:

Broken link and missing page #1684

chrisdel101 posted on Nov 17, 2024

The following links are broken _includes/header/header-id.html

• <a href="/{{ page.lang }}/changelog/4x.html">Release Change Log</a>

_includes/header/header-th.html

• <a href="/{{ page.lang }}/changelog/4x.html">บันทึกการเปลี่ยนแปลง</a>

Suggest change to: <a href="/en/changelog/">Release Change Log</a>

Missing page causes console error in UZ language: /css/langs/uz.css

Suggest adding this page.

View on GitHub

I chose this issue because it involved HTML and CSS - technologies I'm comfortable and familiar with. However, what looked simple actually taught me an important lesson about open source development:

Even familiar-looking tasks can involve unfamiliar territory.

The repository used technologies I'd never touched before, and that's where the real learning began. It took me about an hour just to decide whether to attempt this issue - maybe too long in retrospect. I was hesitant because the project used Ruby, which was completely new to me.

Spoiler alert: Setting up Ruby was... an adventure.

Understanding how to setup the project locally

Setting up your local development environment is often one of the most educational parts of an open-source contribution.

I learned a little about Ruby and Jekyll, simply by trying to run expressjs.com locally.

Here's how my journey unfolded:

1. Initial Confusion: I started by installing Ruby directly on Windows. While it worked, it wasn't ideal, because I was having problems with the version I installed being different than the one used in the project. Version management on Windows was not fun. As such, I uninstalled my installation of Ruby on Windows and its other dependencies and looked for an alternative solution.

2. The WSL Discovery: My research led me to the conclusion that I should run Ruby on the Windows Subsystem for Linux (WSL), since it offers a much better development environment and access to the powerful Ruby Version Manager (RVM), which would allow me to work on projects that use different versions of Ruby. To me, installing RVM was a very similar feeling, since I use nvm-windows to allow me to switch between different node versions.

3. Version Management Learning Curve: Once again, I learned about RVM and its similarity to Node.js's nvm. This taught me the importance of version management in development environments.

Below are the actual commands I used to get my development environment ready:

## 1. Installing RVM (Ruby Version Manager)
# First, import GPG keys needed to verify RVM installation
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

# Download and install RVM
\curl -sSL https://get.rvm.io | bash -s stable

# Verify RVM is installed and get its path
which rvm

# Load RVM into your current shell session
source /home/peter/.rvm/scripts/rvm

## 2. Installing Ruby
# Install Ruby version 3.3.5 (latest stable as of early 2024)
rvm install 3.3.5

# Set 3.3.5 as your default Ruby version
rvm use 3.3.5

# Verify RVM and Ruby installations
rvm -v
ruby -v

## 3. Setting up Jekyll
# Install Jekyll and Bundler gems
gem install bundler jekyll

# Install project dependencies from Gemfile (must be within the target directory with the Gemfile)
bundle install

# Start the Jekyll server with live reload and external access
# --host 0.0.0.0 allows access from other devices on your network
# --livereload automatically refreshes your browser when files change
bundle exec jekyll serve --host 0.0.0.0 --livereload

Tackling the issue

With my development environment configured, I was able to begin addressing the issue at hand, that is to simply update the
anchor tags containing broken links to an English version of the link (since the English version of the link isn't broken).

That was the easiest part of this whole contribution.

I also made sure to look at some logs to see if there were any errors to fix. I suggested adding another file css/id.css, which follows the same
coding format of files that were added already, since I had an inkling that would resolve some of the error logs.

One of the maintainers of expressjs.com Chris Del, provided very immediate feedback stating that was the thing to do (thank you Chris!).

As such, I also added this change to my pull request.

Waiting to merge changes and learning to get involved with discussions

With that said, the changes I have made are now waiting to be merged into expressjs.com's main branch.
A follow-up issue was made to discuss the standards of the expressjs.com website. That is:

should a user be redirected to a working English page than to a broken-link in the correct language?

That is not up to me to decide, but I wanted to be part of the discussion. You can follow the discussion over here.

Learning to Grow as an Open Source Developer

What started as a simple HTML/CSS fix turned into a journey that taught me valuable lessons about open source development:

1. Stepping Out of Comfort Zones: While I chose an issue that involved familiar technologies (HTML/CSS), I ended up learning an entirely new tech stack (Ruby/Jekyll). This taught me that growth happens when we're willing to tackle the unfamiliar.

2. Technical Growth: Setting up development environments, managing versions, and working with new tools are all crucial skills. Each challenge makes the next one easier to approach.

3. Community Engagement: Through discussions like the language redirect discussion, I learned that open source isn't just about code - it's about participating in meaningful discussions that shape project decisions.

Looking ahead, I plan to improve by:

• Taking on increasingly challenging issues
• Learning to work with different tech stacks and development environments
• Engaging more actively in project discussions and decision-making
• Contributing to documentation and helping other newcomers
• Building relationships within open source communities

Most importantly, I've learned that being an effective open source developer isn't about knowing everything - it's about being willing to learn anything. Every contribution, no matter how small, is an opportunity to grow and make a positive impact on the projects we care about.

If you're considering getting involved in open source, remember: start small, be curious, and don't be afraid to learn as you go. The community is here to help you grow.