Read the original article on the member’s section of Medium.

Read the original article on the member’s section of Medium.

Read the original article in the member’s section of Medium.

Giving something away for free can be a fantastic way to achieve adoption, but it raises a permanent conflict. The conflict is even greater when the free products are open source.

Driving adoption is a key requirement for any product business, and a popular tactic for doing so is hooking people with something free in order to sell them products once they’re invested. The most famous example is Gilette “giving away” razors, but this model is now widely adopted by software companies striving to grow quickly but cheaply. Splunk and New Relic are examples of fantastic businesses who allow their products to be used for free in some circumstances in order to drive long-term adoption and revenue.

Success with this tactic requires mastering the tension that it introduces: The thing you give away must be valuable enough that it drives adoption, but not so valuable that people don’t eventually need to upgrade.

If it is insufficiently valuable on its own, no one will use it, but if it is so valuable that people can succeed without ever paying, then you have users but not customers.

The goal of a freemium business is to separate the commitment from the buying decision. I want you to become so successful with my product that you become committed to it, which means when I finally ask you to pay the sale is both easier and more valuable.

For you to become committed, you must be successful. You must achieve whatever goal caused you to download my software in the first place. However, in your success, you must also hit some wall that requires you to upgrade.

Managing that balance is crucial to success with freemium. Give too little away and you don’t get any adoption, but give too much away and you have a passionate community but no money to pay for building the software.

This balance is complicated by the fact that the best communities are built around authentic identities, so changing what you give away involves changing who identifies with your company and why, which is much more fraught than tuning your business model. It’s a sufficiently complex operation that it’s one of the key dials that a freemium business will manage throughout its existence.

As difficult as this balance is in a proprietary software business, it’s much harder when dealing with open source. After all, when you decide to open source something, you’re not just choosing to make something free, you’re giving your community permanent rights to something you own. While you technically have the right to keep private any further updates, in practice once you open something up you have to either keep that project free forever or let it die.

Your community considers the opening of your code a permanent commitment to maintain this software for free forever, and anything less than that will generally be considered betrayal. They didn’t adopt you, or your revenue streams; they adopted this free thing that you promised would work well for them, and they’re going to raise hell when it doesn’t. They don’t care that your business model requires that you charge for analytics, or for clustering. They need those features to be successful, you implicitly promised them success, and now you’ve got blood coming out of your ears.

In some sense, successful open source software companies require lightning to strike twice: They need to free something that it is so great you’ll adopt it without paying, then they need something else that’s also so great you’ll pay them. Most OSS companies try to provide this extra value at the margins, because getting that second lightning strike is so hard. Proprietary software companies can provide hard limits on how you take advantage of their most useful features, but if those features are open source, then of course you can’t limit them in any way. You’ve got to develop additional features instead.

It’s not a coincidence that we’ve seen so few open source software companies build large revenue streams. Most end up shifting their focus from the open source that started everything to proprietary software that drives their business. The best companies remain community-oriented, but that is by no means a given.

If you’re considering building a freemium business, you must treat the success of this balance as a key business metric. It underpins the unit economics of your business, determining how big the funnel is based on adoption and how many convert based on the willingness to pay.

Getting it right is worth it because it enables a fantastic company with low marketing and sales costs, an engaged community, and easy upgrade paths for your best users.

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.