Introduction
The idea of contributing to open source projects is often presented as an easy task that anyone can do. However, in reality, it can be a very challenging journey. Despite hearing countless times that contributing to open source is simple, it wasn't until I tried it myself that I realized this was not the case. In this text, I will share my own experience with open source contribution to provide an honest and informative account of what it truly entails.
Act 1: The grand illusion
In the beginning, I started to ask my colleagues for tips on where to start, and they pretty unanimously said to search for issues with for beginners or help wanted tags, maybe in some of the projects I was already using at work. Well, I thought, that's easy. I got a short list of the libraries I was using and/or I was interested in and started digging into their GitHub repositories. I combed dozens of open issues, but either they had no good first issue tag, or the more accessible things got snatched lightning fast.
So I went back to those who had suggested this route and asked for advice again, and this time they told me that I probably couldn't look in the famous libraries, where the competition was too fierce; I had to find my hidden gem in smaller projects.
I restarted my search, feeling slightly disgruntled. While it's nice to offer help, it's even better if that help is given to a prestigious library that you can boast about to other developers. It's natural to want to showcase our accomplishments, especially to those who understand our work. My parents only see value in my ability to fix their phones, so let me have this one thing.
I then perused less-known libraries, confident that I would be lucky this time. But I wasn't.
All I could find were libraries with complicated tasks, even the ones marked for beginners, in which the tag was very much misplaced, as in you had to know the codebase exceptionally well to fix even the minor stuff.
So OF COURSE I rolled up my sleeves, drew upon my inner strength, and found the perfect fix, after which everybody hailed me as the best contributor in the world.
Yes, no, of course not, otherwise we wouldn't be here. I quit. Just like that.
Act 2: Reality check
Let's jump a few months ahead, and the OS itch returned to me. I have a friend who makes videos about OS. He was doing one on Hacktoberfest 1, saying that there were no physical prizes to discourage issue-taking spammers this year. This was my long-awaited chance, I was certain!
So I went to the Hacktoberfest site and combed the starting section. There, I found a link to a site that collected issues suited for first-timers, grouped by project. If they were included in the most famous site for the most famous OS event of the year, they certainly must be what I was looking for, right?
At first, I tried filtering by language, trying JavaScript, and looking at some of the open issues. Even worse than with my previous attempt months before, I couldn't even find the issues this time: they were snatched so fast that the site wasn't always updated on time, so it listed things already being worked upon or even fixed and merged.
So I narrowed my search and went where only the bravest engineers dare to go: CSS fixes.
But even doing so, I was again faced with the problem of finding only not-really-for-beginners-beginners-tagged issues. So, once more, I gave up.
Third time's the charm, and now I was fixated on having to make at least one OS contribution, so after Hacktoberfest was over, I tried another of the many tips I had been given previously: fix the documentation and find typos or bugs even before an issue is opened.
This was pure coincidence; I was researching Angular's Signals, and I knew that the .mutate() function was taken out of the APIs. (For context, this was just a couple of days from the announcement).
I checked the documentation and, lo and behold, it was still there. I thought this was my chance for glory: a small, not-yet-mainstream documentation fix in a famous project. So I rushed over to the Angular GitHub, and I'm sure you've guessed it: It was already fixed and just waiting to be merged in. And it was snatched just before I checked, so double the annoyance.
Act 3: The Hidden Gem
That was the last straw; cumulatively, I had spent more time looking for something to do than actually doing it. But I really wanted to contribute!
So a few more months went by, until one day I met an Italian open source maintainer and long-time speaker, Giorgio Boa, who by the way was a guest on our podcast Continuous Delivery, and asked him for advice, saying that I wanted to be part of the OS world. He said he was working on a small library of Qwik components and could help me if I wanted. I gladly accepted, and we found an issue that seemed pretty straightforward.
A few days after our conversation, I followed the little README guide to install everything required, and...nothing worked. So, after a few bad words, a lot of doubt about my skills as an engineer, and self pep talks to overcome my shyness about asking for help, I contacted Giorgio again. Even with his help, at first we had some trouble figuring out what was going wrong, but in the end I finally had a working setup.
Eventually, I finally had time to start working on it. It seemed easy; Boa had already given me some tips on how to get started, so I got half the work done in a short time. But then the problems started. After going in circles for about a day, I finally gave in. I did the scariest thing of all: I once again asked for help, admitting that I had no idea what was going wrong. We tried to look at it together, but we couldn't find the problem right away. So I committed the part that I did that worked, and the next day Giorgio fixed the other half and merged my very first PR into the Qwik Storefront.
So, in the end, I finally got what I wanted: a published contribution in a good library, but I couldn't stop wondering if it was all worth it.
I was proud of it, of course, even though I needed some help. But I wanted more out of my work.
In the beginning I felt like a fraud for not contributing to OS, but in the end even contributing, or trying to contribute, made me feel like a fraud for not knowing enough and being more of a burden to a senior contributor than an additional help.
Looking back at it now, I think my biggest mistake was trying to do it for the hype, trying to conform to what everybody else around me said I should be doing and not because I really believed in what I was doing and why.
It doesn't really matter what anyone else says or does, because at the end of the day it's your time that's being spent solving these issues, and that time has to mean something to you if it's being taken away from other parts of your life.
I haven't resolved any other issues since then, and for now that's ok for me. I want to resolve an issue all by myself next time, but I want to be sure to do it for the right reasons this time, to avoid any unnecessary stress.
Knowing that this time, if I do go back and contribute, it won't be for the "glory" or the FOMO (Fear Of Missing Out), but for the kindness I've been shown, and which I hope to one day give back to a fellow developer in need.
Conclusion: The Truth Unveiled
So am I saying you shouldn't contribute to OS? Well, of course not. But I am stressing the importance of doing it because you really want to, or because you think the project you are working with will benefit from your contribution, not because everyone else is doing it and telling you how important it is, or because you really want a free T-shirt. As we've seen, helping in OS is not a walk in the park, so you must engage in it knowing what you're really getting into to avoid unnecessary frustration.
If you enter this world fully aware of what you're up against, you'll find it easier to accept the difficulties that come with trying to start contributing to open source. It will also give you the mental strength to accept failure when the problem you thought was beginner-friendly turns out to be much more treacherous than you thought.
What will be different is your reaction in front of this problem, as you will now know that there's no shame in not being able to close a beginner-tagged issue or even in asking somebody more skilled than you for help. Even though you'd have to ask two, three, or a hundred times. Just know that it is ok to fail and to need support and it doesn't make you any less of a developer.
Post Scriptum
This post offers my personal viewpoint on contributing to open source software, with the awareness that alternative methods of contribution, such as identifying and reporting bugs or translating documentation into other languages, exist but may be less widely known to those who are new to open source communities. Rather than purporting to present the definitive truth, the aim of this post is to provide a different angle on the difficulties that beginners may encounter when trying to make their mark in this world of contribution. The text conveys a thought-provoking perspective while upholding the utmost respect for individuals who consistently contribute to the open-source world.
EDIT: we also wrote a reply to this post that you can find here
Footnotes
-
Hacktoberfest is an annual worldwide event held during the month of October. The event encourages open source developers to contribute to repositories for the whole month.
Up until 2022, if 4 of your PRs got merged, you would receive a free t-shirt and sometimes other swag, which created utter chaos, with loads of fake or useless pull requests being spammed all over the GitHub universe. ↩
Top comments (2)
I appreciate the moxy, keeping with it, and then writing this up.
I've long been puzzled by the hype. Open source had always been about scratching an itch you have as a developer to fix an annoyance in a thing you are using. You therefore need opinions first. If you find something simple, you just go ahead and fix it, why would you bother creating an issue for others when the fix is easy?
Also consider that from the maintainers point of view a good "first issue" might be a good first issue for learning the code because you intend to be a consistent, long term committer. A "beginner" issue likewise might be good for someone starting out with the codebase, not with coding in general. What projects usually want is invested, trustworthy, long term committers not one-time-and-done resume padders. Not saying that any of this is you, just that I never understood that logic to begin with.
When I recommend devs try working with open source it is because that will give them experience with how real projects work. When they find projects to be complicated, poorly organized, and requiring a great deal of reading, research, and serious, long-term commitment in order to make a difference, I say yes - exactly. Getting the reps in at learning to work with such projects is the experience bit.
Like with any real world coding, it's only simple when you already know what you want to do.
This strongly resonated with me 😅
Very well-written blog!