Contributing to Open Source Software. It sounds so formal, doesn’t it? I thought that for quite a long time, and it put a bit of a mental barrier in place for me to begin my journey. I am a classic over thinker, but that’s perhaps another blog in its own right! Contributing to Open Source isn’t as scary as it may first initially seem. Let’s start with a few thoughts.
Contributing to Open Source Software. It sounds so formal, doesn’t it? I thought that for quite a long time, and it put a bit of a mental barrier in place for me to begin my journey. I am a classic over thinker, but that’s perhaps another blog in its own right!
Contributing to Open Source isn’t as scary as it may first initially seem. Let’s start with a few thoughts.
First thought - Do you need to be a developer? If you don’t write software every day, then you may be reading this and thinking “I don’t have a development background” or “I’m not sure my development skills are up to scratch”. Notice that in this post so far, I’ve used the terms “Contributing to Open Source” or “Contributing to Open Source Software”. I haven’t written “Writing code”, or “software development”.
That was a deliberate choice because Open Source isn’t successful just through the writing of code. As the African proverb says “It takes a village to raise a child”, meaning, it takes a community to come together to achieve something. We are more than the sum of our parts, and all have different skills that we can bring to a project. Whether you are a good writer, a designer, have a project management background, you will have something to bring!
Contributing to Open Source isn’t just about writing code, and your first steps don’t need to be that either! It could be as simple as raising a GitHub issue to file a bug report, or requesting a new feature. It could be updating some outdated documentation, or writing some documentation for a new upcoming feature. It could be helping to triage a number of open issues and bug reports.
One thing to bare in mind though is that each project is different.
- Check the GitHub Repository for a Contributing file. These files typically give guidance on how you can get started contributing to the project, e.g. setting up your development environment, any standards that the project follows (whether development standards, expectations on format for the bug report/feature requests), etc.
- Open Source projects (like most software projects) will be bound to some kind of license. When you contribute to the project, you may need to either explicitly or implicitly agree to this license. This is important to bare in mind, as the work that you produce is then effectively licensed under that project. Why is this important? Well, there are a number of companies and employers that explicitly prohibit their employees contributing into Open Source projects. This is something you’ll need to check on. See an example discussion on the same.
- “There’s no I in team”. Before you start working on something, make sure that you keep folks up to date with what you’re doing. You don’t want duplication of effort and possibly having to lose out on the great work you’ve been putting together!
- Likewise, communication is crucial. You’ll want to make sure that you’re not creating work for other people because you haven’t followed certain standards. Make sure to check out that contributing file before beginning to work on the project.
- There is a theme throughout these projects. Everyone has had to start somewhere, so everyone knows how intimidating it can be to get going. There are many great coaches and advocates in the community.
So, how have I contributed into open source? Think about the Azure Docs as an example, or the Azure Architecture Center. Both of these platforms code are hosted in Public GitHub repositories and are open for absolutely anyone to contribute into. Spot an issue in a docs article? You could either correct it directly by submitting a Pull Request to tweak the codebase or, if you don’t feel confident/comfortable to make the change, then raise the issue for someone else to review and act upon the change.
This is exactly where some of my first open source contributions originated. Starting small by making changes to grammar and spelling mistakes, gradually increasing the scope of my changes to fixing outdated information/examples, and create brand new documentation articles.
My journey then continued into the Hugo Community, as you can find all about in my last blog post.
So what’s the moral of this blog post? It’s simple. Contributing to Open Source sounds like a big intimidating activity. But you have to start somewhere, and it doesn’t have to be huge. Remember, evolution rather than revolution. Takes those first initial steps that you think are within your skill set, and as you grow your comfort, expand the types of activities that you’re working on.
Inspired? Then here are some additional resources that may help!
- How to Contribute to Open Source
- First Timers Only
- The Definitive Guide to Contributing to Open Source
I’d love to hear what Open Source projects you’re working on. Let me know over on Twitter, I’d love to hear all about it!
Until the next blog post, bye for now!
In this video, Chris lays out his second weekly technology vlog update talking about updates on Cloud With Chris (Weekly Vlogs, Blogs, Podcast Series episodes, Sessionize), Azure Updates, Community Updates (John Lunn aka JonnyChipz, Sarah Lean aka TechieLass, CloudFamily.info and Richard Hooper aka PixelRobots).
Imagine the scenario. You’re a developer and you need to go and build some code. You need to install a number of dependencies, a code editor and perhaps a number of frameworks, only to find the code still doesn’t compile on your machine. Probably because you’re missing some frameworks or libraries. We’ve all been there. But perhaps, we don’t have to be there. Stick around in this episode as we talk about Visual Studio Code, The Remote Containers Extension and GitHub Codespaces and how all of these can help solve that challenge.
During the 2020 Festive Break, I had a lot of time on my hands. I took 4 weeks of my Annual Leave, which meant I had the majority of December to personal time. Personal time / time off is great, but I also wanted to push myself and catch up on some pieces that were on my personal learning or achievement list for some time. I started refreshing my knowledge around Rails (having developed in it some years ago, it’s progressed quite a bit!), NodeJS, GoLang and Rust. All interesting to learn, and I’m sure I’ll be continuing on my journey with these throughout 2021. But that’s not the point in this blog post. One of the activities that I kicked off was contributing into the Hugo Community. Read on to find out more.