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.
Two decades into a software career, I’m still moved by its potential to improve people’s lives through connection, automation, and access to information, yet I’m less convinced than ever that our financial systems are built to get the most out of it.
This is the first post in a series I’ll be writing on the structural problems in venture capital. These problems aren’t a condemnation of the industry, they’re an attempt to outline where the industry fails the market. This failure helps to explain people’s experiences, but I think also helps to outline the opportunity and need for other ways of funding companies. These ways will also have flaws - they’ll likely not be great at building unicorns - but they’ll be finding people and markets ignored by the current environment.
Like the general financial industry, the world of venture capital has become adept at using money to create more money, but it does not consider of the wisdom of its actions. It chooses easy answers, thus leaving harder but better questions unexplored, and accepts high collateral damage to the employees, customers, and industry that at best is painful and at worst is pure exploitation.
I am pulled to build more software that, like Puppet, helps people get higher quality work done in less time and with more joy. But that kind of utopian phrasing is used by every company in silicon valley, whether they do advertising arbitrage or sell you pet food, all while asking their workers to work crushing hours for lottery pay, no safety net, and 19th century ideas of labor force participation. The devaluing of women and minorities as either workers or buyers is both discriminatory and bad business. It’s true I’ve heard no overt support for child labor, but I expect that’s mostly because kids don’t have CS degrees from Stanford or Harvard.
I believe it is possible to design a kind of financing vehicle that is less subject to these flaws. There is a lot of money to be made in enabling the whole market to participate in the technology economy, and given that productivity has stalled since 2004 (coincidentally around the time that social networks and attention-seeking advertising-driven business models took over), there’s a lot of opportunity to deliver value by increasing productivity.
The major concern about increasing productivity is that it generally means fewer jobs, and the lowest-skilled workers tend to be first and hardest hit. I do actually believe in reeducation and the movement of labor to new opportunities, but you can’t ignore the trauma of career changes and industry churn. My work at Puppet showed that empowering people at the front line is how you drive both change and value. Too many industries focus on getting rid of the experts at the coal face, when instead they should look to elevate them. This would improve productivity while developing careers, instead of destroying them.
Unfortunately, venture capital is structured to require trauma to everyone involved except the investors. Too often, even the limited partners who are the source of capital suffer, with only a few firms delivering the kind of returns that the asset class purports to offer. The industry is built around making many bets and expecting most to fail. Even worse, every company who wants to participate must make a claim to be able to reach these heights, even if they don’t believe it, and then they must risk their own death attempting to keep that promise.
The model itself requires that companies either go public or kill themselves. Nothing else fits in the spreadsheets. Again, this guarantees trauma to nearly everyone involved - even the ones who make it out suffer the whole way, leaving a trail of burned out employees and failed customers.
I think there are amazing companies waiting to be created that can deliver life-changing benefits but can realistically “only” generate $30m, or $50m, a year in revenue. At 25% margins for software, these can be huge sources of profit, but a venture capitalist would derisively call that a lifestyle business and either not fund it, or force it to kill itself in an attempt to scale beyond its natural size. These can be great businesses, but because business funding generally fits into either conservative bank loans, or 10x-oriented venture capital, there’s no model today that respects them. Jason Fried and DHH at Basecamp have doneatonofgreatwriting on this.
Jennifer Brandel, Mara Zapeda and others have launched the Zebra movement, focused on helping founders shut out of the VC world start companies that enrich themselves and their communities rather than their investors. I think this is an awesome effort, and has been an inspiration to me.
It’s true that this kind of company could not have as high a failure rate as venture capital does, but, ah, that’s not exactly complicated. I mean, VC literally requires failures of most of their companies, so I’ve got a nice anti-pattern to work against. There are well-worn practices for improving operations, people, and efficiency at even young businesses, but VCs haven’t bothered to invest in any of them, because again, they expect most everyone they work with to fail. Vista Equity, among many others, has shown that being more than dumb money can be more than just talk.
You might say there aren’t enough entrepreneurs out there, and all the great ones are focused on building unicorns in silicon valley. I say phooey. Tell that to the millions of people who start restaurants, corner shops, and franchises around the US. Frankly, tell that to all the people who pitched the valley but weren’t white men, or couldn’t afford to live in the bay area, and thus could not get funded. Because the valley itself refuses to believe great entrepreneurs can be women of color, or uneducated, or have a humanities degree, there is a long waiting list of great people ready to be given a little money and a little trust.
Silicon Valley today is baseball before Jackie Robinson, golf before Vijay Singh and Tiger Woods, tennis before Arthur Ashe and the Williams sisters. It’s the World Series with only North American teams, the World Championship game with only American athletes. It might do great things and be a great spectacle, but it’s weak sauce, because you know you’re not really competing with the best. In fact, you’ve structurally guaranteed you won’t, with all your stories of pipeline problems, lowering the bar, and various other grandfather clauses.
I do not believe in the primacy of ideas. I do not believe great entrepreneurs are in short supply. I do not believe we will run out of awesome opportunities in software in my lifetime.
I want to collect funding that will enable those unsupported entrepreneurs to reveal and develop their greatness, I want to build software companies in spaces that currently have no software, and I want to generate great returns for everyone involved without hemorrhaging people and money.
Yes, I know that means I have to find a different way to deliver returns to investors, because I don’t want my portfolio companies to have to sell. Yes, I know that means I will be creating a new asset class, with all the complications that entails around convincing LPs to invest in it.
The fact that others dismiss it out of hand for being impractical is exactly what excites me about it.
Please follow along in the rest of my series as I delve into the individual structural flaws in venture capital that I think outline what a competitive funding instrument must find a way around.
It’s only a good practice if you have the cultural discipline to make it work.
Stopping the factory used to be sacrilege - companies figured they were only making money if the line was moving - so when Toyota adopted this practice on their manufacturing line is was a huge shift. It was taken so they could resolve quality problems immediately, which saved them time and money because otherwise the problems occurred in many cars and had to be fixed later. It was better to pay the price of stopping the line now than the price of redoing the work later.
This was a huge cultural shift throughout the organization. Management had to recognize the cost of fixing quality later, and change their short-termer mindset around the moving line. The workers on the line had to learn not to let problems slide by, to ask for help immediately and not rest until the problem was truly resolved. Everyone had to learn to diagnose problems in the line without blaming individuals, otherwise trust was impossible and the real problems could not be diagnosed. (This is also where Toyota developed their ‘Five whys’ practice for getting to the bottom of problems.)
While we’re obsessed with individual techniques like Kanban, the team at Toyota knows that it’s culture that allows them to win, not the tools they use. That difference is also exactly why it took decades for the rest of the industry to catch up: You can adopt technology quickly, but culture? Not so much.
We experienced the same problem when we tried to adopt this practice in our software teams. People loved the ability to stop the factory, and they used it all the time. Often, it did actually increase the quality of the work we did. But overall, it made things worse for us, not better. It was causing arguments, bad relations, and most importantly, was reducing our long-term efficiency, not increasing it. It became nearly impossible to ship software.
What went wrong?
We had adopted this practice without developing the cultural discipline to make it work. People weren’t stopping their own lines to resolve systemic quality issues; instead, they were stopping the work of other people to question their decisions. A technique for improving our work became a technique for attacking our strategy. Disagree with the product that team is building? Stop the factory! Don’t like the database they chose? Pull the cord!
Yuck. That’s not how that’s supposed to work. It didn’t help that I’ve always pushed hard for people at the front line to be opinionated and educated about as much of the product as possible. Suddenly they’re applying those opinions to the work of others, and we’re not building higher quality products, we’re just arguing non-stop about what we should be building and how.
This required that we develop a couple of new cultural skills. When you read about the Toyota system, it’s striking how much of what they accomplished was essentially cultural technology - that is, tools for developing and sustaining culture - rather than manufacturing tech.
Our failed experiment at letting anyone stop the factory showed that first everyone needed to understand the value in stopping the line. We started to point out that they should be focused on their own work, not others’, and thus should only be able to stop their own line. Most importantly, remember back to the point of pulling the cord: You’ve discovered that your own work is compromised because of a quality problem in the system, and you need time and help to fix it. That had to be why we stopped the line, and nothing else.
That being said, people’s concerns about decision making in other parts of the organization needed to be heard. Expert teams should being given the power to build what they think is best. But even the best teams need outside reviewers, need other experts to question their assumptions and conclusions.
Our work cycle needed to include productive, constructive feedback opportunities. The best process like this I’ve ever seen is in Pixar founder Ed Catmull’s Creativity, Inc, where he describes their “Brain Trust” system for helping directors make great movies. This is such a great system that it’s worth reading yourself, but the aspect that stands out is the responsibility of the team giving feedback to the director:
Your job is to help them see the flaws in their proposal. You can not and must not propose solutions, and you can not demand that they agree with your complaint. Even if you’re the CEO. You are a collaborator helping someone do their best work, not a competing director trying to get your ideas into the movie.
See the parallels to the value in stopping the line? It’s about improving the quality of work, not making a power play, or being right about something.
Pixar has a critical second layer to this process: Management decides whether to ship the movie. This allows them to give the director full responsibility for the movie. If directors don’t agree with the team’s list of flaws, that’s fine, but in the end, you have to convince the management team that the movie works.
The thing I love about this is it gives you concentric circles of iteration and control. The movie team makes decisions constantly about what to do and why, then they loop out to the Brain Trust to get feedback on what they’ve done, and finally there’s a business cycle that determines whether the movie should ship. Everyone gets to contribute, but your business concerns are isolated from the work cycle, giving teams the freedom they need to build something great.
I was never able to figure out how to adapt their process to software, but I hold out great hope that there is a way, it just requires a lot of evolution. Pixar gets to take five years to make a great movie, but you never get that kind of window to make software. They also kept all of the iteration inside the building, where modern software should be built in layers, in collaboration with your users and the market.
Even without being able to directly adopt a better practice, we recognized the need for two layers of process. We thinned down people’s ability to stop the work of others, and at the same time built feedback loops at larger intervals and in different forums for strategic concerns to be heard. We also began building cross links between teams that allowed those with concerns to collaborate with those doing the work, rather than leaping in and shouting ‘stop!’.
There are many great inspirations for how to build better software, faster, but all require some level of adaptation. I am absolutely convinced we will see a software production system as coherent and clear as Lean Manufacturing, but I also think it’s going to take a long time, a lot of experimentation and failure to get from here to there.
Hopefully our experience, our successes and failures, can help you get there faster.
I was asked by a CEO recently, “How do I know if my product is ready to scale?” He thought he was ready to raise money and start growing the company, but he didn’t really know how to be sure.
Venture capital exists to invest in enterprises that have a huge opportunity but are also a big risk. Yet VC firms tend to actually be pretty conservative, relying on pattern recognition and social networks to make their decisions. This turns investor pitches into bizarre encounters where you have to help them see the huge risks in your business and how this risks can generate massive returns, but you also must convince them that you have all of that risk managed, so there’s no reason to be afraid. I’ve been turned down so many times by investors “until we’d taken the risk out of the business,” and every time, I’d sit in the car outside their office park thinking, “But don’t you exist specifically to make big bets?”
I can’t tell you how to raise money, because no matter what it’s hard, and there’s no special trick to it. Well, there’s one trick: Sell a company for a billion dollars. Do that, and you’ll never have trouble raising money.
This article is only for those who are not quite so lucky.
What I can help with is framing your company so that you can more coldly see and explain where the risk is, and with that hopefully you can help others get excited about the vision in your head, the beautiful thing you’re trying to build.
Step one is understanding your market risk. If you’re raising money, you have to convince your prospective investors (if you’re talking to typical valley VCs, anyway) that you can build a company that can do $100m in revenue at some point. So, convince me your market can support a company that can hit that scale and still grow. That means the market needs to be hundreds of millions, and probably billions. With Puppet, we knew the overall management market was between $6B and $25B a year, depending on your definition, which made this part pretty easy for us, but lots of companies are creating a market, so they have to spend a lot of time on this topic.
The next big question is why you, particularly, will win. Sometimes this is called technology risk, but companies win for many reasons other than technology, especially these days. Puppet didn’t necessarily have the best tech in the world, but we had a focus on the user that no major player in our space had. Everyone else was worried about the buyer, and we focused on helping the individual users succeed. Other companies have a cultural edge, or even just a mindset that others can’t copy. Whatever it is, though, there needs to be some reason why you’re going to take this big, awesome market.
I call this strategy risk. You’re planning to take the market in a particular way, and you think it will work but you don’t really know until you play.
A high-growth company usually trades off strategy and market risks. If everyone else agrees this is a great market, then you’ll have lots of competition so you need a unique strategy that sets you apart. If it’s a mature market with clear revenues and margins, you need a great strategy to fight against big incumbents, who won’t go quietly. If, on the other hand, no one else agrees this is a good market, and you get it all to yourself, then the strategy doesn’t need to be differentiated, so you can run the least risky strategy you can think of.
You can’t walk into a VC’s office and say there’s neither market nor strategy risk, because that business is just too obvious. It’s either so obvious it’s actually stupid, or so obvious that you’re one of a hundred players running the same game - both of these are bad bets. You’re not getting that funding round.
The last piece is execution risk. You’ve got a good market, you’ve got a solid strategy. Now convince me that you, particularly, can build a team and make this happen, within the window you have available. This is 99% about the team. Can you hire people? A lot of them? Get them working together? Do you know how to ship software, sell software, market it, etc? Some of this you can do through force of will, some you can do by just being smarter or faster, and some requires that you really nail a couple of pieces, but most of it is about building and scaling a company that can execute your strategy. This is the grit, the work, the hard part. The best strategy in the best market is worthless if you can’t do the work.
There’s one more critical point about risk. It should be obvious, but somehow it’s not.
You want to minimize the risks you take. There’s something about what you’re doing that’s unlikely, probably scary, and quite possibly stupid. That thing has to exist, because it’s what makes your business valuable. Without that huge risk, you can’t possibly achieve the massive payoff you’re looking for. Take that risk, put it on a pedestal, love it.
And then do everything you can to not let other types of risk into the rest of your business. If you know your major risk is strategy, why introduce a massive execution risk at the same time? No. Your work is scary enough that you should be conservative everywhere possible. Pick something you know works when you have that luxury, because you won’t get it very often.
This frame should at least get you the first three slides of your presentation. There’s plenty more to know before you can convince someone you can go out there and win, but being able to clearly talk through the risks in your business and how you’re managing should at least help you get a seat at the table.
I’m a tech founder and recovering SysAdmin. I helped found DevOps and grew up in open source. These days I am convalescing from a decade of physical and mental neglect while running Puppet.
Read more
