My beginnings in Open Source — WIL
Open Source. First Week.
Introduction
On this post I’ll talk about what I learned in my tenth week as a member of the NS Academy; the lectures and videos I watched, the tasks I worked on, my day to day, and all the activities that were included in the first week of the Open Source Phase. This week we started a new phase centered in contributing to Open Source projects, that is, projects that accept help from anywhere in the world. This help can be provided by solving bugs, adding new features or even translating and correcting typos in the documentation. In the first section of the essay, I talk more about what I learned about Open Source projects, how they can help you become a better developer, and why contributing to these projects can also help you in your career. In the following section, I talk about more technical stuff. Since this was the first week of this new phase, one of the introductory activities was to answer three technical questions about the languages that we chose for our stack. In my case, I chose Python and JavaScript, since those are the ones I like the most and I’m more familiar with. In this section, I will talk about what I investigated this week, like cookies in JavaScript. At the end, I give a brief conclusion of this week and how I felt about it.
Open Source Projects
When a project is “open source”, that means anybody is free to use, study, modify and distribute that project for any purpose. This lowers the barrier to collaboration and allows people to spread and improve projects quickly. In this new phase, the Academies have to contribute to different Open Source projects, mainly, projects that are related to the coding stack that they chose. But why do this? Personally, I’ve never contributed to an open source project, and I didn’t understand the reason behind it, but the lecture “How to Contribute to Your Favorite Open Source Project” explains very clearly why. In this post, they give you different reasons on why you should do it. Some of those reasons are: learning how the real world functions and learning good and bad practices; but the one that I didn’t think of was that it can help you during job interviews. There are a lot of Open Source projects, and some of them are really famous! For example, Brave is a web explorer that’s becoming kind of famous lately and that I’ve used before. If I can make a contribution to this project, It’ll really help me during interviews and my personal brand.
Now that I know the benefits of contributing, how do I choose the project that I want to contribute to? A lecture that helped me choose the projects I want to contribute was “How to contribute to Open Source”. In this, they explain that lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that’s the case, then contributing the patch back is the best way to ensure that other people will be able to benefit from it. This really made me think about the projects that I want to contribute and why. In my university I used a lot of Python libraries like numpy, pandas and matplotlib to examine and determine results from various physics experiments, and all of them are open source projects. That’s why I decided to try to collaborate with those projects. I’m an active user of those libraries and helping them would help me understand more the tools that I use and also help the project in the process. I also want to help on the Brave project, since it is a browser that I actively use and would really like to know how it works and help improve on it. I think that choosing the project you want to collaborate on using this technique is really smart, because it’s something meaningful to you and you feel more motivated to try and solve problems within those projects. Or at least I know I am.
Speaking of which, I’ve visited a lot of Open Source projects, and I have to say that there’s a lot to unpack if you want to contribute to them. You need to understand how the community works in that project. Every one of them has its ways of accepting contributions, so you need to familiarize yourself with those guidelines before even attempting to do any contributions. That’s why it’s important to do a quick check to make sure your ideas or fixes haven’t been discussed elsewhere.
Developing and reading code
After selecting the stack that I want to work with and the projects that I want to contribute to, I started downloading the projects and seeing how they work internally before starting to try to fix bugs or add features. As I mentioned before, this week we also had to answer some technical questions about the projects that we intend to collaborate. These questions are more related to specific ways that the language manages things or tasks. For example, something that I always wondered and never really understood was web cookies and how they were handled. Since I was looking through the Brave repository, I searched in the projects where cookies were used and how they were used. I was a little confused at first, since I’m not an expert on JavaScript and I’ve never used cookies before. But after spending some time with the code and reading a little bit more about it in the documentation of JavaScript and the project itself, I think I have a better grasp on what these are and how they are used when developing a web page. Not only did I learn how JavaScript handles cookies by using the property document.cookie, but also how the project that I’m working on uses them.
I feel like this is a great way to understand code and how it actually functions. When I don’t understand lines of code, I mostly go to the documentation of the language and try to understand the basics of it, but sometimes that isn’t enough. Maybe the code you’re reading is used for something else, or maybe it’s not even the same thing you were looking for in the documentation. This is something that happened to me from time to time in the last phase. Since JHipster generated a lot of code when creating the base of the project, sometimes I felt kind of lost and had to go through a lot of documentation, but it wasn’t until the last week that I understood that documentation can only help you so much. You need to also try to understand the code without the documentation, that struggle of trying to understand will help you retain that knowledge more than if you only stare at the documentation all the time.
As of now I’ve selected two projects two work on, and I’m moving through the files, doing some testing, and trying to run the projects without problems locally on my computer. Also, I’ve read some issues and read the threads of those issues to see if I can start to collaborate on them or not. Right now I’m having some problems running the Brave project on my computer, so I’ll try to fix those problems based on solutions the repository gives me and try to start working on some issues.
Conclusion
This week was a lot more calmer compared to the last week, but that doesn’t mean that I stopped learning more about how this line of work functions. Open Source projects is something that I knew of, but didn’t really take an interest in it. After reading various articles about the benefits of contributing to this kind of projects, I’m really excited to start working this month. Something that I’ve noticed this past two months is how my perspective changed about development overall. When I first entered this program I thought that coding was more of an individual job, and boy was I wrong. Even in this phase, you have to work with projects that have literally more than a thousand contributors, so you need to understand how they work and how you can actually help them. I’ve grown a lot in these past months, not only as a developer, but as a person too. I actually enjoy what I’m doing and I’ve been balancing better my work and my personal life. This program has shown me so much and I hope that I can still learn a lot from it in the future weeks.