Much of the best open source software originates with individuals or companies that build software to meet their needs. When developers write software to solve real business problems, it leads to better software. 

SEE: Meet the hackers who earn millions for saving the web, one bug at a time (cover story PDF) (TechRepublic)

But in a conversation with Jeremy Unruh, Head of Developer Efficiency and Platform Engineering at Credit Karma, he pointed to some reasons that teams may not want to open source code. The tl;dr? The question of whether to open source code can come down to velocity.

Making developers more productive

Credit Karma isn’t in the business of software, per se. The company provides access to credit information for consumers, among other services. Along the way, the company builds quite a bit of software, said Unruh, which isn’t surprising given that engineering makes up more than half of Credit Karma’s employee base. 

Because of the imperative to protect customer data, Unruh said his team creates platform software that enables teams to build secure software but in a “streamlined” way such that “they’re not really aware of all the safeguards we’re putting in place.” By building their own platform code, it “allows us to customize the way we manage our tech stack,” Unruh noted. 

SEE: Top 5 programming languages for systems admins to learn (free PDF) (TechRepublic)  

One such platform tool is Falcon, an internally built deployment tool that Credit Karma engineers heavily depend on to manage Kubernetes services and front-end deployments in production. Falcon serves as the gateway to production for Credit Karma engineers, whether they want to deploy a new service, restart a service, or understand the state of production. Unlike a lot of platform code, Credit Karma built Falcon as a product with a user-friendly UI. 

It has worked. Falcon has more than doubled velocity in terms of deployment time, while improving security and reliability controls. It’s a significant improvement over the clunky tool they’d built on top of Jenkins before, requiring up to 15 steps to deploy a new service. With Falcon, that same process involves a single click. 

So why not open source it, I asked?

The pros and cons of open source

Credit Karma is no stranger to open source. The company has released a range of projects on its GitHub page, and has talked publicly about its work with GraphQL.

But with Falcon or other projects within Unruh’s team, it’s a question of development velocity. It’s one thing to open source code as is, but for it to have maximum chance of success, it needs to be genericized to the point that it can be useful outside a particular organization. Credit Karma has built a “really slick way of doing service deployment,” Unruh noted, but it’s tied to Kubernetes. To make that same code useful in other contexts, his team might have to remove the Kubernetes dependency. 

There’s also a fair amount of work involved cleaning up code (and documentation) to make it ready for external consumption. Arguably, this kind of work should be happening anyway, and open sourcing code can be a forcing function to ensure technical debt is retired. But companies that decide to open source could invest in preparing the code with no eventual reward. 

This is similar to what Lyft engineering lead (and Envoy maintainer) Matt Klein has said. If companies go halfway on open source, or even if they invest significant resources to make it succeed as a project and it doesn’t, it can be a “net negative,” because “Open source done poorly is not a great look for a company,” noted Klein. Appearances aside, it requires investment (engineering and otherwise) beyond what would be required to make the project useful within one company. Of course, if the project takes off, as Envoy has, then it can dramatically accelerate innovation around it such that the company that launches it derives disproportionate benefit. But there’s no guarantee this will happen.

In sum, as much as we may want open source to be the industry’s default, it may not always make sense for busy engineering teams. For Unruh, who is focused on maximizing the efficiency of his engineering teams, sometimes it makes more sense to keep cool technology like Falcon behind the firewall, rather than pushing it to GitHub.

Disclosure: I work for AWS, but the views expressed herein are mine.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see