IT Employment

Why software sales models hurt customers and vendors

According to Justin James, many of the problems in the software industry, particularly bloated, buggy, and insecure software, are a direct result of the business models.

At the TechRepublic event in early July 2010, there were a lot of great discussions, and one of the un-conference sessions that tied everything together was "How do we fix the software industry and stop ripping off our customers?"

There are companies that are universally despised by their customers, yet they continue to enjoy revenues in the billions by abusing their customer bases. We have entire software classes that cost customers millions to purchase and millions more to install and integrate, but they are so useless and difficult to use that only about one third of the sold seats are actually used. There are a number of companies charging so much to support different open source packages that they are actually more expensive than their proprietary competition. We all know who these companies are.

There are a number of ways to make money writing software; unfortunately, many of those ways have what economists call perverse incentives and, as a result, some companies are driven to exploit their customers because of their business models. Does this mean that everyone involved in the software industry is a dirt bag? Of course not. But when you look at the details, the software industry is in deep trouble.

Let's take a look at the common software sales models and examine how these models can hurt our customers and our IT departments.

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 selling only 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 buy a support contract? Here are three possible justifications:

  • Some applications are insanely complex and difficult to use, so you always want someone you can ask for help. From a customer's perspective, I would be wondering why a $50,000 application will require help desk support on a regular basis. Is it because the product is bad, the documentation is bad, or both?
  • Some applications are insanely complex, and the vendor regularly needs to issue patches for them, and without the maintenance contract, you don't get the patches. This doesn't sound like a great reason either, does it? The customer has to pay the company for a support contract to fix any manufacturing defects when it costs the company a few cents (if not less) to allow the customer to download the patch?
  • You need a support contract so, when we release a new version, you get it for free or at a discount. This sounds reasonable until the customer finds out that the new version is really just a collection of fixes for problems in the version that was already paid for (yet the company refuses to patch) and some features that the customer didn't request (resulting in feature bloat). Half of the features add functionality that was supposed to be in the customer's current version. This doesn't sound like such a great deal anymore.

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 if 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 when 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 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 counterexamples (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 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 might be 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 of 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

About

Justin James is the Lead Architect for Conigent.

41 comments
jayohem
jayohem

It sounds that with these behemoth software monopolies we might be looking at a 21st century Beauvais Cathedral. That's the French Gothic cathedral that never got finished because it was too big and could not have supported its own weight had building continued. Maybe they should start to divest themselves of acquisitions that are building in useless bloat (and costing us (US) jobs. More smaller companies (large vs. huge) mean more jobs. No elite group of executives in any business needs too much money. This country does need working people and working products.

gscratchley
gscratchley

ok, I'm a software vendor. we like to think that we have a business model that our customers accept. you get a password to use the software on an annual basis, assuming your maintenance is paid. for that payment, you get right to use new version (ie, version upgrades do not require an additional license) and telephone support and patches as they are released. What would you suggest?

CharlieSpencer
CharlieSpencer

"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;" You've raised one of my long-standing questions about the open source model: when you can get paid for doing something, why do it for free?

jmarkovic32
jmarkovic32

This is the main reason businesses "hate" their IT departments. It's because we spend every four years or so justifying these ridiculous expenses (albeit half-heartedly). It's upgrade time where I am now and I feel like a damn snake-oil salesman.

fgranier
fgranier

Open source engineering and all that is related to literature, music, art and any other activity related to the human ability to innovate or solve some kind of problem, including education and of course medice, psycotherapy, yes specialy the last one.

apotheon
apotheon

There are a number of business models that work perfectly well with open source software. In fact, the Software as a Service model -- one of the models mentioned in the article -- works perfectly well with open source software. Another model that has been shown to work pretty well is the open source developer who maintains a particular piece of software taking "bounties" to provide plugins, additional features, and other enhancements to the software. Then, of course. There's also a mixed licensing model that has been gradually emerging over a period of a decade or so, where a copyleft licensed application is also offered by the copyright holder under a commercial license to people who don't want to have to abide by the copyleft license terms when they combine it with their own code and redistribute it. This license has been known to be lucrative, even if it ultimately ends up screwing customers by proxy (when the companies buying commercial licenses screw their customers). Ultimately, though, I think that "the solution" -- which will actually be a myriad of solutions, each suiting a different need -- to the problem of business models that screw someone involved in the business transaction will have to involve open source software, or in some cases be business models for which it doesn't really matter whether it's open source software or not (ultimately a vanishingly small segment, I believe). That's not to say that open source software is the magical answer to all things. Rather, it's to say that, like software development that uses systematic regression testing and version control, open source development will ultimately become one of those things that any sane development team does, because trying to keep everything secret ends up giving you a competitive disadvantage.

AnsuGisalas
AnsuGisalas

The "If you like this software, you can donate to ensure it's continued availability and development" -model ;)

