Not too long ago, Northwestern Mutual (NM) took a bold step forward and started contributing to open source projects.

Big deal, you might say. After all, open source has been around for a long time and has millions of contributors.

The “big deal” isn’t the contributions themselves (although some are pretty fantastic). The big deal is that Northwestern Mutual—a 160-year-old, highly regulated business focused on managing risk—made a change. Our company embraced innovation, adopted agile practices and started sharing our knowledge with the technical community. This is significant because not many other companies like ours have been willing—or able—to contribute back to open source projects.

How did we do it? Let’s walk through the steps we took to help our organization get comfortable contributing to open source. If your company is just starting its open source journey, we hope these ideas help open the door to future opportunity.

Embrace Innovation

Embracing innovation is a mindset shift. It not only opens minds to what can be done, it also places a cost on not trying. This is a different way of thinking, especially when you are used to working with a waterfall-based project methodology. Once your company has started this shift, you can start talking about the cost of not contributing to open source. There is power in showing the data.

Build a Team of Passionate People

We built a team of diverse people from architecture, engineering, infrastructure, law and security. Each person brought different insights, experience with open source contributions and knowledge of how our business worked in order to make the process fit the needs. A group of passionate, diverse people empowered to make decisions and do what they do best can bring outcomes you may never have thought of.

Understand the Needs

Our first priority was to get an accurate understanding of what we needed to build out. We asked ourselves a few questions to get started.

  1. What types of contributions would we support? Bug fixes, enhancements and/or original contributions?
  2. What was the target for how long the process should take?
  3. When did we need the process?
  4. What weren’t we willing to compromise on?
Diagram of the decision process for releasing Open Source Software

Define Intellectual Property

Intellectual property (IP) – knowledge unique to your company – seems simple in theory, but is difficult to define. We put a lawyer (who hates ambiguity) and some engineers (who love ambiguity), together to define what intellectual property at NM looks like. The good news is they all survived. They also agreed that IP can be fuzzy and – when in doubt – get a second opinion.

Build the Process

Here’s our solution – a process with all the rigor our business requires, delivered with the speed of open source. Legal, security, and technical review all happen at the same time, in parallel. Results are aggregated, and the contribution moves on for final approval.

Why so many reviews? If you are adhering to good development practices, you should be pair programming, completing peer reviews of code and completing automated quality and security code scans to ensure the integrity of the product you are creating. The process above is just formalizing the steps every good developer should be doing anyway, with a step for the legal review of the open source license.

Capture the Results

We have had some interesting results over the last year. The process will continue to evolve as we learn.

  • Quick approvals ranging from 2 days to a couple of weeks
  • Contributed 11 bug fixes and enhancements to other open source projects
  • Published 10 original contributions
  • Social media – we interviewed (and hired) a person after they commented on one of our contributions

Interested in seeing more? Check out our contributions at

If a 160-year-old company can change, you can too!