Toggle table of contents
DISCLAIMER : This post is entirely my personal view, and does not reflect that of any projects I contribute(d) to.
Hey! In this post I've shared my personal experience with contributing to open source projects. I'm still a learner, and probably will be one for rest of my life. But I believe I'm beyond that point where I was confused about "how do I even start". I'm recording my experience in hope that it proves to be useful to someone else.
Since this post is meant to record my personal experience and observations, I have glossed over some commonly known practices like looking for good first issues, or learning basics of the toolchain you'll be using. I find those advice to be abundantly available on the internet.
Be inspired
The first step is pretty simple. Be inspired!
As simple as it sounds, many people don't know exactly why they should be contributing to open source projects.
Do you want to improve application reliability for thousands (or even millions) of users around the world? Do you think you can add a cool feature to your favorite application? Do you believe that you can lend a helping hand to the developers pushing updates to applications you use daily? (and many of them are probably doing it without any pay)
If your answer to any of the above is "yes", you've already completed the most difficult step.
Finding true love
If your answer was "no", well, how do you find that application or organization where you're truly motivated to contribute? First step wolud be start using more open source software. As you increase your exposure with open source software, you'll eventually find a software that you really want to help with and improve upon.
I really suggest switching to a Linux distribution at this point, because that will make your life much easier.
My story, you ask? I have tried contributing to open source projects here and there, but the lack of real motivation was a big friction point for me. Fast-forward to April 2020, when I first used Endeavour OS. I found it to be a great distribution, offering the experience I really liked and believed in. Months later, I realized I really wanted to help them out. In whatever small way I can. February 2022 marks one year of me being on the team.
If you try contributing to a software you use, it will be much easier for you to test changes and come up with new ideas/ improvements.
But, I don't know coding :(
"I don't know coding, how do I contribute?"
This is a big misconception among people new to the open source scene. Programming is just one part of the process. There are many other things a project needs help with. Graphics, translation, cloud infrastructure maintenance, promotions, testing, support... KDE even had openings for music producers willing to work on sound design for Plasma!
Some of these don't even require a very high technical IQ. Take for example testing - an average Joe is as suited to test applications as the project developer, since most of the users are going to be the average Joe.
On Endeavour OS, I do testing, theming, packaging etc. Any one who can write code to traverse an array can certainly do these things. So you can already guess there is no coding involved. But my favorite work is seeing those experienced people discuss problems and find solutions. That is what grows me as a learner.
However, that doesn't get me into XYZ open source event
"Most open source events for students are geared towards programming, so how do I make it if I contribute with other stuff you just mentioned above?"
If you've reached here, I suppose you said "yes" to the questions I put up in the first section. If you're doing this only to get into an open source event - that would totally defeat the purpose. Yes, it's good to try getting into these, but in case you're not able to make it, you shouldn't stop contributing to open source altogether. You can still contribute even if you're not a part of any student event. What should motivate you is the fact that you'll be improving user experience for thousands (or millions) around the world.
Even if you don't contribute code, there is a lot to learn. Just by seeing how the project members function, you get an idea about managing large communities. You get better with your communication skills. You learn more about the organization and make friends, who could certainly help or guide you. (seriously, knowing an experienced person is way better than a hundred unknown LinkedIn connections)
Ok so, how do I start?
You've finally found the project(s) you want to work on. What do you do now?
First up, join whatever communication platform the project uses. Matrix, IRC, forum and mailing lists are the common ones. Introduce yourself - keep it short and to the point. List your technical skills that are relevant to the project. You don't go to a kernel development group and say that you know React. (unless you're discussing their website) Most likely, you're going to be ignored. It shows that you did not try to read up what the project is about and how they do their work. Introducing yourself is - undoubtedly - one of the most dreaded questions. Looking back, I find that my non-coding days at Endeavour OS taught me a lot about how open source projects function. Being a mini maintainer myself, I have seen quite a few potential contributors. I know what a project maintainer would like to hear. And that helps me when I am the one introducing myself in communities where I'm new. From the last section - even if you're not programming for a project, you're still progressing faster than you know.
Stalking communication channels, I've seen a couple of copy-paste introductions and project ideas. The posters had put in absolutely zero effort in even looking up what kind of products does organization makes. As a result, they either were gracefully ignored, or received a feeble response. So, do little bit of research beforehand. Do your ideas suit the project goals and philosophy? It is much easier and smoother working on a project where you believe in the goals and philosophy.
Once you have introduced yourself, a community member should point you towards the resources and relevant communication channels where you could help out. Do note, exactly nobody will spoon-feed you. Most likely, you'll get link to a wiki page, or link to a different group. It's your task to explore and follow the links to find what you want to help with.
Say, you want to join the promo team. Of course, you'll first need to join their channel. For a couple of days, try to just observe how they work. They are probably more efficient than the way you're used to working with your friends. Try to understand the tone and air of the channel. (you never want to crack an out-of-place joke) Once you feel you understand their flow, start chipping in with your suggestions, ideas and opinions. Again, you're probably not contributing something tangible at the beginning, but one idea leads to another - you never know when your simple idea transforms into a lengthy discussion and ends up as the next big thing.
And obviously, never send memes in #general XD
If you actually want to get into coding...
It is a tough ride ahead, but I promise, it is very rewarding. As I said earlier, if you are contributing to a software you already use, chances are you already have some suggestions or ideas to make it better. Why not take them as the starting point? Before starting to work on anything, it is always good to discuss with other team members about the changes. It is possible that your suggestion goes against the project philosophy, so it might need some tweaking. Or in the other case, an experienced member could help you refine your idea. Also, make it a point to look up if the idea or bug you want to work on has already been reported and/or is being worked upon. If yes, you could team up with the person(s) working on it, and help them with testing, or giving ideas.
What if you don't have any idea, or you're new to the project altogether? Download it and start using! Try to look around the application to get a sense of what is it about. Don't straight dive into the code. Look for pending issues. Try to assess which issues you could possibly solve. You don't have to solve the complete issue in your head right now. Just think about what all tools you'll need. Do you know how to use them? If still looks difficult at this point, simply try to reproduce the bug. There are many nasty bugs that are hard to reproduce. Even if you come up with a definitive process to reproduce the bug, you'll be doing a great help to whoever takes up the task of fixing it. Share your findings with the team, and follow the discussion. When the bug is finally patched, try reading the diffs and see how it was solved. This will give you idea about at least one component of the application.
If submitting patches, feel free to discuss or take help from the community members. Most likely they'll help you out. Never be afraid of code reviews. See them as light discussions. My first code patch was not merged, and the discussion only led me to contributing a better patch. I've recorded the experience below.
My experience
The first "coding" related issue I had to fix on a KDE project was on KDF. You can see my bug report here. KDF was using Dolphin as the default file manager, instead of the system default. It did let users change file manager from settings, but that wouldn't work when using KDF as a Flatpak. So, in my first patch, I removed the feature of selecting file manager altogether and made it such that KDF will always use system default file manager. In review, I was suggested to not remove the feature, but instead give users the option to either use default file manager, or specify a custom one.
I closed the pull request and the next day, created a new one, which was finally merged. My code contribution wasn't something too significant, but it helped me become more confident with QtWidgets, C++, signals - slots and by poking around in the source code, I also learned how the project is structured and how they use their framework to store user preferences. Tiny patch, but big learning. As my next patch, I was suggested to add a feature that would detect if application is running as a Flatpak, and disable the custom file manager input automatically. This time I already knew about the application. I sent the patch rather quickly.
Of course, I got a lot of help from the community members. The whole experience makes it worth it for me to contribute.
Going further
By now, you probably have some idea about how to go about making your initial contributions to your favorite project.
Once you make your first successful contribution, you feel lot more confident. You feel motivated to take on bigger tasks, and become active in discussions. You should have already realized that this is a team effort. You work with constant back and forth reviews and suggestions. The more you participate, the more you learn. Probably for this reason, I like joining different channels and stalking their discussions. (even if I don't understand half the technical terms they use!)
This was a beginner sharing his experience for other beginners. Hoping this post cleared up your doubts and you feel more confident about stepping into the world of open source software development!