rackerman
rackerman

So what's the answer? Perhaps Ray Wang can shed some light...

Tony Hopkinson
Tony Hopkinson

You mustr be thinking long term, they don't, which is why we see this sort of crap. The thing is, if you did it right, could you compete with the it'll do, good enough, we'll fix it next version boys...

jkameleon
jkameleon

It's been like this for a long time, ever since the dotcom boom, when software development lost its innocence, so to speak. This is the time when bloatware appeared. The 1st and worst piece of bloatware I got my hands on was Borland's TCC. It was even worse than Microsoft's VB6, if you can imagine such a thing. Far worse. It behaved completely unpredictably. Sometimes the code compiled, at the other times it reported some insane error. Because of buggy hash table class, library crashed randomly. Borland was by far the worst in those days, and Microsoft wasn't much better either. I don't expect it'll get any better soon. Market rewarded sleazy vendors for far too long, and it still pretty much does.

mcswan454
mcswan454

Excellent article. But having read it, why am I not surprised at the way software HAS evolved, or the sales models attached. Now, if you can convince the vendors to consider your analysis, we might have a fighting chance. Me? I'm going to be patient, and see how this shakes out. I can always hit from the flank when least expected. M.

AnsuGisalas
AnsuGisalas

a functioning distributed innovation base/undergrowth would create synergistic economic growth and technological progress all over the damn place (i.e. Sol III, aka Terra, aka Earth).

gscratchley
gscratchley

at another employer of mine: you pay for the software once, you get a password that never expires. However, UNLESS you pay annual maintenance, you get no support, no right to new version, etc. wrt a couple of replies: It's not obvious to me not sure why it would make a difference if the company was public or private - isn't is just the difference of who you have to report to (whether your revenue and margin had increase)?

AnsuGisalas
AnsuGisalas

The idea of renting software isn't very nice, but then, it's something people can probably accept, if price and service levels are ok. From the premise that all these sales models are flawed, this one is probably in the "lesser evils" group, as it provides some non-perverse incentives, and a revenue flow for future developments at the same time. It does force the software dev team to commit to neverending improvement, something that's not entirely sane. Keeping it compatible isn't the same as making it ever improving, and the price tags on those should be different. It does make for some level of feature bloat pressure.

apotheon
apotheon

Instead of the developer doing it for free, the corporation that hired him is now doing it for free -- by donating developer time to the development of the open source software. This is actually common not just among corporations that serve customers through the use or distribution of open source software, but also among corporations that use the software a lot on the back end. It's kind of a shell game: Who is donating time to the project -- the developer or the corporation that employs the developer? In most of those cases, the developers whose on-the-clock time is being donated to the project would work on the open source project for free anyway (though they likely couldn't afford to spend as much time on it if they weren't being paid to do so), because they like and use the project and have a lot of pride in the quality of the software as long-time contributors. Even when being paid to work on the project, they often put in more time on it than they're paid to put into it, because they believe in the importance of the project enough to donate their own time as well as the on-the-clock time in their work for the company supporting the project. There are other reasons for working on an open source project for free, too. Many of them have less longevity of motivation than the above, but not all. For instance, nontrivial involvement in a major open source project makes for a great bullet point on the resume, for many developers seeking programming work. Some actually make money off their expertise in the software, working as consultants who have great personal knowledge of a popular open source software system and can help clients make the most of it. Others want to contribute to the development of a piece of software they use and love, to ensure that it continues to be software they use and love -- much the same motivation as corporations that might later pay them to keep working on the project. Still others simply believe that the project itself is of great importance, because of its security benefits, the fact it is an effective replacement for something sold by a corporation whose policies they despise, and so on. Don't forget possibly the strongest motivator of all in any group-oriented work: the impetus of membership in a community. There are probably almost as many reasons to contribute development work to an open source project as there are people who contribute development work to open source projects (and there are a great many of us). In fact, there may be more reasons than there are people who need such reasons. I know that my reasons for contributing to a number of open source projects are different for each one of those projects.

