I undertook a little experiment last April – to contribute to open source projects for 30 days (similar to #blogmonth). The idea was to contribute in a way that it helps the project itself without any personal gain. For example: Implementing a feature that I need doesn’t count, but implementing something that somebody else requested counts.
Why waste your private time for *that* stuff?
That I was asked a few times. Some people don’t understand the way open source projects work. You do not have to pay with money for the software, you can use it and do whatever you want with it. But somebody has to have the initial awesome idea for a project, somebody has to implement it, write docs, handle issues and feature requests. Open source projects can only survive when contributors exist.
Personal goals:
My idea was to contribute to a few projects on github. The web UI offers a nice way to see your contributions. I do a lot of stuff for the puppet community in spare tiem and at work so I knew which projects needed a bit of help, mostly puppet modules. My aims were to improve my git skills (use it often, break stuff by accident, learn how to fix it via stackoverflow) and do a bit of testing and deal with code quality.
Recap after 30 days:
My streak started when I had to do some FOSS stuff for work in the last week of march, but I didn’t count that for my desired 30-days period. I experienced a few issues in the beginning:
- How to correctly interpret a feature request written by another contributor (we need an RFC for a machine-parseable format or feature requests)
- How to write sane and logical commits
- Dealing with different styles of programming
- Empathy for the users of the software
Everything I worked with is in English as other contributors or users write issues, feature requests and comments in English. For most of us English is not our first language which sometimes leads to communication issues. As our grasp of English is limited discussing technical problems in detail can be very difficult. Proving a detailed description of an issue you found is hard, but keep in mind that you have to describe your environment (so others can exclude side effects) and your configuration (so others can try to reproduce it) also. If you’ve a feature request you should describe what you want to achieve (or what the feature has to achieve), not how you want it to be implemented. Very often there are several ways to implement a specific feature and hopefully the person who actually implements it knows how best to do it.
git and git commits are a complicated topic. I wrote a CONTRIBUTING.md for projects I founded which describes my idea. I discussed that in a few projects and was able to convince a few contributors to write smaller commits that only encapsulate a single logical change (one bugfix, or one new feature) and not multiple. This makes a revert in the future way easier if something introduces a regression.
Every developer has his own style, some of them similar to your own, some are far far away (this doesn’t automatically mean that they are better or worse). Fathoming the thoughts of a dev by reading his code isn’t always easy, also documentation is not always present or up2date or at times even misleading. Working with many different projects or developers and reading different styles helps to get better at it, but it does take time. You know you’re good when you can determine the author based on the code style.
Empathy, the last and most important point. You maybe want to implement a feature which would break backwards compatibility. You want to change the code style to be more readable by developers which would be incompatible with old versions of $languageinterpreter (like perl or *ruby*). Also very common: you want to drop support for an older release of the language, but many people still use it and don’t want to or can’t upgrade (RedHat I hate you, I really do). Finding the best way here is not always easy, there are always people that won’t like your decisions. The goal is to speak to many people involved and find a working solution together (hey: this is the devops spirit).
Conclusion:
This was a great experience and I still contribute on a daily basis. I finally wrote my first rspec tests, I enabled over 90 rubocop cops in a puppet module, bumped many dependencies and released a few puppet modules. The biggest profit: I was able to work with so many different people. Nice and friendly people, all interested in software. I met so many new faces (via internet) and I’m looking forward to meet a few of them in person at the next conference or a community event!
If you’re also interested in contributing to open source as well or if you want to blame me because I broke a puppet module you use -> join #voxpupuli on freenode.