Why proprietary software is dangerous for business-critical applications

A friend of mine is the IT manager for a medium-sized wholesale distribution business. One afternoon in early August, a hard disk drive in one of his employer’s servers started to show signs that it was dying. That hard drive contained the company’s (proprietary) credit card processing software, which was chosen specifically to integrate with the company’s (proprietary) inventory control and accounting software package. My friend — we’ll call him Stan — didn’t think the problem was a big deal. He’d just reinstall the card-processing software on another hard drive, move the customer data he’d wisely backed up onto the new drive, and go home for the day. That was before he called the software company that had sold his employer the card-processing program — a call that left Stan and his boss angry and confused.What Stan wanted from the card-processing software publisher was simple: an “unlock” key for the new installation. It’s the kind of request software company customer service departments handle all day long. They check to make sure the caller has actually purchased the software in question, then email a new key or read it over the phone.

But this software company said, “No, we can’t give you a new registration for your old software. You need to upgrade to our latest version, and the upgrade will cost you [several thousand dollars].”

It turned out that the company that had sold the original software had been bought out by a larger software company that had substantially rewritten the program and didn’t want to support old versions at all, not even with emergency re-registrations for existing customers. Nope, they said, you must upgrade to our new version. That is your only choice. Take it or leave it.

While the financial blackmail aspect of this attitude angered Stan — and angered his boss even more — their biggest worry was that they might have trouble integrating the new software with the rest of their accounting and inventory control system. Note that for a company that makes most of its sales over the Internet or by phone, with credit cards as the most popular means of payment, any interruption in the ability to process those credit cards is costly, and if it goes on for long can easily become catastrophic. So the obvious, sensible, conservative path for Stan to take was to reinstall the software he already had, and that he knew worked correctly, then experiment very carefully with a new version.

Stan’s next move was to make a bit-for-bit copy of the dying hard drive in hopes that the new copy would run correctly. As those of you who have tried this move know all too well, sometimes this works and sometimes it doesn’t. And as you also know, if you’re dealing with many gigabytes of data, this can be an all-night job that requires all-night babysitting. It is something no sysadmin or IT manager looks forward to. But Stan did it, and, lo and behold! It worked.

The alternative short-term plan, if the bit-by-bit copy hadn’t worked, was to process credit cards manually, using a terminal like the ones you see in almost every restaurant or retail store.

The long-term plan obviously does not include a costly upgrade to the current card-processing software. And Stan, being a Linux user and open source advocate, used this situation to show his boss that open source is often not only better and less costly, but safer than proprietary software.

The question, though, is whether there’s an open source credit card processing program that will integrate properly with the company’s proprietary accounting and inventory control software. If not, Stan’s company might decide to help underwrite the creation of one that would do what they need. It’s also possible that they will carefully and slowly start looking for an open source accounting and inventory control package to replace their current proprietary one, although this would be a huge move for them; one that might take several years to make if, indeed, they make it at all.

But the real point here is that an entire medium-sized company’s executive staff has learned a hard lesson about the dangers of proprietary software, and members of that staff who previously resisted open source are now ready to consider it — and for business continuity reasons rather than as a money-saving measure, no less.