Jaqui
Jaqui

one of the FS/OSS models. :D and the one that doesn't truly get any income to pay for continued development. :\ The majority of FS/OSS uses it, and are hurting for the cash needed to pay for server space, never mind having some to pay for the leaders time and effort.

fjessani
fjessani

I don't think there is or can be a universal answer. Each of those techniques does work depending on the situation. I think the author's main point is that each of those can be exploited.

apotheon
apotheon

It's been like this for a long time, ever since the dotcom boom, when software development lost its innocence, so to speak. It has been going on much longer than that. That's just when the industry got big enough for most people to notice.

michaellashinsky
michaellashinsky

Rip off #1: Client Access Licenses. I buy a server OS. I buy 25 Workstation OS. I then have to buy 25 CALs to allow my workstations to talk to my servers. What is the point of a server if the clients cannot communicate with it? I own the server and the workstaitons, I won the server OS and the workstation OS, I own the wires in between, why should I have to pay more to use my own stuff? It is like buying a car, and still having to pay by the mile, or by the passenger! Rip-off #2: Having to buy seats to an appliance or software version of an appliance. If I buy a firewall or email filter, I have to buy the device or software, then pay per user that will use it. I already bought the product for my office. What difference does it make how many people are in my office? It is the same appliance or software package running on my network regardless whether I have 10, 20, or 250 people in my employ. It is not installed on every PC, that would be different. It is still only one unit on the whole network. How is this even legal?

apotheon
apotheon

The question of who's in charge has a huge impact on how the business is run -- because different people running a business have different goals. When you're dealing with a public corporation, you're dealing with "owners" that consist of a bunch of people who just want to make a buck, and don't actually care about the business itself. Many of them don't even plan to keep the stock for long; they just want to make a quick buck by any means possible, even if it means the ultimate ruin of the company, and run with the money the moment they think they've gotten all it's worth their while to get. Meanwhile, a sole proprietorship (for the opposite end of the spectrum) is its owner's baby, and he or she is in it for the long haul -- unless the owner is just trying to build up its value for sale to a major corporation, in which case the goals for the company in the short and long terms will be significantly different from either a public corporation or a sole proprietorship that isn't for sale. Another extreme is a company that is "owned" solely by its employees. Their motivations are colored not only by their desire to make money, but also by job security, and by their working conditions and pensions. These things take precedence over customer satisfaction where there is a conflict, for instance -- and individual desires related to working conditions and salaries can also potentially conflict with the hard decisions that might need to be made to ensure the long-term viability of the company itself. What about those businesses that are "owned" by their customers? These tend to be certain types of credit unions and similar membership-based business models. In such circumstances, everything is based on customer satisfaction -- though by way of an aggregate decision making, rather than a centralized attempt to satisfy the right people at the right times. You ask "It's not obvious to me not sure why it would make a difference if the company was public or private - isn't is just the difference of who you have to report to (whether your revenue and margin had increase)?" The answer is . . . well, yeah, sorta, but that's a big damned difference, and can affect everything else in nontrivial ways.

apotheon
apotheon

How does the rental model commit the software team to neverending improvement? All it needs to do is avoid letting something else get better to the extent that it will damage the viability of the rental model. That "something else" might have more and more features piled on because it's using a different business model, intended to keep people buying new versions, but that doesn't actually make it better. In fact, it probably makes it worse. As long as the company doesn't become a publicly traded corporation, it can be "successful enough". It is only when a corporation is publicly traded that it needs to strive for the impossibility of perpetual market share growth. If maintaining an acceptable level of success is your goal, rather than an insane, perpetual growth cycle, all you need to do is keep the software good, rather than trying to find ways to "improve" it. As such, there's not necessarily any feature bloat pressure. The major problems with a sustainable maintenance development model and a rental-based business model are two-fold, as far as I see: 1. Public corporations that need perpetual market share growth will do everything in their power to acquire or destroy you. As long as publicly traded corporations (in the current meaning of that term) exist, this will continue to be a problem. 2. The rental model requires a development model where the core of the software is closed source. This means you're stuck with a suboptimal development model, because the benefits of an open source development model can never be had for the core software offering; security, reliability, and outside contribution will suffer to varying degrees.

