In the early days of shrink-wrapped PC software, I used to buy a software title and not expect to pay anything more for that software until I decided to upgrade it. I might upgrade when the publisher released a new title, or I might skip a release -- it was up to me to decide.
Pretty soon, though, software companies discovered that it was expensive to staff a help desk to support customers, and then they started to discover that it was painful to have customers working with software that was several versions out-of-date. The solution: software subscriptions and maintenance plans. Enterprise software companies had already been doing this for years; it lets the software company generate revenue from support areas, and smooths their revenue stream (so it's not clustered around new releases).
Although enterprise customers had been paying maintenance for years, consumers have been wary of subscriptions. They want to know what they're getting for their money, and they want to be able to decide when to upgrade.
In a recent blog entry (Software maintenance pricing - Fair or out of control?), Scott Lowe shows that this sentiment affects the enterprise customer, too. Especially in these times of constrained budgets, enterprises aren't too excited about big increases in software maintenance prices without a whole lot of additional perceived value.
If you're a software developer, you need to understand that you can't get away with milking your existing customers just because they decided to buy your software years ago. This should go without saying, but if you sell subscription-based support, make sure you provide upgrades that are worth the cost your customers are paying. In a recent Joel on Software thread, a developer sounded off against Lowe's article, but he completely missed Lowe's point: the prices of software maintenance are going up, but value isn't.
If you're a customer, you hope your vendors are committed to providing value for your support dollars, but this won't always be true. If you've ever felt locked into a vendor, you know this is no fun at all. When you're faced with a vendor who's got you over a barrel, you can feel like your organization is being held for ransom, and you're powerless to extract yourself.
As a manager or an architect, part of your job is to manage vendor risk. I've got some thoughts on this, and I'll share them in another post.
Let me know what you're thinking - what are you doing to manage vendor lock-in in your organization?
Related articles by Zemanta
- When You Treat Your Customers Like Criminals, Don't Be Surprised When They Go To Different Suppliers (techdirt.com)
- Penny wise, pound foolish (meganmcardle.theatlantic.com)
- Another Take on Enterprise Open Source (cazh1.com)