Tips on Contributing to Projects
I have been involved in open source projects for quite a while now. While my projects haven’t seen as much following as some of the big fish they have had fair share of contributors. More often than not the contributor is a newbie full of enthusiasm and virtually zero experience with version control systems. Here are a few tips that may prove helpful to someone trying to dip there toes in open source software movement. While the tips are meant for beginners, a seasoned developer new to FOSS should find them helpful too.
Find something you can relate to
Before you even think of contributing to any project at all, find something that you truly care about. While it is tempting to pick a popular project to get involved in (and it sure does look good on your résumé) I would advise strictly against starting with it. When you start working on a project you that you cannot relate to, the enthusiasm fades away pretty rapidly and you are left with an uninteresting task on your to-do list. Best case scenario, you stick to it and complete whatever your started with grit. Worst case, you leave it and a ghost fork becomes a part of your life (okay, your GitHub profile) forever. In both the scenarios, you end up with sore taste in your mouth and decide never to go back to contributing. This is bad. The world needs more contributors.
Instead, choose something that you use regularly. Find something that you think could be done better. It can be as simple as repositioning a button in that grocery app you use or fixing a spelling mistake. As long as you care about that feature, go for it. When you’re done, you will have sense of accomplishment every time you use that feature. This keeps you motivated when you move to bigger things.
Communicate
So you have picked a project and decided to do something. It’s very tempting to fork the repo and jump to coding. Hold on! First thing you should do is to announce your plan to the maintainers and members of the project. As a maintainer, last thing I want is two contributors independently working on the same feature. Not only this wastes precious time and development effort on part of contributors, but it also puts the maintainer in position of choosing one contributor’s work over another. Secondly, project owners may have something planned that is different from what you are about to do. As much as they hate turning down a contribution, it is necessary to keep project on path.
All of this can be avoided by communicating early on. If the project has issue tracker (all GitHub repos have it) create an issue and write your plans down for everyone to see. If the project has an accessible mailing list, announce what you plan to do there. Use an IRC channel if it is available. If you are unsure whether the feature you are planning to implement falls in roadmap of the project, discuss it with the owners in detail before you start working. Maybe there is a reason why that button was placed there.
Don’t expect to be spoonfed
Contrary to what your academics might have taught you, most of the projects are not documented per class level. Most projects may (and do) have something like a quick start guide that… gets you started (duh). But form there, you are on your own. And that is not a bad thing. I’d rather prefer developers spending their time writing good, self documenting code than creating redundant documentation.
No, I will not make pretty class diagrams for the whole project. I won’t walk you through every API my services expose either. You know why? Because I think it’s pretty obvious what a class called ConnectionManager does.
Stick to the style
Every good project has its style. Naming conventions, coding patterns, even commenting styles are followed throughout the codebase. This is what makes it easy to understand without any documentation. Need to find out where a UI related constant is defined? Obviously in UIUtils class. Without this consistency, the whole project starts rolling down the spiral of technical debt.
When you start making changes to the code, study the project’s styles carefully. It is okay to write messy code for experimenting. But before you ask the project owner to merge your changes, make sure that you have refactored code to stick to styles. It saves everyone’s time.
Commit early commit often
I cannot stress this enough. Divide your code changes into small, easy to digest commits. While there is not rule regarding how frequently you should create commits, it’s ideal to create a commit when you finish something. For further reading, refer to this excellent post by Jeff Atwood.
While this list doesn’t cover everything, it should be a good starting point for people new to FOSS world. Got something to add? Let me know via comments.