carlsf
carlsf

I dont mind paying for a application/operating System, as long as it meets my requirements, and is reasonably priced. Let cut to the chase Microsoft...... I object to being forced due to their phasing out/ending of products. Then forcing users/clients to upgrade to a product where we have to change, relearn, retrain and in the meantime who pays for the loss of income/productivity, I do. Dont get me wrong I pay a monthly subscription for my acounting application this provides me with help on demand (NO additional cost) and every 18/24months I recieve a updated (next re lease)again NO charge. I will stop paying for this service WHEN/IF the next release starts costing me additional money (retraining/loss of productivity). In the MS case I pay, then pay even more, to be able to use the application/Operating System. AND I have drawn the line with Microsoft NO more, WIN7, the cost of the product then retraining/loss of productivity, "CLASSIC" option, and the same goes for their Office 2007/10 and the "RIBBON.

CharlieSpencer
CharlieSpencer

"...the one that doesn't truly get any income to pay for continued development." Until some company buys the product and hires the developer.

MikeGall
MikeGall

And then a big corp decides that the software is the next big thing and sponsors development and you end up with 90 corp X employees (some of whom used to be the project lead developers) and a miniscule working on it for free crowd. Also the corp demands to have the final say in releases which means features get added that they think they can sell support contracts for, features only get added to the "for profit" branch of the project etc. Finally the last problem with the model: a lot of crappy software. The program is okay and does the job, but looks like an ugly relic from 1994, behaves the same way and shows "no pride of ownership" in its design. Sorry guys but I'll use it until I find something better but I won't pay for it. How can I? I'd have to convince my boss that we need to spend the money, but it is a hard sell because the product is free and crappy. There is no evidence that the developer has the knowledge and resources to make it look better or clean up the design.

maj37
maj37

Actually it has been going on even longer than that. You folks sound like you think the software industry started in around 1990, it has been around much much longer than that. It predates the original IBM PC in 1981 by decades and these problems have always existed. maj

apotheon
apotheon

What about a per-core license? It's the same piece of software. You're just running it on a newer machine with more cores in the CPU, and/or more CPUs. Why should that cost more? When you get right down to it, there's the rip-off of even having to get installation licenses. Why do I need a separate license for each install? I bought your damned CD. Let me use it.

AnsuGisalas
AnsuGisalas

I made the mistake of figuring that greasing one's wheels was a given, and one that remains relatively constant... but maybe it isn't. Obviously, the proprietor is likely to hold back on their own pay until the future cash flow feels secured - but in a way that's "financing" too, just loaning off oneself - I tend to make lots of conflations like that. Maintaining the work force is something I hadn't considered in depth. I'm also not sure how much work goes into "keeping it good"... depends on technological developments a lot I guess. There's lots of things to consider, and if it was easy, someone would have fixed it already :)

apotheon
apotheon

When this burden of debt diminishes (hopefully) then the part of the pie that goes to further development increases. As in any other career field, in software development, employees come and go. This is not necessarily a bad thing. If you can replace outgoing developers with incoming developers that are as good or better, you win. What do you do with that extra money? Do you spend it all on making your stable of developers do much the same kind of work, while replacing those who leave with people equivalent to them when they first started so that you have still more money to spend on development that sucks? Maybe you should spend that extra money on replacing outgoing developers with even better developers, or on convincing some of those outgoing developers who are really good at what they do (and worth the money) to stay. There's also the question of whether that bigger piece of the pie has to go to development. Some of it can go to retirement funds. Some of it can be pure profit for a sole proprietorship or contractual partnership, or the owners of a non-public corporation. Some of it can go in the bank, saved up for a rainy day (such as when some ass-burglar publicly traded corporation comes knocking on your door with a spurious patent infringement claim). A smart business owner and/or president can always come up with better uses of money than just giving developers busy-work that ends up degrading the quality of the software. . . . and as you say, you can give your customers a share of the profits by cutting the cost if you want to reward them and keep them around.

