Should You Open Source Your Product? That’s the Wrong Question

Don’t get stuck on a solution until you know what problem you’re trying to solve.

I often get called in to help companies make decisions about their open source strategy. They want to release key parts of their software as open source, but they need some help figuring out the best way to make it happen. I always ask them the same question:

Why? Why are you planning to open any of your code?

They rarely have a good answer. They’ve already decided that this is the right decision, because a board member, founder, or customer has said it’s necessary, and they are just trying to figure out how to do it. But it’s impossible to build a strategy to accomplish your goals if you’re unsure what they are.

Are you trying to build a community? To get public review of core functionality? To grow adoption? Something else entirely? By now most people have realized that open sourcing software isn’t a route to magically get free contributions so you don’t have to write your own software, but there are plenty of other myths around it.

I’m a huge fan of open source. I’m an even bigger fan of the companies behind it building a sustainable business so they can stick around for the long term. Open source is a tactic, taken to accomplish (hopefully) a key goal for the business. It has upsides and downsides, like most tactics, and it has to fit your goals.

There are damn good reasons to open source software, either as a business or as an individual. Most motivations I’ve heard from founders don’t stand up, though. Companies have built healthy communities (Github, Atlassian, VMware, Microsoft) and scalable freemium models (Github, Splunk, Slack, Trello), all with no notable reliance in publishing open source software.

The fact that these businesses have been built with proprietary software doesn’t mean yours should be. But it at least shows that your goals have multiple routes to accomplish them, and you can’t just say you need to open source your product because you want the same adoption path as MongoDB.

Many open source software companies don’t have the luxury of starting with goals and working backwards. If your project started first, and you only built a company once your community made it clear you should, then many hard questions are already decided, and you have to work around the reality of your situation. Docker is a great example of a company being built in response to community demand, because an existing project got adopted broadly enough that the opportunity arose to build a business (or in their case, shift the focus of an existing business), and some of their struggles can be attributed to the path they took.

I open sourced Puppet through a combination of ignorance and confidence. It honestly never occurred to me that I could build a company around commercial software, since I really only knew the OSS world well, and when I started Puppet, around 2005, there seemed to be plenty of great examples of successful business models around open source so I assumed I’d figure out which of those made the most sense when it came time. In the mean time, I did exactly what needed doing: I focused on building software that people loved, and then convincing people to use it. By the time I realized how hard it really was, we were too far down the path to dramatically change our strategy.

If, however, you are early enough that all options lie before you, you need to take the time to ensure you have the highest probability of success. It’s hard enough to build a company from scratch; don’t make it harder. Your team should actually view open source as a liability, in the financial sense: You’ve made a commitment (usually implicit) to your community that you’re going to spend money indefinitely to make sure this software gets better and better. Just like other financial liabilities, like office leases, employee contracts, and partnership commitments, these can be fantastic successes. But like any liability, they can just as easily be a painful drag on your work if done poorly.

I think open source can be a huge help in building community, widening your marketing funnel, increasing the quality of your code, and building software people love. But you have to do it with clear ideas of what you’re trying to accomplish and what you’re willing to do to make it happen.