My question is, how do I actually do that? How do I become a contributor for an open source project?
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.
- 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.
Have fun coding! :-)
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.
Or release some of your own software - something that other people would find useful.
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).
Step 1: Use the software
Step 2: Swear at the top of your lungs when you encounter a bug
Step 3: Download latest version from source control in hopes that it's fixed
Step 4: Discover it's not fixed, fix it and submit a patch.
PS. I was kind of teasing. Don't take me to seriously ;-).
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.
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'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.
http://www.grobmeier.de/hey-i-became-a-vice-president-070720...
Here is another link, which helps you to understand how Apache works: http://www.apache.org/foundation/how-it-works.html
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.
You will receive each day a PR or an issue of each project. Then you can see if you can resolve the bug and propose your solution.
- 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 .
1. Go on to http://userscripts.org/ and find some non-trivial script
2. Does it work with Firefox, Chrome, Opera? Sometimes a little fix can make it more portable.
3. Do you think it lacks any features, configuration options etc.? Go on and implement it.
Most of the US are opensource-licensed and small enough to get started quickly.
Most projects will want to know you before accepting anything major, as they are on the hook for maintenance once you disappear!
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.