Either:<p>- try to discuss issues on the bug trackers (or IRC), propose a solution, then send a patch/PR.<p>- find an itch on the project and scratch it. I did that for grml-etc-core [0], and helped port some advanced functionality to *BSD because I found it cool, but it only worked well enough on Linux. I also add some specific info in documentation when needed [1]<p>Don't work alone on a task before pushing a patch to the devs, make sure someone's aware of your work.<p>[0] <a href="https://github.com/grml/grml-etc-core/commits?author=moviuro" rel="nofollow">https://github.com/grml/grml-etc-core/commits?author=moviuro</a><p>[1] <a href="https://github.com/nextcloud/documentation/commit/c40a80a2367dd1439e33145f7d14458f63cd0f59" rel="nofollow">https://github.com/nextcloud/documentation/commit/c40a80a236...</a>
The easiest way to get into open source is to start your own projects.<p>Alternatively, you can find a project with a single maintainer and few or no third party patches & fix a serious issue (or add a useful feature). If your patch is accepted, then you've made a social connection with another developer (and maybe even a friend); if your patch isn't accepted, you can maintain your own fork & somebody might contribute to yours.<p>Contributing to someone else's project (particularly, large and complex projects) involves integrating into existing social structures, which often is difficult and underdocumented (particularly when the primary goal of the project is to just get the development work done -- such projects often don't go out of their way to make it easy for newbies to contribute, since newbie contributions are liable to be of lower quality). Some projects make a real effort, but that's unusual. Even then, large projects (because they have communities) are full of complex politics that are borderline incomprehensible from outside, and navigating these politics takes a lot of time that could otherwise be used for meaningful contributions to smaller projects.
If it's a small project, then a quick email to the maintainer or a GitHub issue asking how to get involved would be great. More often than not the maintainers would gladly help you.<p>If it's a large project then the above would be slightly annoying. The maintainers would more than likely have some sort of process for contributors to get involved in their CONTRIBUTING.md file. If not, then creating that file is a great place to get started!<p>Also, you could just go direct and submit a PR. But only do this if you know that it's within the scope of the project. Adding an enterprise feature to a small project isn't going to go down well.<p>I used to be quite scared of contributing because I didn't know if my contribution was good enough. But I quickly learnt that the maintainers do it for the love of the project and anyone contributing is like them showing love for the project too!<p>Other than that, enjoy it. Don't fret the small stuff! Happy contributing!