How to foster the adoption of an open-source mindset

The old world of open source

Over the last six years, our interrelated Digital Transformation, DevOps and Open Source journeys have brought a lot of changes to Capital One.

I was hired by Capital One as an enterprise architect about seven years ago and have been an integral part of this transformation. This was an “up close and personal” experience for me. At the time, our development teams were mainly out-sourced. We were 100% waterfall and full of manual processes from our builds to our deployments to our testing. We were in data centers and had not moved to the Cloud. We were also using mainly commercial software and open source alternatives were strictly against policy unless specific approvals were obtained. This is how almost all large traditional enterprises worked during that time.

I still remember when I first started that developers had to fill in an Open Source Approval Form and send it to the Legal department with their VP’s signature. And then Legal would look into the request and send back a response on whether you could use the software, library, or code or not. It felt like banging on their door, but with emails and faxes. Developers and Legal did not understand the other’s role or stake in the process and this was a major misunderstanding that we had to work through.

The new world of open source

Needless to say, in the new world, we no longer handle our open source process this way. We do not print forms and we do not fax anything or knock on each other’s door for approval. In fact, we’ve built deep teamwork between Developers and Legal, including a legal team who specializes in helping developers use open source software safely. But how did we get here?

This goes back to how we started on our amazing DevOps journey. The first thing we realized on this journey is that if we were going to use CICD in this process, we needed to move beyond a commercial SCM that really did not fit the development model that we wanted. We struggled a lot with this decision six years ago when choosing an open source alternative. There were a lot of questions about using a “free” tool as a critical component of our development process: Who are we going to call if it breaks? Who is going to support it? What happens if there are vulnerabilities that allow someone to infiltrate or steal our code?

We managed to address these concerns and started using an open source SCM. However, we soon hit the next hurdle. Each of our development teams had their own approved set of open source libraries, frameworks and tools. These were stored in the teams’ SCM repositories. This meant there were multiple copies of the same things all over Capital One. A lot of them. So, we dug into these repositories to see what they contained. We found some custom packaged open source libraries that were too old. We also found many modified versions of standard open source libraries. Many of these were “stuck in time” and could not be upgraded. In short, we did not have a clean dependency management solution and a “binary repository.” At this time, we brought in an open source tool to solve this.

But, the question remained, how do we handle the custom and modified libraries?

We soon realized that the only way to get out of this bad situation was to start contributing back. Once we have a library sitting in our source code repo and we find a bug and fix it only for ourselves, we are doing two things wrong:

1. We are preventing other teams at Capital One (and beyond) using the same library from benefiting from our fix.
2. Our project is “stuck in time” because we cannot upgrade anymore without losing the fix.

Changing our mindset

These two realizations lead to a conversation in 2013 about if Capital One could and should contribute back to the open source community. The initial response came from a legacy mindset — this was against our policies. Why should we give our IP away? Why expose ourselves to possible legal and security implications? Who will even use and benefit from this? How could this impact our reputation?

It’s against our policy! Let’s change our policy.

We came up with answers to the legacy mindset questions. Yes, we don’t want to give away our IP but there are ways to contribute back to open source without exposing our key business processes. If we’re unsure of the legal implications, then let’s collaborate with our Legal department, let the legal community have an open discussion with the development community and see what happens if we increase communication and learnings between all parties. If our software is useful, engineers outside of Capital One will use it. Finally, we have a good reputation on delivering software that touches on how people access their finances, contributing to open source will contribute to this too.

And our answers were understood and accepted. In 2014 we contributed back to our first open source project, a simple library used in test automation!

Going open source first

Since 2014 we have made many contributions to all sorts of projects — some are large, and some are small. We have created an open source program to centrally manage open source activities and partnerships with legal, security and engineering that pushed our usage even further. Which lead to our next big move.

Let’s take it to the next level. Instead of just contributing to existing open source projects, let’s make our own.

But then, the question was, what project do we sponsor and support open sourcing? We needed something that was valuable and useful as a dev tool but not directly related to our core business. So we settled on open sourcing one of our internal DevOps tools in 2015.

Our other very popular project, Cloud Custodian — a rules engine for cloud security, cost optimization and governance — has more than 120 contributors. And all in all, the Capital One GitHub hosts 29 repositories.

We are also helping to push forward discussions in the greater community as a member the Linux Foundation and the Apache Foundation, as well as the TODO Group. We’ve also built strong internal processes to handle the launching of open source projects, including the branding, governance, resourcing, and funding involved in being committed to open source.

Why do this?

Open source software opens up the culture of continuous innovation that makes things better for our entire industry. Gone are the days when software was created only by big commercial software companies. Now big enterprises and small companies alike are solving their own problems and open sourcing them.

Open source software has changed how we think of culture, collaboration, partnership, community building, and how we hold discussions about development best practices. A good idea is a good idea no matter where it comes from. A small company, a large company, a senior leader, a developer. Open source lets us collect the best-of-the-best ideas and build best-of-the-best websites and applications with them.

Capital One remains committed to using, contributing to, and launching open source projects. Pay attention to our GitHub to see our newest projects and changes to our existing projects.