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.
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.
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.
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.
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.
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.
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.