Introduction to Open Source
Arguably one of the greatest benefits of working in the tech industry is the collaborative nature that permeates the community within open source projects. While this leads to better projects, it can be daunting for Junior Developers and beginning coders to jump into repositories with much more “developed” developers.
So what is it like to be a Junior Developer and jump into an open source codebase? It is a lot less intimidating than I initially thought. Since the tech community so often contributes to open source projects, they are ready and willing to receive pull requests, issue submissions and questions.
The difficult part actually came from jumping into another project partway through. There are so many different frameworks, libraries, and languages and any of them can be used in an open source repository. There can be problems with installing the packages necessary to make the application run correctly and, worst of all, documentation can be spotty or non-existent. These things are good, though. What better way to understand what does and does not work in regards to instructions in a README? The things that were so obvious to you that you didn’t take the time to write them down might be something that makes setup that much easier for someone trying to contribute.
We were lucky in that our README was incredibly specific, well laid out, and honest. They mentioned that they did not have everything tested, so instead they wanted users to go to specific endpoints and make sure that information was there. Is this as good as testing everything? Of course not. What it does instead is point to the fact that no code is perfect and that openness and honesty allow users to feel more comfortable and the codebase to be more approachable.
But what do we do about all of those frameworks and dependencies? The best part is that you can learn them. If you find a repository or project that has some things that you understand and some that you do not, it is a great opportunity to read through the code and try to figure out what is going on. Do some Google searches. Search for the NPM package. Run through the docs for the new framework.
In our project, we were introduced to many different new frameworks, but the two that I chose to research were “Prettier” and “JS-YAML”. We had worked with .yml files before to set up our CircleCI, but this project was using this file type to store all of their data. And there was a lot of data. There was so much data that we, who had only seeded databases with small amounts of data, were confused about how to even run through all of it and get it to show up on the page. That’s where JS-YAML comes in.
JS-YAML gives the developer the ability to specify the depth to which they need to dig into the .yml files and get the data. You can also set the fields that you are looking for to default to “null” if there is no data there, and beyond that, you can tell it the specifics of how that null is written. You can specify the way that you want your integers in your data to be written and return new objects with only the information that you want.
Prettier is almost as helpful as JS-YAML. Working in huge codebases with a team can be challenging. Everyone (developers especially) have strong beliefs about how things should be done. Do we end our statements with a semicolon? (YES.) Do we indent or space? Prettier takes all of those things and does them for you. The docs for Prettier specify: “Prettier is an opinionated code formatter.” You no longer have to worry about if you have the right number of spaces or indents, and no longer have to check your linter to make sure that there are no errors. Prettier takes care of all of those things for you. The use of tools like this can make such a huge difference in any project but especially in an open source project. What better way to ensure that no matter who wants to contribute, your code will be correct and consistent.
Despite all of these packages that make things much easier on everyone involved, there are still going to be difficulties in jumping into someone else’s codebase. It’s hard to understand the file structure and it’s hard to know which changes you made in one file will affect something in another file. In our project, a lot of the issues (that we were capable of fixing) had to do with CSS. They incorporated SASS into their project, and while we were not familiar with it, we did our best to work through the code and figure it out. That didn’t change the fact that they were using class names to style their site. That didn’t change the fact that there were so many variables to run through that it was almost impossible to figure out where to make the changes. But I don’t think there would have been a better introduction to SASS than being thrown into the middle of it and having to find our bearings.
So what is the point of all of this? The point is that open source contributions are one of the best parts about working in web development. The community is welcoming, and I can honestly say that having your contribution recognized, even if it seems negligible in the scheme of things, is a great feeling. Employers enjoy looking for outside work from your actual job or school. An employer once told me that even though the actual suggestion and change that you made on an open source project might not be huge, it shows that you were interested. It showed that you want to make a difference. It showed that you had confidence in your work. It showed that you had the determination to see something through to the end. It showed them that you are a programmer who is going to make a difference both in your career and in the larger community.
