In between steps 0 and 1, hang out on the mailing lists, IRC channels or wherever the devs talk to each other. You can get a feeling for the culture of the community, who the most active people are, the best people to ask newbie questions without getting flamed, and so on.
First you have to find a project you would like to work on. After that it usually goes like:
- Adding New Features
Is it a new feature I want to add to the project? If yes, find out if someone is already doing this feature, and then you have the option to work with them, otherwise, start coding and submit a pull request (or something similar).
- Fixing Bugs
Is it a bug you found while working with the project? If it is, then this is a good time to go inside the code and fix it and do the same pull request cycle.
- Performance Fixes
If you're a curious guy like me, you can go ahead and look through the source code and find places where you think performance can be improved, then start refactoring, after you're done, make sure you publish benchmarks in comparison to the old results.
As other said, just dive in.
And if you're lucky to have your patch criticized and ripped to pieces, you'll learn a lot more from that than you would have if you just work alone. And next time, you'll know to think better about how your code interacts with the rest of the project before submitting another patch. This will give you a lot of insight on how to work nicely with others, without stepping on each others' toes.
I think there is only one way to know, try :) And then just keep trying until you succeed.
But I think it is good idea to first talk with the maintainers. At least if you plan on making a 'major' refactoring to the existing code. Start small and continue from there.
I think discovering OSS projects for one's aptitude and interest is a field ripe for disruption. A few sites have been mentioned, but I think even more can be done. At the same time I wish GitHub was more newcomer friendly.
If you have a full-time job and family life, and side-projects of your own that are not OSS, how do you find time for OSS?
You need to find OSS that you're motivated to develop for. You shouldn't pick some random project that you have no interest in for the sake of boosting your GitHub activity. You need to set up your project environment. You need to debug/test your patches. You need to learn and conform to the coding standards of the project you're dealing with. You need to communicate with the project team and be available.
All these things together require a lot of time. Great if you're single and in college or without a job.
OSS projects, and GitHub in particular, have an elitist stigma surrounding them these days. I don't think it was like that ten years ago. All the Silicon Valley hot-shots are contributing to the OSS projects all over the place. One may think reading HN that everyone and their dog contributes to GitHub and is active, but I don't think that's the case (at least outside of Silicon Valley).
I think it's pretty ordinary to be angry when something you use regularly breaks; is there anything particularly unhealthy about expressing your anger by yelling at an inanimate object? If so then I may need to change some habits.
I personally get more angry with bad design annoyances that will probably never change. Like the way YouTube videos stall and reload when you click back in the video or not begin able to filter out certain news items on Google News etc.
PS. I was kind of teasing. Don't take me to seriously ;-).
I cannot believe that people can have that question. Or, well, I do believe it, but then my second question usually is: did you ever use linux/bsd or any OSS project in the past?
I don't want to be rude at all, but the suggestion of "contributing to an OSS project" makes a lot of sense if you already had to work with/use OSS software. Because, if you had to use one of these projects, you would probably already understand the most important social aspect of it. Coding, IMHO, is just secondary (and is not necessary at all).
Thus my suggestion would be: if you never dealt with an OSS project before, try to find some OSS software which you genuinely like and try to use it (and well) and follow its development. Once you did, you will certainly know how to contribute. There's nothing more to it.
If you are already familiar with OSS, but so far never found anything "interesting", the best thing to do IMHO would be starting your own. Release something that you did and that you would like others to use.
Most importantly, do all of that for fun. Don't do that because you have to and because they said "it would be helpful". Helpful for what? Coding style\quality varies wildly, as is the community around the project itself.
The biggest difference between a "professional" and OSS project is exactly this: people work on OSS project for many reasons, but it's mostly for fun or passion. Some projects strive for quality, some for functionality, and some just solve an "itch" somebody had. Understanding the social aspect, again, is the biggest differentiating factor.
There's no point in contributing to OSS unless:
1) you released something that you like to maintain
2) maintain something somebody else released
3) fix an itch you have
4) having fun coding (or any other activity around said project)
>If you are already familiar with OSS, but so far never found anything "interesting", the best thing to do IMHO would be starting your own
I couldn't disagree more. If you haven't found a project that is "interesting" or simply useful, then you're not really programming (or perhaps aren't looking in the right place?). There are SO many useful projects, or semi-useful projects (and lots of not very useful ones) that there's got to be at least one (if not dozens) that would be interesting.
Regardless, if one couldn't find an interesting one to contribute to (at least a little bit), starting a new one would be a bad idea because, unless it's really unique or compelling, won't get a lot of attention and you won't get any good feedback on what you're doing (which is critical if you want to learn).
I do agree that the social aspects of contributing to and/or running an OSS project is important. So even if you're not contributing code to a project, if you're filing issues or making comments on other issues, that's a great way to learn.
If you are not familiar with Linux (for example, you're working on Windows or mostly doing web-development), it could entirely be. Mac OS is more friendly, but I certainly saw many developers that didn't scratch the surface and directly went with XCode/ObjC/iOS. In that sense, you can build a career without ever considering OSS development/usage.
What's best for somebody that, as of now, is questioning which project should be looking at? If you don't know what you're looking for, any advice is just as good as a google or github search (ie: useless).
If you start by having fun, even by publishing your random projects, you will be dragged in by dependencies (that's ironic). I would rather recommend choosing something fun to work with than a random project to look at.
I can definitely agree with the social aspect of oss and contributing to oss. my contributions have come as a direct result of interacting with various people in the community casually, and finding out about things I can continue to along the way serendipitously.
I created a Github account and found a really interesting project (Adobe Brackets). At that time I was looking for an open source project and found brackets, I enjoyed using it and when I realised I could contribute I started building whats missing.
I've contributed to Arabic Translation, Text Highlighting and Code Recognition.
So my advice to find something you like and contribuite to that :)
A lot of the advice on here is fantastic, but mostly relies on "being passionate about a project", or "pick a project you use". To me, the hardest part is actually finding the project you want to contribute to. I heard in school that I should contribute to open source, but at the time, all the programming I did was for class projects. When I heard the term "contribute to open source", my head heard something along the lines of "patch the linux kernel". I never really used all the cool libraries that exist for web or mobile development, so I had no idea what I would contribute to if I were to contribute to open source.
I'd say first pick a project by going and building something that relies on some cool Github library. I don't think anyone but me clicks on the "Explore" tab on Github, but check it out, find a repository that you think is awesome, try using it in your own small project. Then I'd say go ahead and look at the issues that the library is having, and start tackling them one by one.
Of course, you don't need to go to the ASF when doing Open Source. I found it great because its all around community there and there are many nice people.
You could also simply start with getting the sources of the tools/lib/framework you use every day, be it on ASF or not. For example, I got the source code of Angular.js because I use it daily. Now when I need to implement something which makes me confused, I am looking into the Angular.js code to understand why it does confuse me. In many cases it's not easy and I leave it up for "later" (aka never), because of the time. But if I am REALLY interested I simply ask on the mailing list how things work. When you have got that knowledge, you can investigate if there is a better way and propose a patch/pull request.
Also simply looking at the issue tracker and finding issue which are matching your skill level are a good start. You could also try to understand issues which are above your skill level, just to understand better how things work.
After all, becoming a contributor is easy: asking and answering questions on mailing lists IS already a contribution to the open source project. Finding out on background, sending patches for typos in the docs, improving unit tests or implementing new features is of course a bigger contribution.
If you are serious about getting into open source, then my advise is to flesh out an hour a day and walk intensive through code you find interesting. If it bores you, take something else. If not, understand things and simply get in touch with the dev, hopefully with some great patches.
Late to the party but I wrote a website to help you do exactly that http://www.codetriage.com. Find a GitHub repo you like, then subscribe to receive one issue in your inbox each day.
Most projects have a special page with instructions for beginners. Generally, all instructions are similar and contain several steps:
- subscribe to the mailing list for developers;
- preview of the coding standart;
- familiar with the procedure for sending patches to review;
- contribute :) ;
In my opinion the best way to contribute is to add that functionality, which does not get to you personally. As an example, you can see the page of GNOME for beginners https://live.gnome.org/GnomeLove .
Even more simple. When you find a bug tell the dev(s).
It's sometimes frustrating to find out a bug that has been around for ever and drove users crazy but no one ever signaled it.
Edit: The first project I ever contributed was phpBB. It was years ago. I never coded before, so I was moderating the community and then I learned how to code. Sometimes, It's not all about coding.
I was involved in a relatively large server mod community, primarily as a dev, but as time went on more and more time was spent moderating the community and managing incoming work.
By getting involved, even without coding anything, you will learn a lot about how the 'core' team operates and communicates. If you are able to support by testing or triaging that can help even more. Once you get an idea of how things work you will probably also find something that you can fix.
By all means, jump into the code as soon as possible, but don't discount the other parts of an open source project.
p.s. Documentation is an area that always benefits the entire project, without requiring much more than a comprehension of the code.
Many mature software projects have some bugs marked as 'Junior Jobs'. They are issues which maintainers felt could be fixed by a newcomer.
OpenHatch[0] is a website which helps you find such projects/issues easily.
[0] https://openhatch.org/