Our Codacy Pioneers program is not just about supporting incredible open-source software (OSS) creators. It’s also about amplifying their voices and fostering a culture of discussion and discovery.
The following piece was written by one of our Pioneers, Artem Zakharchenko, author of MSW, a seamless REST/GraphQL API mocking library for browsers and Node.js.
-------
Contributing to open source is, indisputably, a fantastic way to gain a deeper understanding of the tools you are using, expose yourself to the end-to-end software delivery cycle, and advance your skills as an engineer.
Being an active maintainer for almost seven years now, I know for a fact that most of the things I learn come from the tasks I tackle in my open-source projects. And while a maintainer’s life isn’t just butterflies and sunshine, it would be foolish to deny that it makes me a better professional and person overall.
But where do you start with it? How do you become a contributor? Do you have the skills it takes? Would someone actually want your contributions?
Let’s answer all of those questions today.
What Can I Contribute To?
Since the moment I learned about Node.js, I wanted to land a contribution there. Badly. I thought the project was fantastic, and bringing my little brick to the gigantic wall that is Node.js would be nothing short of an incredible achievement. I cannot count the times I’ve cloned the repo only to spend an hour lost in the code and, eventually, delete it. At the time, it was one of the most complex projects I’d ever seen. I felt powerless. I felt stupid. And, worst of all, I felt discouraged.
Eventually, I gave up on that notion. Life went on, I changed jobs and responsibilities, and my open-source projects evolved alongside me, gaining ideas, complexity, and popularity. It just so happened that one of those projects became tightly coupled with the network code in Node.js, forcing me to learn a lot about Node’s internals to implement it. There it was, the Node.js repo on my machine again.
But this time, it was different. I wasn’t just meandering, looking for low-hanging fruit to grab. The folks using my project reported plenty of real-world tasks, and I had to find a way to solve them. My lack of experience with Node.js didn’t exactly make the task better. But you know what did? Having a clear, scoped task at hand.
Time after time, I had to dive deeper and venture farther into the unfamiliar, intimidating codebase. What used to be alien and weird became natural and almost obvious. Even as I write this, I have an integrated development environment (IDE) open with the Node.js repo and the most common modules I reach out for: _http_client.js, stream_base_common.js, and net.js.
I think I’ve spent more time in those modules than in any project at work. Heck, I think I’ve spent more time in the Node.js repo than I ever worked at any individual company. In the end, this was where I learned to solve tasks for my libraries, but there was an unexpected side effect to it as well.
I found bugs in Node.js. Sometimes, it was something minor, like a confusing or out-of-date
documentation. Sometimes, it was something bigger, like a broken class implementation or a bug with handling streams in FormData. And I’ve reported those, too, barely noticing that I have become a contributor to Node.js.
Because here’s the truth:
The best contributions happen to the tooling that you are already using.
So, if you are wondering, “Where should I even begin?” Begin with your dependencies. Begin with the tools you import, require, install, and reference in your day-to-day job. Begin with the tools you find helpful and also with those that may occasionally annoy you. Those are the best places to start your open-source journey.
Where Do I Start?
I have bad news for you—or maybe good news, depending on your worldview. You are already a contributor to each dependency that you use because using is contributing.
Just by installing a project on your machine, you can provide feedback. Did it install without
errors? Was there a warning when you tried it with a particular package manager? Was something in your operating system interfering? Trust me, every maintainer dreams about having those questions answered and seeing their projects working everywhere for everyone. So, if you stumble upon something odd, don’t hesitate to open an issue on GitHub and let them know!
Like it or not, you own everything in your node_modules.
As you submit issues, try being descriptive. List everything related to the problem, and please follow any template that a project may have. If you also want help, attach a link to an isolated reproduction repository with a problem. Maintainers will love you just for that, I promise.
After that, the sky’s the limit, and everything becomes a contributing opportunity. A typo in README? Fix it and open a pull request. A confusing API? Raise a discussion and share your thoughts on what you think would make it better. A bug? Report it, but also try diving deeper into why it happens.
I’m not going to lie. It will initially feel intimidating, and the impostor syndrome will sometimes make your blood boil. Let those feelings be; they will pass. You will notice in no time how they are replaced by a feeling far stronger and more rewarding—the realization that you now understand the software you use better.
Frank Herbert really put it far better than I ever would:
“Fear is the open-source killer.”
But Am I Good Enough?
Yes. You are good enough.
Ask yourself this:
If you were building a house and were looking for volunteers, would you turn
someone away who’s eager to help but is unsure how?
You wouldn’t. You would appreciate them, support them, teach them, and, eventually, see them building the house alongside you. Most open-source maintainers will do that if you are open, respectful, transparent, and willing to help.
What of the Tasks Objectively Beyond My Reach?
Let’s face it, squeezing a pull request into the Linux kernel will unlikely be your first open-source contribution. And that’s probably for the best. If every task was immediately achievable, it would void the need to grow.
Some projects are harder to contribute than others. Some may require additional knowledge or skills, starting from a different programming language than you are used to and ending with an insider-level, borderline instinctual grasp on the project and its direction. The good part is that nobody expects it all from you. Trust me, just showing up and expressing a desire to help is more than most maintainers can hope for in a contributor.
Don’t forget that open source is about humans. The most incredible engineers I know will be the first in the room to admit if they don’t know something. Because they know it’s a rare opportunity for them to learn. Don’t be shy to ask a question. Many things can open in life if you bother to ask.
Start small. As long as the project excites you, you will get more proficient with the code and the
decisions behind it. That is inevitable—unless you let your fear stand in the way of your progress.
Thank you for coming to my TED talk!
Okay, in all seriousness, I hope you feel more confident about that next (or, perhaps, that first!) contribution.
And me? Well, I’m just envious that you are about to make some maintainer’s day so much better.
