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 Amy Keibler's journey below.
What was your journey to becoming an open source contributor?
I enjoy trying out new technologies and new programming languages, so I've often encountered situations where the documentation isn't quite up to date or example code doesn't compile. In those situations, it's usually pretty easy to open a quick pull request with a fix.
Beyond that, using open source libraries at work gave me the push to go further with contributions. After working around a particular JavaScript library behavior enough times, I decided to see if I could add a feature directly and then simplify my code. Thankfully, they had a good test suite, which gave me confidence that my changes were correct. That experience helped solidify to me that open source programs are not really different from the software we write at work every day and you don't need to be a 10x wizard to participate.
What do you wish people understood about being a good contributor?
Maintaining a software project is a lot of work. Maintainers wear the hat of Project Manager, Technical Architect, Infrastructure Engineer, QA Engineer, and other roles. If a project has a documented process for contributing, following it will reduce the work the maintainer has to do, which will make it more likely they will have time to review and include your changes.
What non-code contributions are worth contributing?
Non-code contributions are incredibly important. My favorite example of atypical contributions is Rust error Twitter, where Esteban Küber will find people tweeting about confusing errors they get from the Rust compiler and use that as feedback on ways to improve the error messages. Letting a project know what issues you've encountered is a valuable contribution that anyone can do without becoming sufficiently familiar with a codebase.
Open source software has an abundance of contributions by people with development skills. We need contributions by people with good design and UX skills, accessibility skills, internationalization skills, documentation skills, and others.
What is one thing you wish you'd known before you started contributing to an open source?
Contribution requires patience. I will occasionally forget about pull requests I've opened and then get feedback half a year later. Because many open source projects are done in peoples' free time, "fun" tasks often get higher prioritization than "boring" ones.
Contribution also requires accepting that sometimes the answer to your feature request is "no thanks". A maintainer accepting your feature is taking on the responsibility of ensuring it fits with the future design direction of the project. It's better to open an issue and discuss the feature you want with the maintainers beforehand, rather than showing up with a complete implementation that you've invested time into.
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?
I believe so. To me, open source involves the idea that we can go further through collaboration than competition. Working on the CycloneDX project helps the software industry by providing a standard way of describing software deployments that can be produced and consumed by a variety of tools. Hopefully, this will provide a foundation that will make it easier for companies and organizations to meet their security needs, as software continues to have a growing impact over all of our lives.
Who's helped you on your open source journey?
There have been a number of kind, welcoming people over the years. As someone who is more reserved and less outgoing, I'm grateful to Jeffry Hesse for seeing an area where I could contribute and then connecting me to the larger CycloneDX community.
Hear more stories from Sonatype maintainers and contributors at dev.sonatype.com.
![Picture of Sal Kimmich](https://www.sonatype.com/hubfs/Sal.png)
Written by Sal Kimmich
Sal is a developer advocate for open source at Sonatype and passionate about helping engineers, ethical hackers and digital enthusiasts understand the complexity of modern software development. With over a decade of experience as a machine learning engineer in the healthcare and tech for good sectors, their work is now focused on filling the cracks in the open source software supply chain to build a better digital future for all of us.
Related Resources
![Resource Center Finos Roughs 27](https://www.sonatype.com/hubfs/Resource%20Center%20Finos%20Roughs%2027.png)
![](https://www.sonatype.com/hubfs/GettyImages-1446878403-2.jpg)