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?
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.
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.
- Or the currency of your region ↩︎