Editor's Note: We're celebrating February 3rd, the day the term "Open Source" was first coined, as World Open Source Day here at Sonatype by recognizing our incredible maintainers and contributors, and the open source projects they support. Read all about Paul Horton's journey below.
What was the first open source contribution you ever made? .png?width=300&name=Copy%20of%20Circle%20Formatted%20Headshot%20(5).png)
My first (real) open source contribution was some typo fixes in a readme file.
What was your journey to becoming an open source maintainer?
As per most, I'm a self-taught techie. I've done development throughout my career amongst many other things, but as I joined Sonatype there was a "hey we need help" for CycloneDX Python tooling - and I enjoy writing in Python. Make no mistake - I'm no Python guru (far from it!), but the projects needed some help, it was interesting and I felt able to help - so I did.
Never looked back. I've learnt so much, and also met a bunch of great people (virtually) on the journey.
What do you wish people understood about being a good contributor?
Consistency - and being present. One-off contributions of course are helpful, but consistency within a project or area really does help. You bring more than just your coding skills - you become an expert in the project and related material, which only leads to a better project.
What non-code contributions are worth contributing?
Loads. Documentation is an easy one, but what I love to see as a maintainer is real users of the projects raising ideas and requests for new features or fixes and then engaging with us to work out the right way forward.
What is one thing you wish you'd known before you started contributing to an open source?
More Python?
Open source is both a philosophy and a legal framework. Does the "spirit" of open source impact the way you code with your contributing community?
Absolutely. If this was a commercial venture, you'd think about your customer's needs. In Open Source, your customer is potentially everyone. To me this means we have to:
- Document well
- Take all feedback with grace - what is obvious to you as a Maintainer, clearly wasn't - so we can do better
- Be collaborative - open source is about the community anyway!
- Be good custodians - open source doesn't (generally) benefit from Software Architects and Teams of highly paid engineers, but we can still try to ensure a project retains it's key focus and purpose
Who's helped you on your open source journey?
Key people who've helped me:
