Open Core is Not a Good Storythree better ways to express yourself and your company
“Open core” means proprietary software. We call it “open core” to say the closed code comes from an open place, that it’s proprietary by necessity, but open at heart. We use “open core” to say that the we’d go all-open if we could, but go part-proprietary because we have to.
When we use “open core” as a kind of apologia, its muted, defensive vibe can strike the right tone in the moment. But the louder companies, investors, and the industry as whole declare that open core is a bona fide, established, viable, unapologetic thing, the less that note rings true to anyone else. Declaring for all the world to hear that you are proud of, and defined by, your otherwise regrettable compromises is not a compelling story. No one is inspired to run out and compromise, too.
If you want to make software, but can’t or won’t just give it all away unconditionally, there are three good stories the industry knows how to hear and tell about it. This post will lay them out, one by one, so you can decide which ones appeal to you, and which ones you might be able to tell about your work.
This is a business.
Rent is reality. Medical bills are reality. Retirement costs are reality. If someone’s surprised or offended to find a business lurking behind good software—which takes good people, who need good money—that’s their naivete or simple selfishness acting out, not a righteous rebuke for any moral failing on your part. It’s not for your company to subsidize the Neverland expectations of those who’ve only just got out of college, or just taken jobs at large companies that try to keep them there, mentally and emotionally.
I strongly suspect that most business folks who find “open core” comforting come to the open-proprietary intersection from the open side. That explains the popularity and generally apologetic vibe of the term. But it’s perfectly possible to start from business as business and work back to what we now call “open core” by simple deduction, from widely received business wisdom. Freemium and loss-leader strategies—pejoratively, “bait and switch” and “first hit’s free”—show up all over the place, and not just in software. “Free” as applied to software means “open source”. So there you go.
Especially if this hard-nosed business realism doesn’t appeal to you intuitively, I strongly recommend that you read up on just how solid the business case for open source can be, sans any ideological or developer-empowerment valences. Read Information Rules, a kind of short-course in applying traditional economic principles to information goods. It’s twenty years old now, predating the marketing ascendancy of “open source”. Read The Cathedral and the Bazaar, from about the same time, and marvel at just how direct, transparent, and amateurish was the “open source” appeal to business types in its infancy.
This is fair.
Rewarding the people behind valuable software is fundamentally fair. If you make ends meet by charging others to use your software, you should expect those whose software you use in turn to make ends meet by charging you. Nobody gets to expect that everyone beneath the precise link in the “value chain” where they happen to hang ought to be an independently wealthy hacker-hermit, tenured professor, or ward of the state budget.
Companies that appeal to fundamental fairness tend to nail the enlightened self-interest point. Takers should want to reward makers, if makers are good for them. When they don’t, compensation problems blow back on production. If you don’t reward software developers fairly, you can expect less good software to use and choose from. At a very minimum, takers should want to keep makers off desperation’s door, where they might be tempted to do something drastic.
But overall, companies haven’t told the fairness story well. They flub not the rational self-interest point, but the moral point. They fail the obvious consistency test.
A company that wants to invoke fairness on its own behalf doesn’t take a superior moral position simply by naming the Golden Rule. A company insisting on a fair shake for its own account—Amazon should do unto us as Amazon’s customers do unto Amazon—comes across conniving and hollow without also mentioning how the company is doing right by its own suppliers and dependencies. Frequently, pointing this out leads to a similarly hollow rejoinder: We will do unto others as we want done unto us … as soon as our checks clear, and we’re flush with cash to spare. That’s a big if, and a big demand for trust. Our money now, your money later … someday … maybe.
If the fairness angle appeals to your moral suasion, be prepared to tell and show a consistent moral position. Practice what you preach before attempting any conversions.
Understand also that you are wading into what is fundamentally a deep, dark labor issue. Read up on medieval guilds and journeymen associations. Read up on unions and inter-union relations. Read up on the professions and antitrust. Read up on corporate social responsibility. Read up on how they fail.
This is a movement.
If there’s one story software people are used to hearing and telling, it’s activism. The mythos of the Free Software Foundation looms large, even for those who came into open source well after its heyday.
Early free software activists were handsomely rewarded, but not with what they asked for. Mostly, they were celebrated for byproducts of their activism that hurt more than helped their own causes, in the long run. There is more free and open software now than ever before. But it is getting harder, not easier, to live a full, connected life without relying on opaque software controlled by others. Opaque software controlled by others usually gets developed and built with lots of tools, techniques, and infrastructure “native” to free and open practice.
As a result, the standard for mission-driven credibility today isn’t the standard for mission-driven credibility applied to RMS’ manifesto. It’s no longer enough to articulate a vision, a struggle, a philosophy, and a project. One must also demonstrate antibodies—inbuilt, essential mechanisms that prevent the practices you are trying to overthrow from coopting your greatest hits. Movements that can’t play strong defense, in addition to compelling offense, are presumed dead on arrival, and more than a little naive.
Whether it’s “software freedom” or “the right to privacy” or “the end of intellectual property” or “decentralization”, if a mission-focused story appeals to you, I can’t recommend strongly enough that you read about movements in other domains—literally anything but software. Read about suffrage and prohibition. Read about the Sierra Club and the Tea Party. Read about the American revolution and Rhodesia. Pay extra attention to when and how things go wrong. Then read RMS again, and think about how futuristic and idealistic his writing seems … after thirty three years of the Free Software Foundation.
Combos
Stories are not mutually exclusive. Software history teaches that companies, foundations, and other groups can tell more than one at a time, and that telling more than one is often more than twice as effective. Just as specific stories likely appealed to you more than others—perhaps activism and fairness more than business—different stories will appeal to others—perhaps business and fairness more than activism. The more stories you can tell in a compelling way, the more folks you can reach with a story that resonates for them.
But beware. History also teaches that it’s incredibly difficult to fake any one of these lines for very long. Disappointments double: Falling short of the image you project affects not only how others see your company, from the outside looking in, but how insiders see themselves and the company they work for, from the desk down the hall. The way you portray your company will have a lot to do with who and how you bring on, and when and how they choose to leave.
The Free Software Foundation has long told a compelling mission-based story. It has long taken pains, here and there, to emphasize that it isn’t against business use and contribution, and even encourages them. But their business line, their nods to financial and practical necessity, never felt particularly sincere. They accede to life’s practicalities apologetically or ruefully, not assertively. They don’t want to drive folks coming from the business angle away from free software, but that’s not where they come from, or really where they stand. It showed.
Experiences
The FSF’s flexibility in welcoming business interests without going out of its way points to a fundamental tension in what they call free software, in what most now call open source, and in what may now want to call open core. There are definitions and essays and books to read about what “free” or “open” mean. But in practice, that’s not how we actually learn, any more than we learn what “software” means by reading Merriam Webster or Wikipedia. We stumble into open source, or get invited, and have any number of experiences and conversations around it. Those experiences and conversations become our own personal definitions of open source.
Different folks’ experiences overlap, but they are rarely the same. Open source appeals to different people for different reasons: productivity, politics, camaraderie, efficiency, and so on. Different experiences also lead to different views and preferences on specific issues, from choice of source code repository to project governance and funding models. Those differences hide behind the very general notion of open source, which points reliably only to the good thoughts and feelings of our experiences, which we share, and not to any specifics of actual practice, which we often don’t.
As a result, “open source” works a bit like “freedom”, “community”, “liberty”, “synergy”, and “innovation”, with a pristine positive connotation, and little if any reliable denotation. When you say “open source”, I know that I should feel good about it, but I don’t know whether it’s permissive or copyleft, community-driven or company-led, Git on GitHub or a tarball on FTP, in English or Mandarin, monolithic or tiny-modular, Windows-bound or POSIX-compatible, and so on. Like singing Kum ba yah around a campfire or hearing a stump speech from a politician you already admire, when you’re feeling the generalities, they can be uplifting. When you’re feeling them with others, they can feel downright transcendent. But when you’re not feeling it, the same experience can come across sappy, affected, and more than a little disturbing, especially when everyone else really seems to be enthralled.
“Open core” accentuates the latent tension between open source feelings and open source practicalities by juxtaposition. See also “essentially free” or, dare I say it, “community license”. If the marketing value of “open core” is “open”, and “open” does work precisely because the difference between open appearance and open reality lets us impute some of the former to closed software, then inviting others to recognize the difference risks breaking the spell. Open core collapses the very fragile appearance-reality divergence that open core itself relies on for good marketing bump. “Open core” is a fundamentally self-defeating term.
Better, long term, to call open core what it is. Perhaps “commercial open source”. Perhaps “enterprise pays” or “when you make money, we make money”. Perhaps “public benefit software business”. Any story is better than “we are trying to feel good about this and get away with it, even though we know better”.
Tollbooth
Even if two people who love open source with all their hearts can’t be relied on to agree on much of anything specific in an absolute sense, there are definitely trends and heuristics. From where I’m sitting, one particular archetype of happy open source welcome has far eclipsed all others in the last ten years: sudden and exhilarating developer empowerment.
Imagine that you set off on a bicycle through a forest to summit a large hill in the distance. A few miles into your journey, you find yourself not on flat land, but at the top of an unexpected hill, on the way to your destination. Heading down the side of this surprise slope, you stop pedaling, and let the grade carry you faster and faster down, freewheel clicking, wind rushing by, all without the slightest effort. What’s more, as you reach the bottom, you find it ends just at the base of the hill you meant to climb. Carrying momentum from your unexpected descent, you get a massive, free push up the next. You’re well on your way, and not even sweating.
Suddenly discovering you can coast—that’s stumbling on the trove of open source, somewhere online, that helps you develop your software project. Suddenly that project—ascending the hill to your destination—seems far more doable, in less time and with less effort, than you thought starting out at the bottom. A project that once gave you pause, and maybe a twinge of lingering impostor syndrome, now has you feeling validated and accomplished. You still have some pedaling to do. But the great boost you’ve been given leaves you feeling, in the moment, like a software superhero. You’ve got this—with open source.
It’s a power fantasy. But for many of us, that fantasy has been all too real. Too real to question.
Back in reality, open core companies are busy setting up toll booths at the bottoms of those hills, which they built, and which they maintain every day. The companies hope that the speed you’ll pick up from their free work will make you and your company ready to pay their toll when the time comes, to keep accumulated momentum. Your MVP suddenly needs single sign-on, audit logs, ACLs, and analytics to land a big customer? Pay, deploy, and go. New CTO questioning the maturity of your choice of framework? Time to pony up for that support contract. The louder you yell “whee!” on the way down, the more and more likely you’ll be willing to pay to keep on rolling, and the more others will follow your route.
Real
Open core companies are setting up barricades and taking tolls for reasons that everyone really ought to have seen coming. Reasons everyone—especially developers on payroll at closed software and service companies—ought to understand. The people who made it possible to really believe that all your basic software needs would be met by chipper, helpful volunteers have always faced burnout, but they’re facing burnout in ever greater numbers, and word of their plight is getting around. We are coming back to reality. We are back to solving the actual problem—making good software and keeping it maintained—rather than an easy, simplified version of it that assumes away money.
Holding onto whatever we can of the previous mystique is natural, maybe inevitable. But it is ultimately counterproductive. As the difference between open source appearance, mythology, and generality and open source reality, lived experience, and specifics collapses, we are left with a clear view of the complexity of the social problem the industry faces. But that clear view, free of reality distortion, represents the best chance in decades to make meaningful, intentional change. When he have to face reality, it’s far easier to talk about it. When we can talk about it, we can start talking about how to improve it.
That reality will be part of your project’s story, like it or not. What are you going to say about it?
Your thoughts and feedback are always welcome by e-mail.