Open source isn’t just about code--other ways to contribute
8 ways to contribute to open source without writing code
Talking to developers and reading about open source I often get the feeling that the general notion is that open source is just about code and commits. Put another way, "If you don't make commits for a project you are not contributing to it." Or so they say. That notion is far from the truth in my eyes. Let me tell you why.
Sure, code is what ultimately ships and has a direct impact on the users of an open source project, so yes commits and code are important. But it's by no means the only way you may contribute to a project. Projects mostly are a whole ecosystem, which is about more than just code. Here are a couple of other ways you may contribute to a project.
If maintainers don't know about issues they can not fix them. Therefore, it is crucial that you report issues you encounter and not just abandon using the project or only build a workaround. Most projects are happy to receive issue reports. Don't take reporting issues lightly either, often a substantial amount of time goes into writing a good issue report. Ideally an issue report contains code to reproduce the issue, information about the expected outcome and the actual outcome, system information, version information and maybe a stack trace or similar artifacts. I also like to include a little note of appreciation for the maintainers, but that's optional. Keep in mind that issues don't have to be about bugs—they may also be about possible improvements or desired features. GitHub even acknowledges the importance of issues by giving you contribution points for opened issues—yay!
Documentation is extremely important but often lacking, as a lot of people really don't enjoy writing it. It's a great way to help a project out by making it easier for other people to get into. Also if you found it hard to get into a project, try improving the documentation so the next person will have it easier than you did. I actually have commits on Ruby—they are all documentation commits.
Improve the website
Many open source projects have their own websites. Sometimes the information is outdated and sometimes it's just plain ugly. I remember the old shoes website—it was really ugly and looked dead (at least that were my thoughts when I first saw it). But look at it now! It looks nice and presentable. And most of it is thanks to wpp—he has never pushed a commit to shoes (that I am aware of), but this certainly was a great contribution for shoes.
Offer to help with art/design
A lot of projects would love to have their logo updated, get some illustrations for their website or similar thing. So if design or illustration is your thing, maybe go to your favorite project and ask them if they want some help with that? I know I'd be more than happy about that!
Trying out preview versions
Developers need feedback if their software works. Therefore, alpha, preview or release candidate releases are made often. Go grab one of those and try it out. If everything works—great, you just made sure it works on your system! If you find a bug—report it! That's a great help for the project.
Weigh in on discussions
Sometimes there are discussions about API changes or ways an implementation could be improved (among other things). Comments are very welcome there, maintainers want the input of their users. I once spent a whole day discussing some architectural issues I identified in a project. It was fun. Other work might be setting up a road map—Eric Watson did that for Shoes 4 one day. He's a great coder, but that road map helped the project more than any code he could have written in a similar time frame. His road map went on to be a very helpful guidance and reference point.
Questions about a project pop up all around the place. Be it Stack Overflow or just the project's issue tracker. By answering them you help other people to get a better experience with the project overall. Also don't forget that a question might hint at a problem with the project. Maybe the documentation for this part could be improved or there is a common task that might be automated or deserves a better API? Maybe you could jump in to do this?
Give a presentation about a project
There are many great projects out there, but developers may only adopt them if they know about them! If you really like a project, consider giving a talk about it at a local user group or handing in a talk for a conference. This way the adoption of the project may be increased, bringing more people to the project making it a better and more stable product overall—benefiting everyone.
If you already have done any of the above: thank you! You contributed to open source. Keep doing that if you like, if not give it a shot. If you want to get started on contributing to open source, this post of mine might come in handy. Personally contributing to open source has been an amazing journey for me so far. I enjoy it very much and have made quite some friends that way.
Originally posted on the Journeys of a young Software Engineer blog. Reposted under Creative Commons.