Visit Our Home Page
 Explored, Designed,

Creativyst Docs 
Breaking the Proprietary Habit 



Managing IT:

Reducing Dependence on Proprietary Systems

Reduce your shop's Microsoft dependency without changing your religion

Q. When is the best time to ensure your legacy systems wont lock you into a proprietary treadmill?

A. When you are making the decision to purchase them.


Many IT shops have come to rely heavily on technology by a single provider. Lately, some of these shops are finding that the costs of such arrangements are beginning to outweigh their advantages. For these shops, this article promotes a slow and steady approach to a less dependent future. This paper shows that avoiding dependence on proprietary systems is not difficult. It explores steps the dependent shop can begin taking right away toward a future that is free from over-reliance on a single proprietary source.

We preach non-violence here. This article does not explore or recommend ways to rid yourself of Microsoft. It does explore strategies, and recommends tactical considerations which will reduce an over-dependence on any single platform, while (hopefully) providing an immediate and measurable return on the effort.

Continuous IndependenceTM

Most shops today are completely dependent on a single proprietary technology source. The fact that so many Microsoft shops, for example, waited until the very last minute to sign up for their new licensing plan, may indicate that these organizations could be basing critical IT decisions more on their dependence on Microsoft's tools than on what they think is best for their companies.

When we are forced to make decisions that are centered around dependence on technology from a single supplier, rather than our own assessment of future needs and goals, a critical point has been reached. At that juncture we might safely characterize such a dependency as unhealthy.

If luck favors the prepared organization a good strategy will be to begin working toward a future where our dependency no longer controls our decision-making process. If we do this we will begin to put in place the understanding and corporate infrastructure we need to gain back control. Once we've restored our ability to choose, we very well may choose much of the same technology. But we will be choosing it on our terms, not because we are forced to. The control over our own company's IT future will once again belong to us.

Parenthetically, many visionaries have been out there for some time now, building ways to free themselves and us from platform dependency. Their efforts are beginning to bear fruit that can help us. Support these open source projects and developers, with your time when you can, and with your money when you are able. They aren't asking for you to do it their way or perish. They are looking for people to help them make their wares better for everybody. By the way, they don't have a corporate marketing strategy, let alone care if their software is compatible with it.


"Interoperable solutions that are built on open and common industry standards are proving to be the winning formula"
    - Niklas Savander, VP, Nokia Mobile SW
A Tactical Progression

