(This was originally posted internal to my org in June 2019)
The famous Lao Tzu quote, “A journey of 1000 miles begins with a single step” is often used - so much, perhaps, that I think we’re often blind to its use - and simply glance over it when we see it.
We are often taught to break problems down into smaller pieces that can be tackled more easily. We should also consider this approach when looking at our own processes. Make a small difference to your process. If it works, iterate and repeat.
TL;DR? I started contributing to open source. You should too.
First, a bit of history.
I’ve been actively using open source for over 20 years. My first Linux experience was in the late nineties, with a variety of small Linux distributions, eventually ending up with RedHat 4. That’s RedHat Linux - years before it split to become Fedora and the RedHat Enterprise Linux we know today.
Over the years, I’ve used a multitude of tools. Like many of us, today, much of my development toolchain is open-source based - I challenge anybody to say they’re not using open source in their stack somewhere. For several years, that’s what I did. I used open source.
At some point in the past, I realised that simply using open source was no longer feasible. I wanted to contribute, I wanted to be a part of the revolution and contribute to the explosion of projects that surround us.
I didn’t know how.
It was a daunting process. How do I engage with the worldwide pool of other open source users in a way that doesn’t make me look like an idiot?
My first thoughts were to contribute my own project to sourceforge. So I signed up and joined sourceforge. (At the time, sourceforge was the place for open source) I planned to add one of several projects I was working on at the time. This planning then went on to questions like, “How do I find people to use my project?”, “How do I find other contributors?”, “How will I keep up with all the questions and issues people start logging?”. After spiralling into a world of problems, I shelved the whole thing and carried on as I was before.
For several years after that, I regularly revisited the same thought process. Each time I ended up walking away from the idea as I believed it was a massive undertaking and would end up eating all my time.
I joined GitHub in October 2011 - still regularly toying with the idea of releasing my own grand project. Each iteration of grand, however, was becoming less so. Open source had grown, and I’d been left behind.
I was slowly coming to realise that to contribute to open source, I didn’t have to be contributing a project. I didn’t have to be making massive changes. In open source, every contribution is just that - a contribution.
Every time I visited sourceforge and later GitHub, I slowly realised that each and every step of the journey becomes as valuable as the next.
I made my first contributions in 2012/2013. They were issues. In the first case, I was so wrapped up in my own world that I never even got back to the maintainer, and for that I’m now deeply embarrassed. But it doesn’t matter. They were contributions. Even if neither of these resulted in a code change, I was now actively part of the great open source community.
2014 - one of my first code affecting contributions. I logged an issue on an eclipse plugin where I found a spelling mistake. Was it petty? Perhaps. It did, however, result in a better piece of software, and that’s the important thing. Another key learning from this was that the maintainers didn’t argue, they accepted the fix and moved on. Where was this burden of contribution that I had talked myself into expecting?
In September 2017, I took one more step on the path to open source contributor. I committed my first pull request. This was an unsolicited pull request but came from the need to close a documentation loop. To my surprise, there was no resistance from the project team, in fact, there was appreciation. This caused me to rethink most of my thinking around contributions. I realised that in most cases, the project team is quite happy to receive contributions - it’s one less piece of code/docs/etc they must write.
For the next while, I continued to make small, mostly cosmetic fixes to various (relatively small) projects. By relatively small I mean these are projects with no deep contribution boundaries. This in itself is difficult to explain, but essentially - these projects allow you to simply submit a pull request on GitHub and wait for review/merge.
At this point, I was getting quite familiar with making small fixes. So much so, that when I ran into a spelling mistake in an Openstack project, I decided I would fix it. Openstack, however, is not a small project. Due to the nature and size of Openstack, they have manuals on how to contribute. There’s a fair amount of documentation involved, and it can be quite a daunting process - especially for something as simple as a spelling fix. Nevertheless, I was determined to do this. I waded through the documentation (which turned out to be very easy to work through and took me about half an hour in the end), performed a sandbox commit and was now tooled up to make the change.
So I took the plunge. The CI system approved my change and there it sat. I looked at other changes in the project and saw that a couple of days was a normal wait for a review. In fact, the Openstack developer manuals even prepare you to have your first few changes rejected. So I waited. (Granted, I submitted my change mid-Friday). I also joined up the IRC developer chat - so I could lurk and see what the team were talking about and getting up to. At 9:30 on Monday, the project lead approved my change and it was merged in.
There was no “Who are you and why are you touching our precious?” There was no “Where do you think you’re coming from changing our code?”. There wasn’t even a “Stop! Intruder!” There was a friendly message thanking me for my contribution and welcoming any further ones. This took me by complete surprise. Even the Openstack developer manuals warned me that my first contribution would probably be rejected, yet here I was, with a first-pass change.
Emboldened by this, over the next couple of weeks I submitted several more changes. All of these were accepted. I even added some reviews to other submissions. It was at this point that I realised that this was exactly what open source was about. EVERY CONTRIBUTION COUNTS.
I then ran into an issue in Ansible. My first reaction was to log an issue, but then I found one. So, I thought, why not fix it. A fix would both unblock me and fix the original issue in Ansible itself. So I did. It took a couple of days, and required some upstream changes in Openstack, but my change was accepted and is now a part of Ansible. It was that easy.
This whole journey has taught me:
- Open source projects want contributions
- It’s not hard to contribute
- Any contribution counts
If you use any piece of open source and find a niggle, do yourself (and the project) a favour and fix it. If it’s beyond your understanding of the code to fix, that’s fine - but then log it upstream and let somebody know that it’s not right. (After all, we as developers never like hearing that there’s a problem in our code that nobody ever let us know about.)
Open source projects generally work in a system of meritocracy - the more you positively contribute to a project, the more responsibility you will be granted. This is an incredibly important point. Examples exist where organisations have ’taken over’ the roadmap of a project, by simply becoming the active maintainers. (I’m thinking of good examples of this, but there are probably bad ones, too). If you actively contribute to a project, then you should get some say in its ongoing direction. If, however, you don’t contribute, then you are at the liberty of the existing contributors as to its future.
If your use of open source is central to your product, then you should absolutely have some skin in the game. Otherwise, you could be left in the wake when the project goes in a different direction to your product.
I challenge you to give it a try. Go and make a contribution. Start small. Start with a single step.