Tag Archives: Features

In Defense of Subscriptions

Posted on by
Reply

It’s not hard to see the world has moved away from discrete software releases to a model that favors recurring periodic revenue. Gone are the days of a bi-yearly office suite offering or a tentpole version of an operating system that might gain some features down the road. Instead we now pay a yearly fee to use the program or application and in return we get lots of new things on a somewhat stilted cadence.

There are a lot of things to decry about software subscription models. I’m not a huge fan of the way that popular features are put behind subscription tiers that practically force you to buy the highest, most expensive one because of one or two things you need that can only be found there. It’s a callback to the way that cable companies put their most popular channels together in separate packages to raise the amount you’re paying per month.

I’m also not a fan of the way that the subscription model is a huge driver for profits for investors. If your favorite software program doesn’t have a subscription model just yet you’d better hope they never take a big investment. Because those investors are hungry for profit. Profit that is easier to see on a monthly basis because people are paying a fee for the software monthly instead of having big numbers pop up every couple of years.

However, this post is about the positive aspects of software subscriptions. So let’s talk about a couple of them.

Feature Creatures

If you’ve ever complained that an application or a platform doesn’t have a feature that you really want to see you know that no software is perfect. Developers either put in the features they think you want to see or they wait for you to ask for them and then race to include them in the next release. This push-pull model dominates the way that traditional software has been written.

How do those features get added to software? They do have to be written and tested and validated before they’re published. That takes time and resources. You need a team to add the code and tools to test it. You need time to make it all work properly. In other words, a price must be paid to make it happen. In a large organization, adding those features can be done if there is sufficient proof that adding them will recoup the costs or increase sales, therefore justifying their inclusion.

How about if no one wants to pay? You don’t have to look far for this one. Most of the comments on a walled garden app store are constantly talking about how “this app would be great if it had this feature” or “needs to do “X” then it’s perfect!” but no one wants to pay to have those features developed. If the developer is already charging a minimum for the app or giving it away in hope of making up the difference through ad revenue or something, how can we hope to encourage them to write the feature we want if we’re not willing to pay for it?

This is also the reason why you’re seeing more features being released for software outside of what you might consider a regular schedule. Instead of waiting for a big version release to pack in lots of new features in the hopes of getting customers to pay for the upgrade developers are taking a different approach. They’re adding features as they are finished to show people the value of having the subscription. This is similar to the model of releasing the new episodes of a series on a streaming service weekly instead of all at once. You get people subscribed for longer periods instead of doing it only long enough to get the feature they’re looking for. Note that this doesn’t cover licensing that you must hold to use the feature.

Respect for the Classics

One other side effect of subscription licensing is support for older hardware. You may think this sounds counterintuitive. However, the likelihood that an older model of hardware is going to be supported later in life is due to the fact that there is no longer a need to force upgrades to justify hardware development.

Yes, there are always going to be releases that don’t support older hardware. If it’s something that needs to use a new chip or a new hardware feature it’s going to be very difficult to export that back to a platform that doesn’t have the hardware and never will. It’s also harder to code the feature in such as way as to run hardware that has varying degrees of support and implementation capabilities. The fact that an iPhone 7 and an iPhone 13 can run the same version of iOS is a huge example of this.

More to the point, the driver to force hardware upgrades is less impactful. If you’re writing a new app or new piece of software it’s tempting to make the new features run only on the latest version of the hardware. That practically forces the users to upgrade to take advantage of the new kit and new apps. It feels disingenuous because the old hardware may still have had a few more years of life in it.

Another factor here is that the added revenue from the subscription model allows developers to essentially “pay” to support those older platforms. If you’re getting money from customers to support the software you have the resources you need to port it to older version as well as continuing to support those older platforms with things like security updates. You may not get your favorite switch supported for a decade now but you also don’t have to feel like you’re being forced to upgrade every three years either.

Tom’s Take

I go back and forth with subscription models. Some tools and platforms need them. Those are the ones that I use every day and make lots of sense to me to keep up with. Others feel like they’re using the lure of more frequent feature releases to rope users into paying for things and making it difficult to leave. When you couple that with the drive of investors to have regular recurring revenue it puts companies into a tough spot. You need resources to build things and you need regular revenue to have resources. You can’t just hope that what you’re going to release is going to be popular and worry about the rest later. I don’t know that our current glut of subscription models is the answer to all our issues. However, it’s not the most evil thing out there.

The Devil Is In The Licensing

Posted on by
1

If you don’t already know that I’m a co-host of a great podcast we do at Gestalt IT, here’s a great way to jump in. This episode was a fun one to record and talk about licensing:

Sometimes I have to play the role of the genial host and I don’t get to express my true opinion on things. After all, a good podcast host is really just there to keep the peace and ensure the guests get to say their words, right?

