Perpetual licenses
As a buyer, I kind of like the good old perpetual license. It's nice to know that you pay one price, and you will never have to pay it again. In fact, if the product meets your needs as-is, this is a great deal. The problem is that it puts the vendor in a bind. If the vendor's product is great, it will quickly meet the market demand, and then what? Companies larger than a very small shop can't just sell a couple million copies of a useful app, bring in a bunch of cash, and then retire -- those companies need ongoing revenue. But if the product is sold with a perpetual license and works great, then there is no ongoing revenue. You make a bunch of money once you get traction in the market, and that's it, you are done. So what happens next? Bloat. If version 1 sold a million copies, then maybe adding features will get another 100,000 sales plus a half million upgrades. Rinse and repeat and, the next thing you know, that svelte little utility that everyone loved is now a small part of a monolithic suite of tools that is universally despised. Remember that guy with the glasses, rolled up sleeves, and the crossed arms and what happened to his products?
Maintenance contracts
Once companies realize how difficult it is to keep a business afloat by only selling perpetual licenses, the next logical conclusion they will come to is that they need to sell maintenance contracts. Someone figures out that if it takes three years to get the next version out the door, a great way to fund that development is to charge existing customers 15% or 25% of what they paid for their license on a yearly basis for "support." This sounds great until you look at it from the customer's view. Software doesn't degrade and break over time as a general rule (operating systems are an exception, as they get endlessly patched and accumulate junk from misbehaving apps over the years). Once the initial installation and configuration is performed, in theory, a customer should almost never need the vendor's help again. So why would customers a support contract? Here are three possible justifications:
The worst part about maintenance contracts is that they actually encourage the vendor to make your life miserable. After all, if you felt like the product was stable or easy to use and own, there is a good chance that you would feel safe not buying the contract. But if the vendor is constantly pushing out patches for critical bugs, or your users are spending five hours a month on the phone with the vendor, that maintenance contract feels like a necessary (albeit very expensive) evil. So from the vendor's view, the best way to encourage the purchase of a support contract is to make you feel like you need it, by providing a "good enough" product that truly requires support. Support contracts are not always a rip-off. For example, I like support contracts when the vendor does a constant trickle of new features, a rolling upgrade as it were, and the support contract is more like a blend of paying "as a service" to constantly have the best version available, but having a perpetual license. Some companies work like this, and I respect it. Other support contracts are reasonably priced, and while the support is not needed, it is well worth having it available when it is. Some companies offer a per-incident support contract. A note to companies that sell maintenance contracts: One surefire way to make a customer furious is to ask for his credit card number at the beginning of the support call while they have a critical problem.
Open source support
Open source is the solution to these problems, according to some folks. There is a lot to like about the open source model. If people can get the software for free and without a vendor, it is logical to assume that this will leave some money in their pocket to pay a vendor for a formal support package if they do not feel comfortable getting their support from the open source community. The reality is not quite as rosy as some folks make it seem. The open source community is not doing the development for a great many projects, but the vendors doing the support are. In most of the big projects, once a vendor or two gets into the support side of things, anyone who contributes in a meaningful manner is hired by a vendor; when this happens, the open source community experiences a brain drain. When a vendor has the top contributors working on the project full-time, the vendor is now in a curious position: While the project is formally open source, the vendor controls much of, if not most of, the development. For all intents and purposes, the business model of these open source vendors is not substantially different from that of their closed source brethren, albeit one where the upfront license cost to the end user is nothing. When you consider that many open source support vendors make a premium version of the package that can be purchased, these companies look an awful lot like the closed source vendors who have free versions of their products. These open source support vendors have management teams, marketing departments, advertising budgets, facilities, hardware costs, and so on -- their costs about equal to what the closed source folks have. These vendors are paying for a substantial part of the development costs, if not the lion's share of the development costs. At best, the development costs are the only place they can shave some costs, and that's only if folks keep working for free once some vendor money is in the game, or if other vendors also hire developers to chip in. If there are gaps in the development model that the open source community or other vendors are not providing (e.g., for the "boring" stuff such as graphics, testing, hosting version control, documentation, etc.), they get to pick up the tab for that too. After all, who is going to pay support for a product that is not as complete as the closed source competition? On top of all of that, they need to maintain a support infrastructure, which is where the revenue actually comes from. Is it any wonder that the cost of their support contracts start to look an awful lot like the total cost of a closed source license plus support contract? Of course not. They have the same costs, so they need to generate the same revenues. The much vaunted open source support model is really not much different in practice than closed source. And once an open source support company gets bought out by one of those enterprise class vendors, have fun being treated like an enterprise class customer.
XYZ as a service
The "... as a Service" moniker is new, but the idea is not; falling networking costs and rising speeds in conjunction with the evolution of the Web as an application platform have made it a much more plausible business model now than it was a few years ago. This is a great business model for applications that you use on a regular basis. The ongoing costs to the customer are justified because the customer does not have to support the application, maintain a hardware environment, deal with installations and upgrades and such, wrangle with backups, and more. While the per user, per month cost is usually much higher than purchasing the applications and a support license, it typically washes out once you factor in the other, less direct costs. If you ignore the technical and business concerns around this model, it is very attractive to the customer and the vendor. While the vendor does support the customer, the support costs are dramatically lower because all they need to support is using the application, not owning it. The customer is not paying for upgrades or support (although that is part of the package), they are paying for the vendor to maintain and run the application, which seems fair to the customer. However, not every application is well suited for this model. Some applications have technical limitations that make them better suited for on-premise servers or desktop usage; other applications get used too infrequently for a monthly bill to make sense (perhaps vendors should look into per-usage pricing models?). Some organizations are so large that they have the same economics of scale that a vendor has, so the service model really ends up costing more since the vendor also has to make a profit, while the internal IT department does not. The biggest problem with the service model is that the much feared vendor lock in is even worse than with traditional application models because your data is not local. The vendor can hold your data hostage if they want. I think that most vendors are upstanding companies that do not wish to mistreat their customers, but I have been in third-party relationships where it was clear that the vendor knew they would lose a lot of business if they made it easy to leave.
Ad supported
A while back, it looked like with enough ads, anything could be free to the end user. Few applications have the user density to get enough ad revenue to support real development work. On top of that, the best way to be able to charge more for ads is to have them be the kinds of ads that many customers hate: giant, obnoxious ads, or the kind that use your private information to target you. For the most part, it seems like ad supported software model is best suited for the consumer space, while businesses usually avoid it. I can think of one or two counter-examples (one of my favorite companies makes a great ad supported business application that customers love), but for now, it does not look like a realistic model for most business applications.
Conclusions
I am not saying that every software vendor is sleazy -- far from it. The problem is that the current software models lend themselves all too well to sleazy behavior, and some really encourage it; there are far too many vendors are behaving this way. In my experience, the larger the vendor, the more likely they are to abuse their customers. Why? Because they have a larger structure to support, and a higher ratio of parasitic costs to revenue generating costs. If you look at a smaller company, the lead developer or the project manager might also be the owner, and the sales lead and the marketing team are the same person, and so on. But a bigger company has a huge overhead that does not contribute to the bottom line, things like accountants, legal departments, and HR departments. Large companies need to make more money just to feed the beast, and many of them also have a stock price or dividends to worry about too, as well as the need to build cash reserves for M/A actions. This does not mean that small software companies are perfect or never take advantage of their customers; it just means that bigger companies have a lot more urgency to wring every last dime out of their customers. That said, many projects (think databases, operating systems, etc.) are too big to write with a small, lean company, let alone support. Something needs to give and soon. Customers are increasingly angry. The open source movement has proven to be much more evolutionary than revolutionary. Too many applications have been paid for and upgraded faithfully year after year, generating billions of dollars for their vendors, while delivering no features anyone needs and just becoming more and more bloated. Customers spend too much money on IT to not see a lot value in their investments. Software vendors need to find a way to make money while treating customers fairly and like partners, rather than like victims to be bled dry. Most software vendors are doing a great job of providing value at a fair price, but those vendors aren't poisoning the industry. The vendors that are poisoning the industry are costing customers too much money and trust, and the rest of us are being affected by their actions. Many of the problems in the software industry, particularly bloated, buggy, and insecure software, are a direct result of the business models that foster stagnancy and inertia rather than innovation and value. J.Ja
posted by Justin James
September 3, 2010 @ 10:49 am
Infrastructure-Application-ManagedServices.Visit www.dayaciptamandiri.com for details..