This is my first post here since i hardly found time and a good reason to write an interesting blog post. Nonetheless due to the COVID-19 thingy I have to get rid of my overtime hours I gathered lately and have some spare time during the next weeks now ;)
This post is about how I was selected as Core Contributor to Hashicorp's Open Source Software although I had nearly 0 experience with the used programming language and to contributing to Open Source software at all.
About myself
Always interested in IT since I was 12 or 13 years old. Went through university with information systems BS and MS, worked for some companies mainly as a developer until I switched to a DevOps Engineer Cloud Services role (if you like to call it that way) in a bigger company 1,5 years ago. Main reason was to eliminate some blind spots i had in some IT topics (how do Ops guys work, how to deal with cloud infra, how to deal with DNS, SSL/TLS etc.). Especially automating stuff is something that i was and still am really interested in. I still try to do some dev tasks as much as i can. But it became less...
My Open Source pre-story
To be honest I use a lot of open source software as well in my own projects as in company related stuff. I always had the feeling that I have to pay something back to the OS community. But as you might already know it's always hard to start with something unless you have a good reason for it. Not to talk about finding a good project to start with...
How i found the right project
Well this was really a coincidence. At the company I'm working at currently we're using Terraform (TF) to provision mainly our cloud infrastructure and Azure is the provider where we host most of our IoT platform.
Since we have a good relationship with Microsoft we're also using much of their really new stuff even before it's GA. Same happened back then when I wanted to put some resources into our the infra-as-code (IaC) TF repo but noticed soon that some resources are not yet part of the Azure Terraform provider.
I had three possible solutions for this issue. Two were short term workarounds which I wanted to avoid if possible and the third was to just implement what was missing.
Short term:
- don't use IaC at all -> manage missing stuff manually (ugly...)
- use the ARM template deployment within Terraform (ok for the moment but not a scalable solution...)
Long term:
- implement the missing features
As you can imagine I went the third way but to finish my tasks i also used the second short term solution until the missing features were implemented.
Overcome the obstacles
As soon as I found the GitHub repository for the Azure provider I noticed that I'd have to leave my comfort zone since I never really contributed heavily to such a project before. Here's a list of the main things i needed to figure out:
- what languages are used? -> Go
- how to build the provider locally? -> README.md is always a good starting point
- how does the dev process look like? -> this was more tricky but the slack channel helped me a lot
First of all I quickly realized that I'd need to learn Go. To be honest it's one of the simpler languages in my opinion. If you have some experience with 2 or three other imperative languages it's quite easy to adapt.
Next thing was that learning a language is one thing but what for me most of the time is more difficult is learning the tooling around it. How does the compiler work? How to write & run tests? Which IDE or code editor is best? Do the compiler errors really help me? It took me a while to get everything up&running but it paid off.
The most important thing then was to figure out how the dev & merge process looks like. Is there something like a contribution document? Are there some rules to follow like linting or tests? Luckily there is a Slack channel especially for contributing to this provider and the guys there are really helpful. I'd advise anybody to check out if there is something similar if you want to contribute to an OS project. Otherwise I'd have failed with no doubt. If there is no such thing then a good idea is to look at already merged pull requests and look what the main contributors told the devs and how they approached the development process for a new feature or a bug fix. Also look at their commits to get some insights.
Honestly speaking it's always a bit of work to get your first feature into a repository unless it's a simple documentation change. But you learn a lot during that trial & error phase so it's definitely worth the effort.
Make it a habit
As soon as your first PR is merged you probably feel a bit of proud. You shouldn't stop with a single PR if you want to get used to it. I started to check the issues of the project on a daily basis to see if there are things to jump on. Of course I didn't try to implement really big features at the very beginning. Start with small tasks and make this a habit or a routine. Then you can start with bigger things. Don't worry your work will be appreciated :)
Appreciation of your work
Always keep in mind that the work you're doing is not just for you to learn something and to fill some gaps in software that you personally use. You also help people around the world who are in a similar position like you are. For me it was a great experience to see people thanking me in person because I enabled them to provision their Azure infrastructure in a cleaner, better and faster way.
My Highlight was when At the beginning of the year I received an email from Hashicorp that I was selected as one of the core contributors to their open source software. They thanked me and I got an invitation to one of their conferences in either the US or Eruope. It really made me proud and it shows that the OS community is really appreciating your willingness to help and improve existing software.
Make a long story short
If you want to start contributing to an open source software then don't wait. Let's summarize my findings:
- choose a project that you already use in one of your applications
- don't reject if you're not familiar with the language or technology
- start with small changes to get insights into the dev process
- try to get in contact with other devs or the main contributors in case you need help
- don't hesitate to ask for help
- make it a habit for constantly learning
- you'll receive some recognition sooner or later
- anyone can contribute
- just start
I can imagine that these are tips you already read a lot in other posts. But I hope that this will show you that it's not impossible to make an impact and that it'll always pay off one or the other way. The only thing you need is to start somewhere.
Hope you enjoyed my first blog post so far. Open for critics, questions or other remarks.
Top comments (1)
Well done joining a great open-source community!
I've often found that some of my colleagues in previous jobs didn't dare contributing, or even reaching out to Open-Source developers, for fear they might be some kind of busy gurus on a cloud… The truth is, Open-Source maintainers are often happy to help you get started with contributions (and I've had my share of mentors who helped and taught me lots of things!).
I like to say if someone makes an effort to contribute, I'll try to match their effort to review and encourage them (though sometimes I fail by lack of time).
Keep up the good work!