The LiMux project is “on schedule”, and “over quota”
The project LiMux
On 12.12.2011 the 9,000th PC workstation in the Civil Engineering Department migrated to the new LiMux client. Thus the LiMux project is proceeding faster than expected: 8500 PC workstations were planned by the end of 2011. Similarly, substantially all MS Office suites are uninstalled, with few authorized exceptions. The municipal government change-over from MS Office to OpenOffice.org 3.2.1 will be a bit longer, because in some cases, the dependence on specialized procedures is still too large. But the more we succeed in being able to run the equivalent open source application to replace it or virtualize it, the more likely it will be the last MS Office suites replaced by OpenOffice.org.
In 2012, the rest of the planned 3,000 PCs will be migrated to the LiMux client and the migration completed. In addition, we shall continue to replace proprietary business applications with open source solutions.
The meaning is clear: the end is in sight. It has been a long haul but Munich will finally have a GNU/Linux system working for them instead of Munich working for M$. While there has been much cost and pain in the process, the future is forever and the benefits from switching to GNU/Linux, open standards and more efficient organization will continue to roll in. If there is one lesson learned from the process in Munich it is that the sooner migration is started the better. Otherwise, you’re just digging a deeper hole. While that other OS can form a basis for IT it is an unstable one designed to bring profit to M$ above all else. With GNU/Linux, FLOSS and open standards, an organization has much more control over its destiny. Almost every “feature” that M$ created served to lock-in Munich more strongly. They recognized that and took action.
Many of the delays were totally unnecessary and triggered by friends of M$. Those people are not your friends. We see that in some of the commentators here. They come to distract, abuse, and delay, not to contribute. In addition to normal due diligence back in 2003-2004, there was patent FUD, SCOG v World (funded in part by M$), and public criticism based on nothing. The result was that the plan for migration was revised multiple times and a year-long testing period was added. This added costs with little or no improvement in performance. Some of the extra time was used to replace macros and forms, some for reorganizing the IT structure but the software on the clients would have run well from the beginning. Efficiency delayed is efficiency denied. A better plan would have phased in the changes: first change the apps to FLOSS wherever possible, then change the OS where the FLOSS apps permit and use virtual apps for the rest, then reorganize the whole IT system which would have been easier with FLOSS and open standards throughout. Instead requiring all the ducks to line up before moving the first step made everything difficult.
My recommendation is that such projects should be divided into reasonably sized chunks and done as soon as possible. Otherwise the benefits are reduced. In particular, one can put the applications for some subset of machines on servers and replace the machines with thin clients a lot faster than using thick clients. That gives immediate savings in power and cost of equipment and reduces the amount of software changes by an order of magnitude.
One thing that Munich did well was to resist M$’s salesmen. Those salesmen are the best and brightest M$ has to offer. Munich did not just look at the short-term costs but also the long-term benefits. M$ will, in such cases cut prices to zero if necessary, but the price of slavery is too high. The fact that they will cut prices to retain users is proof that their prices are too high, and maintained by their near monopoly. A monopoly can be a good thing if it is well regulated publicly but M$ is an evil monopoly designed for no other purpose than to maximize the cost of IT/revenue for M$. It is irrational to cling to M$’s operating systems or office suites or anything else as a platform for IT. Even if it works for you at some point in time it will work to M$’s benefit and against your best interests. Munich was pressured by M$ to buy XP/2003 for no benefit whatsoever for Munich when Munich was reasonably satisfied with NT 4. M$ made NT 4 impossible for Munich to support pulling the chair out from under Munich with its neck in a noose. M$ made it difficult to migrate from NT 4 by providing lots of hooks in the software that were specific to M$. Those were layers of lock-in that Munich escaped.
Another thing is clear. If Munich with all the lock-in that it had was able to do it, anyone can. Smaller organizations usually have less lock-in. Individuals often have no lock-in whatsoever because they mostly use the browser and a few generic applications, often FLOSS already (FireFox, OpenOffice.org). Don’t worry about initial cost of migration or insurmountable problems. Those difficulties pale in comparison to trudging on the Wintel treadmill forever.
Consider the following table. Imagine how steep the rise for cost of using M$ would be if the organization had a growing number of PCs. The most benefit to changing to FLOSS is obtained by changing as soon as possible. Essentially it costs twice as much to own a PC running that other OS compared to Debian GNU/Linux. This does not include the cost of maintenance, lock-in, malware and an office suite all of which are less with Debian GNU/Linux.
Cost of IT with and without TOS (5 year refresh cycle for TOS, 8 year for Debian GNU/Linux)
|M$ ($)||Debian ($)||M$-Debian ($)|
|Year 1 Acquisition||500||400||100|
|Year 5 Refresh||500||600|
|Year 8 Refresh||400||200|
|Year 10 Refresh||500||700|
|Year 15 Refresh||500||1200|
|Year 16 Refresh||400||800|
|Year 20 Refresh||500||1300|
|Year 24 Refresh||400||900|
|Year 25 Refresh||500||1400|
|Year 30 Refresh||500||1900|
|Year 32 Refresh||400||1500|
|Year 35 Refresh||500||2000|
|Year 40 Refresh||500||400||2100|