After the Docker Free Team Episode: How to Sunset a Free Feature
Docker Free Team subscribers got an email in March from Docker saying that its Free Team subscriptions would end on April 14. The announcement caused panic in the open source community, not least of which because many found the emails confusing, so users weren’t clear about the specifics.
Facing backlash, Docker apologized in a blog post on its website, acknowledging that its communications were “terrible” but the policy sound. Within days, however, it reversed course entirely, deciding not to sunset the Free Team plan.
But Docker is not the only company to sunset a plan, or move a feature from free to paid plans, or even take a feature out of an open source project and put it in the proprietary offering. And there are more elegant ways to do so than Docker’s example.
“I think this happens for most venture-backed startups, open source or not,” said Avi Press, CEO and founder of Scarf, an open source metrics company. “If you have a model where you need to grow very quickly, the best way to do that is to give away some of your product for free.”
(A representative from Docker declined an opportunity to talk to The New Stack about the company’s experience, and instead directed readers to its blog posts on the topic.)
Moving a feature or functionality from an open source or free version is always going to be uncomfortable, both for the company and for its users. It requires careful communication and transparency. It’s probably not possible to do without making some users unhappy.
“I’m not really of the opinion that one should never get these things wrong,” Press said. “You need to be launching early and iterating quickly. Ideally you figure these things out faster and earlier, not once you’re being used by 95% of developers in the world.”
So how can organizations minimize the backlash when they start charging money for something that was previously free? Here are some considerations.
Open Source vs. Free Tier
Before going further, it’s worth making a distinction between open core companies moving a feature from the open source “‘core” into the paid edition, and closed-source companies moving a feature from the free tier to the paid tier. Both happen, but the risk of angering your user community is much higher if you’re moving functionality from open source to paid.
“If you are now monetizing a thing that other people built, then that’s the hardest bar,” said Jesse Robbins, investor at HeavyBit and founder of Chef.
That’s because building a community involves a social contract with your users, your contributors and all of the stakeholders in your community — and, Robbins said, there are some red lines around what you can and can’t do.
It’s easier if we’re talking about something that was part of a proprietary free tier going paid — especially something that’s hosted. People recognize that there are costs involved in operating free tiers, and that companies need to be profitable, said Joe Brockmeier, head of community at Percona.
Users will be especially understanding if you explicitly tell them that you’re charging now because of the costs that you incur to run the free offering, he said — going back to the theme that minimizing negative reactions from users is about open, transparent communications.
Not that there won’t be any backlash, especially if it’s something people depend on, but that with proper communication it’s likely to provoke less of a backlash than moving functionality away from open source.
Users Who Can’t Pay vs. Users Who Won’t
When companies move functionality from free to paid, it’s generally in hopes of upselling the free users who depended on that functionality. But one of the issues to be aware of, especially if the paid edition is relatively expensive, is that while there are certainly open source/free users who can pay but don’t want to, there are also users who just don’t have the financial resources to pay.
As you plan to move a feature from a free to a paid offering, you should be aware of these two groups, and think about how you can soften the blow for those who truly will never become your customers — including helping people transition from your solution, if necessary.
Transparency, Honesty, Responsiveness
Moving a feature from open source/free to paid edition might be an unavoidable part of building a company, especially one that moves fast and tries to grow quickly. Backlash is inevitable, but there are still better and worse ways to manage the transition. In the end, the goal is to make the change to increase your company’s revenue without reducing goodwill in the community.
“Just be honest,” said Brockmeier. “Just be very transparent about it and give as much notice as possible.
And as for your open source project, he added, “Don’t be shocked if somebody forks it.”
Often the most serious backlash happens not because of the actual policy change, but because of communications failures.
Acknowledge that this change is going to hurt some users. Be honest that you’re doing this because your company needs to be profitable so you can continue making great software. Be clear about which users are affected, which functionality is going away and what users should do if they depend on those features.
Expect questions, and don’t make big announcements right before a holiday weekend For example, the Rust Foundation recently proposed an update to its trademark policy for use of the word “Rust,” but announced those changes on Good Friday. The negative attention around the proposed changes would likely have been much less if community members had been able to get immediate answers to their questions in a timely manner.
Users might grumble if they suddenly have to pay for something that used to be free, but they’ll make a much bigger stink if they smell hypocrisy, are confused or are unable to get their questions answered.
Protecting Open Source’s Reputation
Open core companies should be especially wary of moving functionality away from their open source project, Brockmeier said, not just because it can damage goodwill among their own community but also because these moves damage the reputation of open source software in general.
“As more and more vendors do that, it undermines confidence in open source and adopting things because they’re open source, especially from VC-funded vendors,” Brockmeier said.
Avoiding these types of situations requires, above all, planning, said Joseph Jacks, founder and general partner of OSS Capital.
Founders should “plan and develop features with a clear understanding of their potential impact on the business model and revenue streams,” he said. “This includes prioritizing features that align with the company’s core strategy and have a sustainable cost-benefit ratio.”
Users: Don’t Take Open Source for Granted
Companies that depend on open source software also shouldn’t take it for granted that this software will be free forever.
“If you’re using open source in your business, and you depend on it, then you should be engaging with a vendor or support of that software,” Brockmeier said. “Because the alternative is that they fail and the open source project doesn’t make it, or they struggle, or they get bought up by some bigger company that has even less friendly terms.”
So while open source companies have a responsibility to try to avoid moving functionality from free to paid, users — especially those with budgets to spend — should expect to financially support the projects they depend on.
After all, as Press reminded us, “A lot of companies and open source projects have provided a ton more value than they’re trying to capture from their user base.”
