Sometimes an open source project is too niche for anyone to take notice. I myself am developing a networking reliability layer ported from C to modern C++ and I’ve yet to see a person use it except yours truly. Sad truth.
If the project has a community forum or chat, be active and help answer questions. That takes a lot of pressure off the dev team. I did that for 4-5 years on the Handbrake project before family commitments ate up my free time.
I myself am a maintainer/main developer of a project and the people that help out in the group chat are a god sent. Takes a lot of pressure out of my day.
is “step in and help review a few PRs” really that helpful? like… oh great, now this one person that i don’t trust is telling me that the other person that i don’t trust made some code that i should merge
How does one become trusted? If they regularly review and provide feedback that you agree with it can really speed up the process, even if you’re still double checking.
I’d love to help out on Open Source projects but have often just not really known where to start. I guess the challenge is to become a experienced enough user of a specific project first.
Besides that there is the possibility to donate. And since the xz backdoor incident I would say it makes sense to keep an eye on end users trying to bully or overload developers. If I remember well I read that the developer of uMatrix stopped with that project because of annoying users filing bug reports with unfriendly and demanding discourse, which can be exhausting for a sole developer.
I personally think you should move the fourth bullet (express your gratitude to the maintainers) to the first position in your list. But a great, simple list none-the-less.
Add comment