Double Feature

I once said that every random feature in a certain network operating system somehow came from a million-dollar PO that needed to be closed. It reflects my personal opinion that sometimes the things we see in code don’t always reflect reality. But how do you decide what to build if you’re not listening to customers?

It’s a tough gamble to take. You can guess at what people are going to want to include and hope that you get it right. Other times you’re going to goof and put something your code that no one uses. It’s a delicate balance. One of the biggest traps that a company can fall into is waiting for their customers to tell them what they want to see in the next release. Steve Jobs is famous for having said the following:

Some people say, “Give the customers what they want.” But that’s not my approach. Our job is to figure out what they’re going to want before they do. I think Henry Ford once said, “If I’d asked customers what they wanted, they would have told me, ‘A faster horse!'” People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page.

Granted, it’s a bit different when you’re building a cutting edge consumer device. And if you look at the track record of Apple it’s not spotless. But when you’re trying to figure out what features need to be built into an operating system you should probably know what your customers want.

But no choice about including code or features comes without a cost. Even if you have engineers on staff writing code day and night you’re going to incur a work cost. Development is measure in hours and hours equate to dollars1. If you have a team of hundreds working on a single feature you’re going to rack up some pretty significant costs. And including that feature in the base operating system only makes sense if you’re trying to capture market share or address a huge issue your customers have.

But how can you track adoption? Number of downloads of the OS or the program? Not a great measure if it’s something everyone needs to install. If you were trying to track the number of Apple Mail users based on the number of people running iOS on a device you’d be pretty far off the mark. Just because it’s installed doesn’t mean it’s used. So how can we track that feature and recoup some of the development costs at the same time? That’s right! Licensing!

The Double-Edged Sword

Licensing, in and of itself, it’s evil. You have to agree to a license every time you use software. Even if you’re using something with a license that says you can do whatever you want with it. The inherent evil part of the license is when it’s applied in an unfair way.

A friend once told me that a networking vendor had a great idea on how to recoup the costs of developing their software-defined strategy. Instead of charging more to turn the feature on for the whole switch they wanted to charge per flow that used the feature. The rest of the room was speechless. How in the world can you charge for a feature in a switch by the flow? Even with bundling of the licenses you’d incur a significant amount of costs just to operate whatever that was. Amazingly enough the person that suggested it had come from a consumer productivity software background, which per-use licensing was the norm.

The idea is sound. Charge people for what they use. But the application failed. Could you imagine someone charging you per phone call? It’s happened before. Remember when calling cards were a thing? You could pay a few cents a minute to talk. Today? The idea of mobile phones and unlimited voice plans makes the idea of per-use phones antiquated at best.

Another great example of licensing backfiring is when Cisco decided they wanted to start charging a license fee for each different phone type they sold. After all, it should cost more to connect a video phone than it should to connect a regular desk phone, right? After spending years fighting against Device License Units (DLUs) and watching them get tossed to side in favor of modified user licensing because of the rise of software over voice, I realized that this is a game that really never ends. I was the proud owner of an old unlimited data plan from back in the day when the iPhone first came out and my provider wanted to charge you more for the voice minutes instead of the data. Today the data usage is much more valuable to them. Trends change. Devices change. And that means you have to keep your licensing fair and even.

Would you license a firewall per hundred flows? Per VPN connection? Maybe per concurrent MAC address? These are all things that have been done before. I have installed firewalls that could be “upgraded” to more capable units by removing an artificial limit on the number of concurrent users. It was wrong to me but the company made money. It was an easy “fix” to get a few hundred dollars more plus some recurring support revenue. But did it accurately reflect the way that the users operated the device? Not really. It was more about getting extra funding for some other feature or for keeping your business unit in business.

The dark side of licensing comes from greed. Ensuring proper feature adoption or tracking development costs is fine and dandy. But when you charge more just because you can it becomes wrong. Worse yet, when you charge a fortune to keep all but a select few from using your feature set it’s even worse. You can’t expect to feel good about yourself charging a million dollars to license a feature that you really expect only a couple of customers to use. But that’s happened before too. And we’re not even going to get into the argument from the podcast about licensing being tied to the myth of “shareholder value”. I’d need another 2,500 words for that one.

Tom’s Take

Licensing is a necessary evil. We have to have rules and guidelines to use things properly. We also have to have a way to tie development to use. Most modern software is going to charge you for some feature, whether it’s a model of paying once for every major update or a freemium model that lets you pay a regular fee for regular updates. I can’t predict that market any more than I can predict the end of unlimited data plans and DLUs. But I can say that if licensing stops being about keeping software use sane and keeps running down the path of keeping shareholders deliriously rich, you’re going to find out that licensing was the real villain all along.

  1. Or the currency of your region ↩︎