Open Source software is a space I feel strongly about as a core fundamental requirement to the advancement of technological capabilities that make the lives of others better. I’ve never written code for the sake of proving to anyone why I am better - rather the sole focus has always been:
- Identify the problem
- Iterate to solve the problem
- Get feedback
- Repeat
I (and many others) refer to this as the “Mission”. The North Start guiding the why behind what we build - and sharing it openly in order to collaborate with those on similar missions.
Getting started
I am no seasoned veteran in the world of Open Source. Many have been collaborating and building software (for a variety of reasons) in the open for much longer than I have contributed.
The reason I wanted to write this article is coming from the background of working for employers who actually restrict individuals (employees) from participating or collaborating in the world of Open Source - of which I vehemently disagree with.
That said - not withstanding some spicy-takes here and there - this blog is not meant to reverberate negativity - so lets look at the positive side.
In search of my place
Entering the domain of open source can mean many things - Heck, “open source” can mean many things. Not to mention the million different ways to meaningfully contribute to any open source project of your choosing. So where did I start?
I started small - Pick a project that means something to you. To me, this was a variety of platform tools that I interacted with in my day-to-day work.
Approach the internals as someone with fresh eyes. I’d never seen many of the codebases before. Did the documentation match how to get something up and running? The longer a project has been around the more likely that the niche docs for how to setup and develop with the project have gone out-of-date in some regard.
Play to your strengths
There were codebases that I didn’t fully understand the internals of - but I knew what I was good at was how to get them running on Kubernetes platforms. So I went in search of their helm charts and started to look at where there was or wasn’t useful configuration that was common for the industry standards.
As I learned more about CLI tooling - I started to look for places to work on those skills while contributing to more than my own projects.
More than Code
Probably one of my more valuable experiences has been interacting with other humans. Collaborating on a common problem and working to coordinate the outcomes that would prove valuable for larger communities. This is largely in the way of looking at spaces for which knowledge was missing or in spaces which technology has changed.
I spent time navigating different groups:
- Technical Advisory Groups (TAGs)
- Special Interest Groups (SIGs)
- Working Groups (WGs)
When initially getting started - it’s very much a listening experience. But even with zero background on current or historical discussions, you can get involved with processes like scribing (note taking) which I’ve found as super beneficial and have lead to furthering my understanding on many new technologies entering the space.
By working with these groups - I found my niche in a few working groups that resonate with the problems I am looking to solve. Biweekly collaboration goes a long way if you combine those sessions with asynchronicity.
An example here is the Policy Working Group and the production of the Kubernetes GRC White Paper for which I am very proud to have contributed.
Conclusion
Being both enabled and encouraged to participate in Open Source opened up a world of personal joy and satisfaction for me. Not even considering the Freedom and Security implications of why Open Source is better than closed source - If you work for a company that prohibits contribution and you have the power for change - please do so. If I can help be an agent for that change - please reach out as I’d be more than willing to discuss it merely because I believe in it so heavily.