In the spirit of continuous improvement, the following list attempts to describe one possible step-by-step transition from dependence on a single proprietary platform to platform-neutral computing. It is meant as a guide since every shop will be different but it strives to highlight as many pitfalls and ordering dependencies as possible. If you have any experiences or insight that will help make this listing more complete or more accurate, please let me know.

  1. Set Up Your IIS Servers to Run Cross Platform (CGI) Software
    Windows® shops: There is no more important step than this one to get you through the barrier between you and true cross platform web applications. Completing this one step will allow you to run platform independent Perl programs side-by-side with your proprietary ASP scripts. I know this does nothing for the non-MS shops reading this, but it is so important to Microsoft shops that it needs to be stated right up front. If you are an IIS shop and you do only one of these steps, this one will get you farthest, fastest. For one of many short, simple step-by-step guides to installing CGI/Perl on your IIS server see How to Install Perl Scripts On IIS

  2. Catalog your proprietary macros & scripts ...or not
    Published advice will often ask you to do this as a first step in moving to system-X. If you intend to switch your systems all at once such a listing would indeed be essential. For the gradual, non-disruptive improvement discussed here macros may be left where they are. Newly written scripts should be platform independent of course.

    In this mixed environment, one approach might be to start a dynamic 'To Do' list. Your support people and developers can then add and prioritize all types of jobs required by the reform effort as they are found. A utility to maintain such a list will actually make a good first application for someone learning to write open, browser-based utilities.

    The good news about macros is that if/when you do re-write them to run in an open, browser-based environment you will almost always realize huge returns in operating efficiency. One reason for this is that macros running on spreadsheets are often the proverbial hammer being used to drive screws. Nowhere else in computing will you find more database applications being force-fit into spreadsheet practices. Often multiple spreadsheets are used and emailed all over to make what really should be one single, simple, browser-accessible database application.

  3. Install & learn Perl [2]
    Put it on all your Windows web-servers (IIS). Put it on your laptop. It's free. The site has binary distributions already compiled and ready to run on your Windows platforms. Download and install it from CPAN or one of their mirror sites. If you have in-house developers, ask them to learn Perl. Because Perl is an open source language that's used everywhere, most developers will already know it, or will be grateful for the chance to learn it. Also, programmers prefer to work on real projects rather than exercises, so once you've installed perl on your web-servers, look around for some non-critical VB scripts and ask your developers to replace them with Perl scripts.

  4. Change an intranet server from IIS to Apache
    It's free, it runs on Windows, and some think it's better. Run your new Apache server in parallel while you determine what will need to be changed on the intranet server and do it. You will learn how to produce corporate data access utilities and applications that will run on any platform with a browser. Mac, Windows, OS/400, it just won't matter any more.

  5. Develop all new client-side scripts in JavaScript
    JavaScript, unlike VB, can be written in platform independent ways. If you have in-house developers who don't know JavaScript (unlikely) have them learn it by converting an existing small VB client-side script.

  6. Get a Linux server to play with
    If you're new to it, get a distribution from Red Hat. You will learn the little things like using the forward slash instead of the backward slash, case sensitive filenames, JOE, etc. Learn to script in Perl for the server, and JavaScript for the client.

  7. Get people used to browser-based utilities
    Your users and your developers must stop thinking of the quick little utilities they build and use as macros that run behind spreadsheets. Users are always asking developers to write small spreadsheet utilities, and for time-stressed developers, the temptation will be to just write it in the environment they're most familiar with. They will reason: "It will take four times as long to learn and then do it as a browser based application because I don't understand it well. It will take me no time at all to write a quick set of spreadsheet macros. I'm in a hurry, so I'll do it as a spreadsheet". Don't let them do this. Give them some breaks when it comes to time, and then insist they put it on the browser. When I say developers, I also mean power-users who can do VB for their peers. Deputize them. Give them your commitment to help, and ask them to commit to this new, better, way. Perhaps you can start a BBS on your new Apache intranet, to give them advice and support as they embark on producing browser based utilities for the first time.

    There is nothing here but upside for everybody involved. Once you are familiar with browser-based apps, your users will be able to use their widgets in their pajamas if they want. Your developers will suddenly have lots of flexibility and power, and they'll be learning a skill set that is valuable everywhere. Not least, your organization will have all those small pieces of process and institutional knowledge represented in a form that can be run on any server, on any client, running on any computer from MAC-OS to AS/400 and all the Windows systems in between.

  8. Change your Internet server to Apache on Linux
    After file and print servers, web servers are the easiest place within a Microsoft organization to switch to more open platforms. The return is open systems, learning about security problems quickly instead of having to wait for the next service pack, better stability, better performance, and less hacker desire to access.

    Most will do this through their hosting services. Those with in-house web servers will likely have enough in-house Unix talent to switch over to a Linux server quite easily.

    The reason you installed Perl everywhere early on, and began switching over to Apache running on your Windows web servers, is so the following issues can be worked on at your leisure without the need to switch abruptly over into this new, open, way of doing things. ...

  9. Set up Linux file and print servers on your LAN
    Not application servers (see below), just file and print services. Such services don't care what platform they are running on. Also, you can leave your proprietary file and print servers running on the same LAN and move over to the new file server gradually, directory by directory, and printer by printer if you'd like.

  10. Don't throw out application servers, but...
    If you have a few large, mission critical systems running on your Windows application server (or AS/400, or other proprietary system), we recommend leaving them where they are for the time being. even if a port to an open server system is available.

    Large systems, like MRP/ERP, etc. are difficult and complex in their own right, and adding the complexity of porting to a new platform for which you are not an expert doesn't add complexity, it multiplies complexity.

    But... do install perl on those application servers. Unless you're on a one-of-a-kind platform designed and built just for you, Perl has probably been ported to run on your system (this is what open, multi-platform computing is all about). Install Perl and any new applications you develop on that application server can be moved to any application server, anywhere.

  11. Consider Linux desktops for selected users
    Once you've begun to master Linux LAN servers and open web application servers it's time to dip a toe in the wonderful world of Linux desktops. OpenOffice is not ready for business at this writing but it's clear it will be there soon. Your users won't be able to run Visual Basic apps on this version of office, but they'll have no problem sharing Word documents, Excel documents, and other Office data types with the rest of your office and the world.

    Don't go into this lightly though. Choose your initial users carefully. They should be people who would relish the chance to get acquainted with the new technology. Perhaps a little nerdy but also, look for those who like to teach and help others. You'll need them if you decide to extend desktops in the future.

  12. Get support people and developers certified
    It never hurts to fill in knowledge gaps with professionally designed skills assessments. It is also a great way to boost confidence going forward. That way, if you choose, you can take on bigger challenges.

