I am exploring the prospect of doing so.
The fixed bug or feature itself is a reward. And that you just need to code that feature instead of having to write your own complete clone of that software just to add one extra little feature. And just like that you have added your little brick to some amazing tool which you can say you helped build.
If you are exploring the prospect of contributing, then a good way for you to be motivated is to find some software you use often, but which you personally would like some feature or bug fixed.
E.g. https://github.com/CopilotC-Nvim/CopilotChat.nvim was written in a single afternoon while sitting at a social event I didn't enjoy and now there's 60 contributors and I've completely handed over ownership/maintenance to the community
I still use an ancient version of obsidian on my phone because it works with my hacks to self host the native sync server https://github.com/acheong08/obi-sync
For other open source contributions, I generally just add features I want or fix random bugs. I use exclusively open source software for everything, no big tech accounts at all. So contributing only helps myself
About 15 years ago I used to contribute to Blender and did it just because it was something fun to do. The documentation wasn't all that good and if I wanted to figure out what some random button did the easiest way was to read the code and, in the process, I'd find bugs. Also, the Python API wasn't completely comprehensive (this was right in the transition between python 2 and 3) and I took it upon myself to fill in a bunch of holes. Other times some artist would ask for a feature and if it was something within my capabilities I'd oblige. Mostly I'd just try different things and if it were viable I'd submit a patch (where the devs had a different definition of "viable") or horrible fail and just move along to the next shiny thing. Eventually I was given contributor status but would almost always go through the regular patch submission process and/or pester one of the main devs before committing anything.
I started out just learning Blender, because it was interesting, then started hacking on Blender because that was more interesting. In the process I learned a bunch about how python does it thing, which I still use to this day, and got really, really good at hunting down segfaults due to not being the best C programmer.
So, yeah, like everyone else is saying, just find something you enjoy and contribute to that... or don't contribute and just submit good bug reports.
My advice is to find something that you like, but want to improve, and then work on improving it. With some luck, the maintainer will be a nice guy and you can collaborate with him on it.
(I mean, I don't do it only because of these reasons, I'm a true believer of Open Source, I believe it is the more superior development model for a more civilized age, but it's kinda hard to argue against a paycheck)
My OSS work turned out to be a great resume builder that opened opportunities for me that far exceeded what I would have had if I had gotten a job as a junior developer straight out of college. The mentorship by the ZFSOnLinux and Gentoo communities was fantastic and helped me mature into a senior level developer rapidly. :)
That said, it is great when you can do worthwhile work and be paid for it. It is a double win.
- stuff that i want to stay for very long time
- stuff that I believe will success.
Anyway, I commented to say that I had a similar experience. I did not know how to fix the issue in MD RAID 6 + LVM2 back then, but I knew how to fix another project that did meet my needs, so I fixed that. :)
I've submitted PRs to projects I use (dnspython, scapy). One of the cybersecurity companies I worked for managed various ruses to keep me from supplying fixes to upstreams; the most feckless bullshit reason they came up with was "opsec".
While working for Farsight I reviewed and provided feedback to several open source projects regarding their integrations with e.g. DNSDB.
Not everything has to be a PR, or targeted at the project's self-declared consituency. For instance I wrote a protobuffer dissector for scapy (https://github.com/m3047/tahoma_nmsg) because scapy was a handy "living off the land" kind of way for customers and prospects to taste Farsight's tunnelled SIE products without compiling a bunch of C libraries. (You can declare your own protobuffer data types, use https://github.com/m3047/tahoma_nmsg/blob/master/tahoma_nmsg... as an example.) I don't distribute scapy, so there's no compelling reason for me to use the same license. (You're welcome.)
In fact, I re-used the protobuffer dissector for the Dnstap half of the ShoDoHFlo DNS + netflow correlator (https://github.com/m3047/shodohflo). I started down that road because Vixie got his panties twisted up and his hair on fire about DoH, and once I looked at it it seemed that there was something in there that I'd personally find useful. A couple years later I decided I wanted e.g. "dig -x" more than a GUI, and after several iterations I came up with Rear View RPZ (https://github.com/m3047/rear_view_rpz). I find it useful, and I think it's a pretty cool hack. (Works with EtherApe!)
ShoDoHFlo stuffs data into Redis. I found myself utilizing that data for other purposes and got tired of installing a Redis client and dealing with the security issues. So I implemented a DNS proxy for Redis (https://github.com/m3047/rkvdns).
I still haven't "found my tribe"; or maybe I have, and most of them don't contribute to open source. Nobody submits PRs, and nobody I know opens issues; instead they send me emails. :-/
