This was the first year I completed Digital Ocean's Hactoberfest. I've known about the event for longer than I can remember, but only seriously considered it the past couple years. Previously I told myself I wasn't enough of a developer to pull it off, I was too busy, or countless other excuses... It felt good to finally set a goal and accomplish it. Aside from helping open source, I also learned a lot along the way. If you've ever planned to participate, maybe my lessons can help you complete Hactoberfest 2021!

Your Day Job Matters

One big reason I was able to accomplish something this year that I've failed at in the past is where I work. About a year ago I started a DevOps Engineer position at Sonatype. I've had similar roles for the past couple decades and worked with some great people along the way. However, the interview experience at Sonatype was immediately different. Sure there were questions to answer and background checks to pass, but the vibe was friendly and relaxed even when talking to the recruiter and management.

Now, after almost a year, I've got to see the culture we talked about in practice. Everything from the team interactions in meetings (the few we have with clear purpose), flexibility in remote work and "real life" hours, management participation, involvement in open source, and most recently the COVID response has reinforced why I chose to work here.

It's easy to see and feel what's good from the inside, but it's no secret... Before I joined I noticed Sonatype had top ratings on Glassdoor. There's also a strong record of being comitted to innovation. This is what made all the difference for me in 2020. I witnessed the commitment in two specific ways:

First, management sets aside "innovation days" every Thursday (and occasionally saves them up to provide "innovation weeks") where employees are free to solo or team up on anything beneficial. What's beneficial? Maybe you research a new technology, build a tool that solves a challenge on your team, take a class (improving yourself improves the world)... it is very open ended. You are free to demo your project or share what you learned, but don't have to if you're an introvert or just don't feel like it. Knowing there is regularly committed time to learning and exploring is amazingly liberating and exciting.

The second way I've seen true commitment to innovation is meaningful participation in open source. Sonatype pays employees to help shepherd open source projects (some places make it an uphill battle to open source anything). They also give a community of developers around the world an opportunity to participate in open source projects... Whether you need to scan Node.js apps for the latest 0-days, make sure your containers are in good shape, or sanity check Go dependencies... there's an open source tool for that (full list here). These all put capabilities in the hands of developers that would otherwise be hidden behind an enterprise license, which genuinely improves the quality of the software supply chain.

My PRs (tl;dr version)

Note: If it's not obvious from the last section, or if you skimmed that because it was boring, I work for Sonatype. I researched a handful of projects before deciding where to contribute, and each project I contributed to provides tooling I find useful. That said, there has to be implicit bias as an employee so consider this full disclosure!

I decided to focus on two tools written in Go because I've been creating opportunities for myself to get better in this language after a few years focused on Node.js. The first was Nancy, which scans Go project dependencies for security vulnerabilities. It works similarly to Audit.js (which I previously wrote about). The second was Ahab, which helps secure Docker images (super easy to plug into your CI process). Since the point of this article is learnings around contest participation itself (and this is a tl;dr section!), I'll let the PRs speak for themselves if anyone is truly curious about what was accomplished.

Issue 29: Deprecate --os by deadlysyn · Pull Request #42 · sonatype-nexus-community/ahab
Deprecate --os in favor of --package-manager. Minor cleanup along the way.This pull request makes the following changes: Deprecate --os (shouldn't break builds and work mostly the same thanks...
Update audit log format by deadlysyn · Pull Request #193 · sonatype-nexus-community/nancy
Dropped running count when printing dependency names to avoid alignment issues when processing large numbers of dependencies.This pull request makes the following changes: Print total count at en...
Add nancy dependency checking by deadlysyn · Pull Request #43 · sonatype-nexus-community/ahab
Updated CI config to dogfood nancy.This pull request makes the following changes: Added dependency checking to circleci configWorkaround etcd vulnBump dependencies It relates to the following ...
Issue 35 by deadlysyn · Pull Request #45 · sonatype-nexus-community/ahab
Update package manager detection to use /etc/os-release.This pull request makes the following changes: Parse /etc/os-release to determine appropriate package managerRemove dependency on which (o...

Lessons Learned

I said I learned a lot along the way, and it wasn't just about writing code or getting free mentoring from awesome developers. A big part of it centered around better understanding of the Hactoberfest process itself – how to be a better participant, and ensure success!

The first thing you want to do is have a clear goal. This is not just about what projects to contribute to (that's secondary), but what you want to learn. This should be a learning process for you! Want to write more Go, brush up on front-end skills, or get practice adding tests to an existing codebase? Whatever it is, start with why you want to participate. Then it will be easier to sort through 2^32 open source projects and identify those which best align with your goal.

Next, start early. They call September "Preptember" for a reason. Before you start writing code and generating PRs, make sure you understand the event rules. This was the first year projects had to opt in (spam prevention measure). Once you identify projects aligned with your goals, you also need to make sure they're participating . When browsing issues, look for those labeled "hactoberfest" as an indicator from maintainers on where to help. Speaking of issues – make sure you start with one! If you just write up an awesome PR, it might duplicate work or be rejected because it doesn't align with the project's roadmap. Start with an issue, have a discussion, and call out what you intend to work on.

Be patient along the way. This can be hard when you feel rushed to fit contributions in between work, school or other obligations. Remember maintainers have lives. When leaving comments or asking questions in issues or PRs, initially "@" relevant people and then give them time to respond. Don't spam the same question. If a week goes by and you have no response, it's okay to post a followup for clarification...perhaps asking the question a slightly different way or giving an example solution. This is also where it's good to have a handful of places to contribute in mind. What if one PR slows to a crawl, or the solution is harder than you thought? Pivot to another PR and maintain momentum!

While it will be tempting to plow through the code and git r' dun... don't let quality slip. Maintainers are letting you manicure their pet (or watch their grandchild – whatever analogy implies you are being trusted to care for something special). Tests won't always be necessary. Maybe you are making minor changes to code that's already covered, or working on something where they don't make sense. However, most often if you are changing or adding functionality you should also add tests. It takes a little extra time, but gives you and the maintainers confidence in your solution.

Last, go big... but not too big. What do I mean? As you're learning the codebase, look for opportunities to practice "read by refactor" and improve the quality of surrounding code. This is generally well received... maybe you can add some missing comments (making godoc linting happier), clarify names relating to what you are doing, or find and fix unexpected bugs along the way (adding test coverage as you go). So what's too big? Read by refactor is a powerful technique that ensures code quality consistently improves, but don't use it as an excuse to trumpet personal preferences. Keep any additional changes relatively close to your main objective, and avoid generating spurious noise so PRs are easier to understand by reviewers. Be kind. Maintainers might ask you to back something out or take a different approach – listen! You can browse my PRs for some examples of this back and forth. If you have a great idea that doesn't quite fit, capture it as a new issue.


It was exciting to participate in Hactoberfest, and an enriching experience overall. While there was some trepidation about completing everything on time, it wasn't as stressful as I used to tell myself it would be. I'm not sure why I let myself put it off as long as I did, but am truly grateful to have an employer who helped build the skills needed to participate and gave me the opportunity. If you've thought about participating and keep talking yourself out of it, I encourage you to go for it... help the open source community, learn along the way, and make the world a better place! Hopefully the lessons I learned help you succeed, and you'll be writing a similar blog post in 2021. The only thing to be scared of is missing the opportunity.