Books & Resources

You'll find vast numbers of books, documentation, and resources on the Web that often address your particular situation specifically. You'll also find general books on, for example, Linux administration. The knowledge tools are out there for those who want to adapt their current proprietary systems to a more open posture.

This listing will change as new resources are discovered. We start with free downloads of some of the most important technologies for platform-independent computing. Books and other paid resources are listed below.

  • Downloads     (free unless otherwise noted)
  • Recommended Books   ($linked to$)
    • Linux Books
    • Perl Books
    • JavaScript Books
    • XML Books
    • Other Books & Videos
More soon...

Open Source People

Open source consultants, in general, like to play with their cards stuck to their foreheads (ok, sometimes on their T-shirts). They will be more than happy to sell you some fish in a bind, but they're just as prepared to teach you how to catch your own.

Open source communities are by their nature about leveraging their craft, the craft they love, in ways that will most help others.

Simple Browser-based App Examples

Browser based applications are simply programs that run on web-servers or browsers and that use a web-browser to present their user interface. Browser based applications, like any application, can be classified based on their complexity and information storage requirements.

Simple Database Utilities
Most of the spreadsheet utilities you use in your business that have macros incorporated into them probably fit into this category. Some examples of online utilities that fall into this category include

  • Our Job Track Utility
    This simple job scheduling tool provides a good example of the kinds of tasks offices would commonly adapt from manual procedures into clumsy spreadsheet/macro systems. This application, for example, was written to replace a spreadsheet system used by a business with four locations. If you try this utility, imagine what it would have been like as a spreadsheet and you may get an idea of why there is so much to gain by switching from spreadsheet utilities to web-based systems. Just to give you an example of what it was like before: whenever the warehouse guys received some portion of an order at their location, they would have to call the office location where the spreadsheet was maintained so that it could be updated. The entire spreadsheet with any changes that had been made the day before would be emailed to them as an attachment each morning.

  • Forums (Bulletin Boards)
    This is probably one of the most familiar simple database utilities on the web. It probably isn't a great example since there is really no analog to this kind of application in the world of spreadsheets and document forms. On the other hand, it makes the point that open systems open up a whole new world of possibilities to the organization that adopts them.

Simple Utilities That Don't Require Storage
There are a variety of tasks which perform relatively complex calculations on a small number of input variables. Tools to perform these tasks can require users to enter the required variables each time they use the tool, so no storage is required. Because these require no storage, they can be implemented completely as client-side scripts, which are processes written completely in JavaScript, so they run locally on the browser without using any bandwidth or server processing power. They can also be written as server based apps. Some examples of this kind of application include.

  • Conversion and transformation utilities
    such as our JavaScript Compressor (JSC) which transforms user input. It takes a user's uncompressed JavaScript code as input, and reduces its size by removing comments and extra space. It is written entirely in JavaScript and utilizes local processing power.

    CSV to XML, and CSV to JavaScript converters on the other hand, convert Comma Separated Value (CSV) formatted files from a user's spreadsheet or accounting programs into XML or JavaScript array files. These could both have been written in JavaScript to run entirely on the browser because no information needs to be stored. These examples however, were written as server based utilities. This demonstrates the flexibility you have in choosing where applications run.

  • Data analysis and visualization utilities
    These are often called calculators or what-if sheets. They can be quickly written in JavaScript to make calculations that are performed often. Sometimes they replace paper based look-up charts, such as amortization, or engineering tables.

    There are many examples of JavaScript calculator programs on the Web for any kind of calculation you can think of. They include calculations for such things as Ocean wave propagation, as well as all sorts of medical calculations. Perhaps you'd like to perform some flywheel energy storage calculations to test a great idea you just had for a better hybrid car. You may also choose from many different mortgage calulators, car cost calculators, and calorie calculators for the diet conscious. This should give you some idea of the types of day-to-day problems these simple utilities can solve. Oh, by the way, hospitals aren't the only ones making extensive use of these, NASA loves them too. Data visualization often goes hand-in-hand with calculation functions. These can be written in JavaScript when the visualization is relatively simple, such as bar charts that can be approximated using tables, and number manipulations that are exploded or slowed down to show the process. More complex visualizations such as 3-D charts, Pie charts, etc. will have to be done on the server or with Java.

  • Animation and visual information delivery
    Mostly just used to present static data in eye-catching ways, e.g.

    But these locally accessed JavaScripts can be combined in very synergetic ways with server scripts to display dynamically updated information, such as news scripts, and stock tickers on statically loaded pages. They can be written to extend cross-platform functionality to even the most proprietary of browsers.

    One of the best uses for animation is the presentation of animated pictures to clarify procedures, such as product training lessons, or work procedures. such animations can reduce the steepness of learning curves for everybody. A technology called Flash can greatly reduce the amount of time and effort required to produce these types of animations. Because of this Flash should be considered when there is a real need even though it is proprietary. One word of caution though, there is a phenomenon called "flashterbation" out there which is the process of producing large flash animations just because they can be done. People over age 16 or 17 in general, would rather not take the time required to watch these no matter how "cool" they are. Of course, no rule is without exception.

    Is a great P-code interpreter system from Sun that aims to be a completely platform independent environment so that applications can be written and compiled once and run everywhere (much like Perl). It includes advanced storage management and security features which make it ideal for many enterprise applications. Is it open? I believe Sun wants it to be, but many have tried to add their own proprietary extension to it, so Sun has had to hold onto some control in order to fend off these attempts. In my opinion this is a very good thing. But what if Sun gets bought out by some folk who aren't such altruists?

