An Open-source Adventure
Before I got into software development I imagined an open-source software community as an MMORPG (massively multiplayer online role-playing game). Developers, just like the gamers of these vast, online worlds, would seek out quests and adventure, solving riddles of code to better the world. Some would team up to take on these adventures together, and some would act as a lone wolf type. Completing these quests would level up their experience so they could take on tasks of increasing difficulty.
This analogy seems accurate, having successfully completed my first open-source contributions as a student at Turing School of Software & Design.
Most MMORPG’s, like World of Warcraft or Runescape, start the same — a new avatar in an expansive, unknown world with no tools, a confusing map and an open ended path to level up your character. I found myself in the largest codebase I’d ever been in using a variety of new technologies I had never heard of, such as Redis and Zeus, and my guide around the application looked like this:
Despite the daunting task ahead, I had an invaluable weapon — my team. We each had built a few React applications, and were able to track down some issues pertaining to the library. However, just like our low level video game avatar, nearly all the tasks ahead of us involved more experience and new tools than we could wrap our heads around.
We installed the application our on local machines and began to explore GitHub issues. We knew there was a maintainer of the codebase, and began to see how they were interacting with other developers all over the world on this project. Our maintainer was an invaluable guide to finding problem we could solve, and we found an issue they had marked as newcomer friendly. Our team was brand new to the world of open-source software, so we asked our maintainer if we could tackle the issue. Permission was promptly granted.
Being new to the project, we started small. Our task was to remove linter errors. Linting is essential to any large application as it maintains consistency in your code base by enforcing rules about syntax and formatting, ensuring that no matter who is writing code the result will be consistent. The project we were working on had adapted the Airbnb style guide for consistent code, but had many of these rules overridden in the linter configuration file. Removing a rule would result in errors upon running Gulp (a toolkit used for building your application) from the root directory.
By removing overridden rules and examining the errors, we explored the React side of the application and began to understand how the whole thing worked. Suddenly, this daunting world we were working in seemed at least a little familiar, and the subtle but important ways we could improve it began to come into focus.
We found a rule and we fixed the errors in the handful places of were triggering linter errors. Working in a large and complex codebase meant that even a small change could have big implementations throughout the program. This is the importance of a testing suite. My team and I had experience with test driven development using the Jest, Enzyme and Chai libraries, and we were able to ensure that we hadn’t seriously broken anything from our changes. We submitted a pull request to the maintainer, and hoped that we didn’t make fools of ourselves.
An email arrived within a couple hours, and we learned that our mission had been a success. We felt like the heroes of an epic journey.
The quest to fix linter errors continued, with some of our pull requests merged into the production application, and others rejected. Through removing errors, we were able to touch a lot of files and the mechanics behind the platform were less of a mystery.
Unfortunately our journey had to come to an end. The Turing curriculum moves fast, and we were beginning to start projects building progressive web application and our own APIs. Ultimately, working in an open-source project boosted my confidence when it comes to working in unfamiliar codebases, and made me more familiar with the processes it takes to prepare a complicated development environment.
I plan to continue to contribute the the Wikipedia Education Dashboard. When testing that our changes hadn’t broken any part of the system, we learned about test coverage, which measures how much of the application is tested by percent of statements, lines, functions and branches. There were holes in the test coverage, most dealing with React functionality, that I now feel confident I could tackle. Additionally, I would like to learn where I can help in adding to the project’s documentation. Improving the navigation and installation of the application can make a large difference to an open-source project, as the ease of installation lowers the learning curve of getting your first contribution merged in.
The most important thing I learned from contributing to an open-source project is how new developers can as a sentinel species to a project. The most common example of a sentinel species is the canary in a coal mine — the canary is used to detect dangerous levels of carbon monoxide before humans can. As a new developer, having the ability to recognize where the process is confusing and unclear can help uncover blind spots in large applications, and learning how to share that information and contribute to the process of an evolving project has improved my confidence and knowledge around working in large applications.