AnsuGisalas
AnsuGisalas

When the first version hit the streets, the "rent" pays for it's financing, and for future development. When this burden of debt diminishes (hopefully) then the part of the pie that goes to further development increases. What then, when the software reaches a "good" level, with it's core purpose well covered, and no annoying frills. Will "keeping it good" cost the same as "making it good" did? If it's not, and if there aren't costs to justify the up-until-now rent, what to do about the price? Do you lower it? Or do you lower it for repeat customers to be fair to the ones that helped pay the financing? That's what I meant, if price stays the same, doesn't it mean that developers are committed (in the eyes of the renters at least) to keeping the improvement vector constant?

michaellashinsky
michaellashinsky

I can name 3 ways M$ forces you to upgrade, and that is off the top of my head. M$ forces many to update by ending support for current versions. Have you tried to download a Win'98 driver for a common older HP printer in the last few years? HP doesn't provide them anymore, because M$ won't let them. They are in the list, but when you click on the link, you get an apology saying essentially that M$ won't let them offer the Win'98 drivers anymore. That is one way to force you to upgrade. Another way is not allowing OEMs and builders to sell a particular OS on a new computer if they do not want them to. When Vista first hit the shelves, you could no longer purchase a new computer with XP for love or money. M$ had to back off of that because of the public outcry over how crappy Vista was, but they have done it before and will do it again. Even another way M$ forces you to upgrade your OS is through the use of OEM licenses being tied to your current CPU. Even though my last computer came with XP disks and a license, I am prohibited from reusing that license on a new CPU, even if my old one blew up. So, because M$ will not sell me a new license for XP, I have to either upgrade or switch to a different platform.

carlsf
carlsf

Accounting continues for the version Im on as long as I pay the monthly subscription. If I dont upgrade I still get support for nn version even though it is not the latest. With MS they dont.

Tony Hopkinson
Tony Hopkinson

As distasteful as the idea might be, if it weren't for the ability to sell the next big thing, we wouldn't be here having this chat in front of an audience of millions. If we were both keen on computing and knew a heck of a lot about them, we and the other guy might have passed some green text about over a 4800 modem on a BBS.... No point in complaining about water being wet.....

CharlieSpencer
CharlieSpencer

"...forcing users/clients to upgrade to a product where we have to change, relearn, retrain..." I've heard this complaint multiple times, but I still don't understand it. How is Microsoft forcing you to update? How is sticking with XP (or 2K or 98) any different from dropping the maint. contract on your accounting app and sticking with the last supported version?

AnsuGisalas
AnsuGisalas

to the land of perverse incentive :p Hey... someone should sell indulgences for those!

apotheon
apotheon

For those of us trying to get work done, usability matters more than a "modern" interface -- but if you have time to kill when you're done making the software secure, stable, and well-organized, it's definitely worth a little time to make it pretty as well. I meant the whole design of the interface, where buttons are and how logically grouped controls are. Give me examples how following this philosophy necessarily makes the application look "new". I don't think that connection between a "new" look and a well-organized application actually exists. One can design an extremely well organized interface in Tk just as easily as in the most recent versions of Cocoa and WxWidgets, and the Tk interface will still look like it came from 1996. Actually, you can design a well organized interface more easily in Tk, in many cases. Shinny and well designed interfaces aren't everything but they are what I and the users will see and interact with so they matter hugely. A shiny, fabulous, "new" looking interface will certainly draw more customers at first. The superficial is great for marketing. It does not, however, mean the application is any good. This is why KDE and GNOME are still more popular than many alternatives that actually work better, and provide better productivity enhancement for their users. Enlightenment does the fancy stuff just as well, but it doesn't throw it all in the user's face right away -- so GNOME and KDE attract more users, but Enlightenment is in many ways a far better desktop environment. Even better, for purposes of actually getting things done, is what I use -- AHWM. Of course, AHWM is terrible at all that flashy frippery that most people love. It doesn't look new and fancy, but it doesn't look old and clunky either; it doesn't look like anything at all, for the most part, because all it does is manage windows. The applications themselves are the only things with any appearance to speak of. These free apps are not always open source and even if they are I don't have time to go through source code for every single app I consider + it would be is stupid to assume that I could as the program could be coded in any programming language using tonnes of different libraries which i might have never heard of, etc. Uhhh . . . what? Is there some point you're trying to make with this comment that you don't have time to read all the source code of every application you use? I don't have that time, either, even though I probably use a lot of applications with far less source code in them than the equivalents you use. So what?

