Then I started using github, and everything got way easier. I started using github for my projects, then had a look at others. I did a very exiting first pull request on a minor error I found in the symfony documentation. I did a few more since then.
In this article, I would like to point out a few ways on how to contribute to open source projects. Turns out there are much more ways to contribute than fixing a bug in the code or adding a feature.
The obvios: Add some codeAdding some code to a OSS project is an obvious contribution and maybe the contribution many people think of when support a project. You can start from different perspectives. Maybe you find a bug and try to fix it yourself and then make the patch avaiable to the maintainers so it can be added to the code base. Or you have a look at the bugs in the issue tracking system (if public) and start on fixing one of the open bugs. Maybe you have a feature request and instead of waiting for someone to do it you add it yourself.
No matter where you start, your first step should be understanding how the project works. What are the requirements to submit a patch? What code conventions are in place? What testing frameworks are used and how do you execute them? Are there special workflows you should follow? Many projects have documents where all this is explained. If you cannot find them or if they are not clear to you, go ahead and ask!
After that, you can download the source code, set up the development environment needed to run the tests and add your code. You should double check it in the end, see if all code conventions are applied and only then submit your patch back. If there are issues with your code, you may have to work on those and submit your patch a few times till everything is ok and your work gets merged into the code base. Congratulations, you are a OSS Contributor now!
The helpfull: Working on the documentationA OSS project without a good documentation is mostly lost work, because if people don't know how to use it, they won't. By contributing to the documentation, you not only help users of the project but also help the project grow.
Again, you can find an error or missing part in the documentation and start fixing this one or having a look at the issues tracker. Maybe you discuss something with another user of the project and realize that there is something wrong/missing in the docs.
The start is almost the same as if you contribute code: Have a look at the docs on contributing to the docs, see if there are conventions, which documentation system is used, what you need to build the documentation locally and so on.
Then you can fix errors or add new parts to the documentation. Of course you should not introduce new errors (look out for spelling or grammer issues, especially if you are not a native speaker). You should also look at the text once more from a user perspective, someone how does not know that much about the project then you do. Can you explain it a bit more easy? Maybe a code example would be good? Are there cross references which might help users?
Submit your changes back to the project and you can call yourself a OSS Contributer!
The person in the back: Reporting problems, helping others, writing tutorialsMany people do not realize that by reporting bugs, helping others (through chats, Stack Overflow or other platforms) and/or writing tutorials or little workarounds in your blog you are also helping the OSS project rise. Bug reports are a first step to a better piece of software. A active community is very helpful when it comes to gather people around Open Source Software. Blogs covering such projects not only help people, they also educate them and tell them about the project.
Helping others needs a bit of understanding of the project. Maybe you are a user of the project and can answer some simple questions on websites like Stack Overflow? Or you can join the official chat for the project and see if questions pop up that you can help with?
If you happen to master some difficult part of the project, maybe you can write a blog post about it? People who struggle with the same problem will be happy to find some resource helping them with their problem. Maybe you found a clever way of doing a particular thing? This also helps others by showing them what is possible.
The evangelist: Tell others about the projectWhile the other contributions are "for everybody" or at least for most, being an evangelist for a particular project is harder both because you really need to love that project and because you must the type of person who can energize people.
If both is true, you know what to do: Writing in blogs about awesome parts of the software, talking about it at conferences, talking to people on twitter/in chats/in person, organizing usergroups, hacking days or other events. Such things are importent because the community can engage way more than just by using the project and because other people get aware of it.
The sponsor: Get them some airOpen Source projects, when not backed by some organisation, tend to struggle because the maintainers need to work on other stuff for their money, having not that much time for the project. In such cases donating some money, organizing an event (with catering, maybe some prominent speakers) or even paying the developers helps. And one can use it to advertise himself or a company. I don't think this is such a bad thing if the donators doesn't want to control the project. redis for example is sponsored by VMWare, and as there are only a few links on the page and it doesn't seem to interfere with the project, why not?
Of course this cost money, so it's mostly for companies who want some promotion or people with some money who want to give back.