Utilities That Employ Simple Storage to Improve Functionality
These are generally simple utilities as above that perhaps store the last set of variables plugged into them, or that store each user's preferred starting variables. [Do you have any example suggestions?]

Complex Enterprise Database Utilities
Most new enterprise level application being produced today are being produced entirely as web-based applications. Makers of large, well known systems that were around before the web have put browser-based front-ends (user interfaces) on their systems and are doing new development entirely in web-centric ways.

Many large applications have been written as pure web-based systems, they include: CRM (Customer Relationship Management) systems, ERP (Enterprise Resource Planning) systems, Call Center Management systems, MRP (Manufacturing Resource Management) systems, Accounting systems of every kind, Workforce Management systems, Knowledge Management systems, Document Management systems, and much much more. This list could go on for a very long time in fact.


"Have nothing in your houses that you do not know to be useful or believe to be beautiful"
    -- William Morris


A negative statement will sometimes express an idea better than a positive one. The above quote for example, aside from expressing a philosophy that underpins many programmers' development styles, also speaks well to the subject of this paper.

  • Avoid adopting new open technology if it does not clearly demonstrate an ability to increase operating efficiency, access, or usability.

    Whenever something is described as "the next big thing" by someone who can't actually tell you, in concise terms, what it is, that's probably a good indicator that a sales and marketing type had a considerable amount of input when making the assessment. You'll see it stated in many different ways; "it means different things to different people" is one of my personal favorites. Browser-based applications, written say, in Perl, will run on any web-server with CGI/Perl installed. It's not "slick" it's not "sexy", it is extremely easy to implement and produces huge leaping advances in productivity compared to the technology that was in use before it (macros, spreadsheets, and bloated applications running on PCs to access data stored on the LAN).

  • Avoid adopting new proprietary technology if it does not clearly demonstrate huge advantages over existing non-proprietary solutions.

    There are very real costs associated with locking your systems into a single provider's solutions. Some of these costs are often improperly reported in trade journals as the cost of switching to the open, platform-independent solution. Don't be fooled. If you do have to switch sometime in the future, it will be because staying with the proprietary system will be demonstrably less profitable or more risky than the cost of switching. These costs would not have been incurred if the proprietary system were not deployed in the first place. Therefore the cost of switching away from a proprietary system should be associated with the decision to adopt such a system in the first place.

  • Treat proprietary technology that is "based on open standards" as you would pure proprietary technology.

    Anything that is designed first to "lock in" a customer base is proprietary, even if it is based on open, platform-independent standards and technologies. The rules for pure proprietary technology discussed above should be applied with equal conviction to this class of technology.

  • Look out for a new oxymoron: proprietary-standards

    As of this writing a company called webMethods holds a patent on some of the in the SOAP 1.2 "standard". They are refusing to give up their right to collect royalties on that patent from anyone implementing SOAP 1.2. This new policy of the W3C to allow patented, proprietary, technology that will require royalties to be collected is ill conceived. It produces minimal returns for the salesmen at the companies who collect royalties from these supposedly open standards, while risking maximum damage to the information industry in general, and to the Internet specifically. Those who feel an obligation to protect their industry must choose their battles wisely, but should try to avoid these new marketing devices whenever possible.

  • Cautiously, slowly, but deliberately pull back from consultants who are as dependent on a single provider as you are.

    If you are (for example) a Microsoft shop, you need consultants who have wrapped themselves in the Microsoft banner, using all the Microsoft provided tools and educational materials. They have honed their Microsoft skills to a sharp, efficient point. The problem with these consultants is that they often accept the Microsoft "way" without question in return for the time that would have been required to gain a truly platform-independent perspective. They will be truly convinced, for example, that the browser applications they are building --with Microsoft tools, using Win32 dependent DLL calls, and requiring Internet-Explorer(I.E.)-- are platform-independent because they run on XP, NT, and 200x platforms.

    If you are a Windows dependent shop you can't simply turn away from this type of consultant. But you can recognize their limitations.

    You can also look for consultants who understand and are comfortable working in the Microsoft "world" but who are equally comfortable producing true platform-independent solutions. These are much rarer than those who have "drank the Kool-aid". Don't value such consultants because they are rare though, value them more highly because they are more valuable to your company.

