|
Copyright (C) 2001 - Adam Ophir Shapira: Verbatim copying and distribution of this entire article is permitted in any form or medium, provided this notice is preserved. Modified versions of this document may not be distributed. |
The Windoes Monopoly Cycle is a cycle of stages that causes Windows to remain dominant even though it is an inferior system to Linux-OS. One goal of LIPI is to short-circuit this cycle.
The majority of computers run Windows-OS. Since the market for third-party applications is made up of computer users, the users of these Windows machines form the majority of the market, which leads us to the next stage of the cycle.
The largest market for third-party applications is for those that run on Windows-OS. Therefore, on the short run, it is more profitable for third party developers to develop software for Windows. Of course, on the long run, it's not so profitable for them to do that, because Windows truly is the playground for Microsoft, where that company can jerk the rag out from under anyone else. However, the short-sightedness of a depressingly large number of developers leads us to the next stage of the cycle. (NOTE: It's at this stage that LIPI could short-circuit the cycle.)
Most of the effort of third-party developers is directed towards writing software for Windows-OS. As a result, most of the software available commercially is for Windows-OS. This leads us to the next stage of the cycle.
It is easier to find software for a given purpose if you run Windows. And, though Windows has flimsy security, changes crucial aspects from one version to the next, and so forth; for many a computer shopper, an important question (if not the primary one) when they choose their Operating System is "Can I run Application X on this system?". The grim answer to this question leads us back to Stage 1 of this cycle.
Now the question is: What can LIPI do to even the playing field in this cycle? Simple. It will now give third-party software vendors the opportunity to package programs that will work independently of the Operating System that they are to be run on. Such programs would cater to a larger market than those written for any one specific Operating System.
Of course, that doesn't mean that once the LIPI Virtual Machine is complete, all vendors will write for it alone. For one thing, there's no guarantee that all vendors will be fully aware of the option of LIPI software. Second of all, native code will always run faster than Virtual Machine code. Though propper design of the LIPI Virtual Machine (including but not limited to high-level native libraries that come with the Virtual Machine) could minimize this lag factor, it is a drawback that can not be eliminated entirely.
However, though this lag factor can't be elminated entirely, it can be reduced to the point that (for most applications, at least) it is not enough to outweigh the advantage of freeing the program from being tied down to just one platform. And though LIPI can not level the playing field entirely, it can reduce the disparity to the point that an inferior Operating System can not retain it's position of monopoly indefinitely by merely playing on it's recursive advantage.