TranslateProject/sources/talk/20200427 Comparing subscription, pay-per-bug, and consulting software business models.md

[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Comparing subscription, pay-per-bug, and consulting software business models)
[#]: via: (https://opensource.com/article/20/4/open-source-business)
[#]: author: (Jos Poortvliet https://opensource.com/users/jospoortvliet)

Comparing subscription, pay-per-bug, and consulting software business models
======
Learn how NextCloud achieves business revenue that is one-third
consulting and two-thirds subscription.
![A chair in a field.][1]

At FOSS Backstage this year, I hosted a discussion on open source models and shared why I think subscriptions are a great way to support open source products.

### Picking a business model

The company I co-founded, Nextcloud, only offers its services to customers on a (per user) subscription model. Some customers ask us during the sales conversation why they cannot just get access to our engineers on an hourly basis as they get from third party consultants: pay for the bug fix or support case, and be done?

When we discussed how to build our new company in 2016 during our very first "[hackweek][2]," our business model was an important conversation. The team discussed different approaches, and we decided to go for a subscription model. Such a model felt more in line with our mission and principles to [create a great product and run a trustworthy company.][3]

Why? While hourly rates seem like an easy way to get a quick fix for a problem, getting paid for fixing issues creates an incentive to create more buggy software, which of course, was not how we want to run our business.

Let's look a bit deeper at the choices.

### Subscription

As a customer, you want the most reliable software. And when (not if, when) things go wrong, you want them fixed as quickly as possible. Our company offers customers a subscription to our services. Such a subscription includes direct and unlimited access to our engineers the moment you run into a problem. These two points are very important. It means that a customer has the certainty of having the very best resources at their fingertips at the moment they need them, and as much as they need them, in a way that only the original software vendor can deliver.

For that, they pay a fee that scales with the number of users.

### Pay-per-bug

What if, instead, you could pay per issue fixed? In a way, this choice is similar to insurance. Indeed, when you need cold medicine once a year, the cost of a health insurance policy with a monthly premium seems prohibitive. But when a car accident crushes your spine and your medical costs skyrocket, not having to sell your house makes up for that premium and then some.

There is also the bigger picture: The incentives potentially created by a pay-per-bug model. It is a simple, albeit cynical calculation: If we got paid per bug we fix for customers, leaving more bugs in our product would increase our income. Now we're not saying every company offering product consulting by the hour is extorting their customers, merely that this backward incentive exists, even when most moral businesses would not give in to it.

Conversely, now that we offer insurance, we lower our support costs by building a better product, just like art insurance providers do what they can to ensure the art kept at their customers' exhibition is secure to keep their costs low. Our support team deeply cares about how our customers use our product: a better setup and good security practices not only make happier customers; it saves them time.

Or, in other words, it helps maximize the ROI or TEI the customer gains from deploying Nextcloud.

That is what we'd call a win-win and a business model an open source company can be proud of.

### Consulting

Now I discuss this business model regularly with others, and I invariably get told: "You might be right, but most of my customers only want to pay for the bugs we fix, or for features. Consulting is our main source of income! And I have no illusions about changing that."

Yes, that's an issue. We open source folk honestly have a sales and marketing issue. And yes, you might think that, as a marketing guy, I just see everything as a nail I can hit with my communications hammer. But really, communication is core to the issue—how you communicate your value—which, in turn, requires you to be aware of your value.

Recently, I had some challenging discussions with users on our forums who were upset that our engineers had not fixed their issues quickly enough. These users were clearly business users, and giving free support on GitHub obviously isn't exactly a great advertisement for the need for a subscription. So some abuse was thrown our way, and I took the hit. When complaining about it all to a fellow entrepreneurial friend of mine, he remarked: "Isn't that good news? They were frustrated and angry because clearly, you have something to offer, they need it, and are annoyed that they are forced to pay you for it. A good place to be in if you want to sell something!" Right he was, of course.

The lesson I want to share with this anecdote is: You have something to offer. Your current customers will certainly be upset if you tell them that, going forward, they can only get your services under a subscription. But the angrier they are, the more you know they _need_ you, and you should persist!

But moving to subscription from consulting requires a great deal of discipline, including saying "no" often. We have hard, internal rules, and one of these is that sales can only sell consulting valued at up to 50% of the subscription value, and only for deals greater than $10,000.

But it has worked. The breakdown of our business revenue is now about one-third consulting and two-thirds subscription. Engineering hours for consulting work are not the limiting factor for expanding our customer base; sales and sales engineering is. We doubled our order intake last year and plan to do the same this year.

### Bottomline: Sustainability

For us, a better product and more sustainable business follows from the subscription model. It also benefits software engineers, who prefer to build a better product and spend less time on debugging issues with customers. A pay-by-the-hour model, with all the time tracking and incentive to keep customers dependent, does not work for us.

What has your experience been? Tell us in the comments.

--------------------------------------------------------------------------------

via: https://opensource.com/article/20/4/open-source-business

作者：[Jos Poortvliet][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]: https://opensource.com/users/jospoortvliet
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/BIZ_WorkInPublic_4618517_1110_CS_A.png?itok=RwVrWArk (A chair in a field.)
[2]: https://nextcloud.com/blog/invitation-to-our-hackweek-in-stuttgart/
[3]: https://nextcloud.com/blog/the-nextcloud-mission-and-principles/