In Defense of Microsoft

There are plenty of groups on the web dedicated to Microsoft bashing. This article will not be proselytizing for their cause.

In my opinion as someone who's old enough to remember the halcyon days[3] of computing; dirty tricks or not, Microsoft grew to their current size and market strength because they sold 'decent' software at reasonable prices. Instead of selling buggy word-processing systems to a few law firms and medical centers for $20,000 each (about $45K in 2004 dollars), they had the vision, long before computers were common in households[1], that better software could be delivered at much better prices if it were delivered in quantity.

So when this article says that Microsoft is the McDonald's of software, it does not say it with contempt, as you might expect from the church of the MS bashers, but with great respect. Though I'm having trouble warming up to his "over-the-top" partner, I place Bill Gates in the same league and company as Ray Kroc, Sam & Bud Walton, and others who saw their fortunes in improving the lot of the common man.

Does that mean we're members of the church of everything Microsoft here at Creativyst? No, not at all. Our web servers are Apache running on Linux boxes and, as you can see, though we often perform work in Visual Basic for our clients, we prefer platform-independent standards like, Perl, C, and even JavaScript.

And that is the point of this article. We do not prefer Perl to Visual Basic because of any religious considerations. We prefer it because a script written in Perl with an HTML front-end will generally run the same on any platform, whether it is Windows, Mac, Linux, AS/400, or even main frames. Perl was not produced to protect any large corporation's business and marketing strategy. It's there to allow developers to write programs that anyone can use from anywhere. Not just people who have purchased one particular company's platform.

While this article mentions Microsoft often, that's only because they are the overwhelmingly dominant factor in the IT world today. I appeal to all of you from those other churches of thought to consider your own reality. Most of the other companies are playing by the same rules; producing platforms and frameworks that are designed first to protect their corporate marketing strategy, and second to run usable software.

With this understanding, this paper has tried to explore realistic, cost-effective ways to turn away from the hype and religious zeal. This article then, is about finding a new way to think about our craft as IT professionals. We can start by resolving not to bash anybody.


This article is © Copyright, Creativyst, Inc. 2002 - 2006 ALL RIGHTS RESERVED.

Links to this article are always welcome.

However, you may not copy, modify, or distribute this work without first obtaining express written permission from Creativyst, Inc. Those wishing to obtain permission to distribute this article or derivatives in any form should contact Creativyst.

Permissions printed over any code, DTD, or schema files are supported as our permission statement for those constructs.


  1. A few geeks, some computer clubs, and, of course, those lawyer's offices. (back)

  2. PHP is also a good choice but it has not been ported to nearly as many platforms as Perl has.(back)

  3. An eight bit processor called the Z-80 was king, Saturday Night Live was funny (and ahem, live), and Gates publicly wondered why anyone would ever need more than 640K of RAM. (back)

© Copyright 2002 - 2007 Creativyst, Inc.

Written by Dominic John Repici

Many thanks to:
Toby Meehan - for proof reading help