In response to my recent column about Forgent's belated JPEG patent claim, ZDNet reader Steve Fischer wondered, with some sarcasm, how I could be so critical of Forgent, while I let Microsoft off the hook for what he considered to be an equally extortionist act: a new licensing plan.
So, what I'm about to say may not sit well with most of you: More power to Microsoft. In fact, more power to any company that manages to hook its customers on proprietary features.
Admittedly, when you took the road more traveled and ended up beholden to Microsoft, there wasn't--for the most part--an alternate route--at least not one that offered the true advantages of standards. (Linux could change things).
Let this be a lesson: The minute you get you or your company hooked on a proprietary technology, you put the vendor of that technology in control of a lot of things that I'm certain you'd prefer to control. Need proof? Look no further than Microsoft's July 31 licensing deadline. Even though a lot of people have threatened to move to something like Sun's StarOffice (which claims to be based on a non-proprietary XML file format), I wonder how many companies are really prepared to stomach the pains of withdrawal. In the end, a lot of companies will end up paying Microsoft; proof that until those companies really commit to a change, it's Microsoft that's in charge of a sizeable portion of their IT costs. News flash: Putting the vendor in control of your IT costs is not a good position to be in. Unfortunately, that's where a lot of us are.
Cost isn't the only thing a vendor controls once you've become addicted to its proprietary technology. As Microsoft has taught us, security is another aspect of our IT that a vendor can come to control. Despite the untold dollars and hours spent resolving problems arising from vulnerabilities in Microsoft software like Outlook and Internet Explorer, few if any companies decided that the situation was intolerable, bit the bullet, and switched to something else. Instead, they put up with it, entrusting their security to the specialists at Microsoft whose job it is to release the patches and fixes before any damage from a newly discovered vulnerability gets done. While you play a role in applying those fixes and patches, Microsoft is ultimately in charge of how secure your e-mail system is.
And then there's product stability
Another thing that the vendor controls when you become addicted to a
proprietary technology (and this one drives ZDNet's readers crazy) is
product stability. It's so bad, write some readers, that they get into fights
with vendors who charge for support calls when the problem is actually a
design flaw or a bug in the software. But, if your company is hooked on
some non-standard features in a product, what choice do you have but to
put up with the bugs that surface elsewhere in that same product? You have
no choice. The vendor is in charge.
Performance and scalability are other aspects of your IT that a vendor can control. You say that your e-mail server isn't fast enough, or that it slows to a crawl when you scale it above a certain number of users? Too bad. Run a second server and split your workload if you don't like it.
That's what happens when you decide to accept and deploy proprietary technology. You relinquish control of your IT to the vendors of that technology.
How do you break the chain?
Reduce your dependency on proprietary solutions. Go to a technology rehab center where you can get counseling on the long-term consequences of shortcutting standards. The IT manager you won't find at such a rehab center is the person who picked IMAP4 as the company e-mail standard, and who resisted the temptation to adopt any one vendor's proprietary extensions to it. The result? Decisions about e-mail clients remain independent of decisions about e-mail servers. If that manager becomes dissatisfied with either the client or server, the pain of switching is greatly minimized because there are numerous alternatives.
In other words, he's in control.
To be sure, regaining that sort of control requires sacrifices. Very often, the reason you got hooked on something proprietary in the first place was because no standard existed for that type of application when the vendor first offered it to you. But now that you understand the long-term consequences of establishing these dependencies--as evidenced by the change in Microsoft's licensing and what little control you have over it--you should also learn to approach the newer, standardless technologies with a more critical eye. At the very least, you should approach them with the idea that you might some day want to replace them, rather than rely on them. That way, you may be able to get the timely benefits of innovation without the long-term consequences of addiction.