MikeGall
MikeGall

but aesthetics matter. It wasn't just how shiny the interface is that I meant though, I meant the whole design of the interface, where buttons are and how logically grouped controls are. Is the feature exposed where a user would logically look for it? Does the design encourage and support an efficient workflow? Etc. Shinny and well designed interfaces aren't everything but they are what I and the users will see and interact with so they matter hugely. These free apps are not always open source and even if they are I don't have time to go through source code for every single app I consider + it would be is stupid to assume that I could as the program could be coded in any programming language using tonnes of different libraries which i might have never heard of, etc. "In some cases, the developer is too busy making it good, useful, reliable, secure software to waste time on perfecting the appearance of the bevel effect on a button." True there are a lot of good developers out there in free or open source software and good for them. Some pay if you want software is actually good enough that you'd pay for it if you had to, but a lot of it isn't IMHO because they solve very small and/or relatively unimportant problems, or are just hacked together cludges to use.

apotheon
apotheon

Finally the last problem with the model: a lot of crappy software. The program is okay and does the job, but looks like an ugly relic from 1994, behaves the same way and shows "no pride of ownership" in its design. Translation: "I regard the superficial qualities of a piece of software as the final measure of its quality, and have only looked at a very, very small, cherry-picked segment of the total available open source software options in the world to form what I laughingly call my 'opinion'." the knowledge and resources to make it look better In some cases, the developer is too busy making it good, useful, reliable, secure software to waste time on perfecting the appearance of the bevel effect on a button.

apotheon
apotheon

I suppose it could have been meant as agreement with, and amplification of, the sentiment. If so, I think it might have been posted in the wrong place (as a response to me rather than to the preceding comment), and the pluralizing reference to the targets of the comments made it seem like it targeted more than just the single comment to which I responded -- but I guess that could just be a misunderstanding. Thanks for bringing a little clarity to the situation. The more things change, the more they stay the same. My observation after over thirty years in the industry is that, with the exception of the Internet, little has changed in IT. Luckily, the Internet was a huge change that has enriched our lives substantially -- enough to more than make up for the hassles that come with it.

bspallino
bspallino

I think he was just trying to amplify your statement, not contradict it - at least, that's how I took it. And yes, its been going on since there's been OTS (Off The Shelf) software. I remember the concept being debated as a major breakthrough in companies I worked for in the late 70's. The platform was different (IBM 360/370), but the issues regarding business model were identical. At that time, there was heavy debate regarding "roll your own" vs OTS. The concerns were the same in 1978 as they are today, whether it be system utilities or business application. Example: we used a series of systems utilities from a company called UCC - back & Restore, check-point restart, tape library management - that sort of thing. UCC was gobbled up of Computer Associates in the early 80's - what a major disappointment. Applications were similar. I made a great living in the 80's support the M&D finance/accounting apps. People bought the app's thinking, "Hey, now we can fire all those Prima donna programmers," only to find that you needed a team of them to maintain and upgrade them, with the attendant 10's of thousands of "patch/fixes." The more things change, the more they stay the same. My observation after over thirty years in the industry is that, with the exception of the Internet, little has changed in IT.

apotheon
apotheon

Actually it has been going on even longer than that. You folks sound like you think the software industry started in around 1990, it has been around much much longer than that. I don't remember setting a specific time. You write as though I said software bloat has been around since 1990. What I had in the back of my mind was much longer ago than that, too -- but I did not mention any specific time period. Are you just assuming that no matter what I was thinking, it must not have been early enough?

Editor's Picks