Lessons from Contributing to Open Source
This summer I had the opportunity to participate in the Google Summer of Code program, where individuals join open source organizations of interest and contribute to their codebase–and get paid by Google.
I would like to share the lessons I have learned in my brief summer of contributing to open source. The lessons are in the context of GSoC, but can be applied to cases where you’re not working on a full project. I may update the article with more lessons as time goes on.
Let’s get on to it then:
Don’t overstate your skills. They will be tested and tried
My project was in the cloud-native and DevOps space. While I had been interested in that area and had taken steps to learn the tools of the trade, I underestimated the amount of time it would take me to really understand the different practical concepts needed to actually get work done. In turn, this led me to underestimate the time it would take me to complete my project.
In addition, I understood that learning things in theory hardly equate to actually understanding how they work in practice–or in this case, in production.
I’ve learned to always take an honest assessment of my skills in relation to the (any) project to so I can gauge how much time I really need to both learn new things and work on the project–and not put unnecessary pressure on myself in the process.
No room for laziness
The best way to show you want to contribute to an open source project is to contribute.
And for a program like GSoC, you must be willing to work even on days you don’t feel like it–of course this doesn’t mean overworking yourself. In my case, I felt the potential indiscipline that remote work could bring.
If you’re unproductive for a period of time, you’ll quickly become a burden to your team members. Keep in mind you’re replaceable–unless you actually aren’t– which is cool, but generally irreplaceable people are the ones that add the most value.
I had to learn to plan my schedule between learning new things and working on my project, while planning towards my final year of studies and beyond. I also realized the necessity and importance of using time wisely. The days go by so quickly, and time lost cannot be regained. There’s so much to be done in so little time, so we gotta make every second count.
Communication really is key
In the end, software engineering and open source especially, is not just about your ability to code. You need to be able to clearly communicate what you intend to do/are doing and where you are at any point in the project.
Communication can make or break a team’s progress, and their attitude/view of you. And if you have a mentor, you do not want to go for long periods of time without communicating (by long I mean maximum of 1 week). Communicate your struggles, no matter how ‘stupid’ they may seem. Your team cannot read minds…yet.
Stay with your problems until they are solved
…but take as much breaks as you need to, and involve others as much as is reasonably possible.
It goes without saying that part of being an engineer is solving hard problems. And if you need to have the tenacity to stay with ‘wicked problems.’ till they’re solved, especially if they have the potential to add value to your organization. Knowing when to walk away from a problem is also a critical skill, but it is developed with time and experience.
Pull requests are learning opportunities
At some point, I felt so scared of even pushing my code for fear that, perhaps I had merged when I should have rebased, which could lead to a messy commit history. Creating pull requests for others to review the mess I’d made was just nerve-wracking. In addition, my mentor would have to see what I’d done, and it was embarrassing just to think of that. Time and time again, however, my mentor proved to be kind and understanding. She helped me out whenever I needed her help, and gave me the space I needed to figure things out on my own. Shout out to you, Fog.
The community was also really helpful–as most open source communities are. I began to see pull requests as learning opportunities to improve my code and new things. So…pull request awayyyy!
Okay, maybe creating pull requests at every turn is not such a good idea in production, but you get the gist. Trust your gizzard (if you get this last reference, email me. We could seriously be friends.)
Practice, Practice, Practice
Nothing beats practice. You can never claim to know a technology without having practiced writing usable services or programs with it. And you will not get better at writing usable programs without practicing —which involves making mistakes along the way.
I’m definitely not the “project huncho”, pumping out projects at every turn, but I have worked on a couple of projects. Unless you’re among the legends whose side projects end up turning into products used by people and organizations, most other projects don’t exactly prepare you for production-grade programming. I suppose this is why corporations have to train you after hiring.
However, the best way to get good is to practice. And the best way to practice is to build projects. This is why I strongly recommend open source, and I wish I started out earlier. But I’m in now, and that’s all that matters (…and they lived happily ever after 🥹).
That’s it for now. I hope you finds these lessons useful as you begin or continue your journey in open source. I may create a separate post on how to get started in open source, but I’m still a noob, so that might have to wait.
*On proofreading, I get this feeling these lessons can be applied more to company teams than open source, but they can still be applied either way.
Written with StackEdit.