Slashdot Mirror
How Munich Abandoned Microsoft for Open Source
An anonymous reader writes "TechRepublic has the story behind Munich City Council's decision to ditch Microsoft Windows and Office in favor of open source software. The project leader talks about why the shift was primarily about freedom, in this case freeing itself from being tied into Microsoft's infrastructure and having control over the software it uses. He talks about how the council managed to keep such a large project on track, despite affecting 15,000 people and spanning nine years. He also warns against organizations justifying the shift to open source software on the grounds that it will save money, arguing this approach is always likely to fail."
Actually this is a good point. My wife works for an insurance company. People there are just expected to know how to use a computer and MS Office by extension. They never receive training and the results are half can barely turn their machines on, the other half spend all day running around doing everyone else's work. We seem to expect people need training with FLOSS products, but expect them to just know what they're doing with MS products.
It's shameful really, I've spent many an afternoon banging my head on my desk while trying to talk someone through the ribbon interface because they were just expected to know what to do when Office 2007 first came out.
Many years ago - maybe in 1995 or 1996 - I worked on a team that wrote a load balancing software. We did some in-depth performance measurements of a few web servers, which also included web servers running on Windows NT. We finally also wrote our own little test server. We concluded in our tests that the listen-queue length on NT could only be set to a certain maximum amount (maybe 5, or so) by anyone using the official socket API that was available. However, magically, Microsoft's own web server (IIS) was able to utilize a longer listen queue.
Clearly, Microsoft is not beyond using secret APIs to ensure a competitive advantage for their own software.
FLOSS changes the costs. You spend more in training, but save on material. If your organization already has significant training procedures to accommodate big processes (like, say, a government would have), you'll probably come out ahead on the deal. If you have an office of 50 people who were all hired already knowing Microsoft's products, you can expect significant retraining costs that might exceed what you'll save on licensing.
From what I've seen, small businesses won't have training infrastructure in place. Software needs to be able to be configured and used by people with little or inadequate training on the software or related technology. Large businesses do have dedicated training, but this is industry-specific. For example, insurance companies will have extensive training on policies and procedures so adding software/IT training is straight-forward. This is because the business lends itself to having a lot of people doing the same job, at the same location. But it won't work as well for, say, a retail chain. That's because while they have a lot of people doing the same job, there's only a few at each location.
What I've found to be by far the biggest cost in IT is support though, not training. I worked a contract out of a hospital that was switching over to a new electronic records system. Despite each employee receiving close to 60 hours of training each, on-site resources at each hospital given an additional 40 hours of training on top of that for more in-depth training, the whole thing detonated on the launch pad. The reason for the failure was that, although plenty of training had been given on the user interface and what-not, hospitals are highly specialized in how they process things; every department had its own unique process. And it resulted in a support nightmare that caused their entire organization's IT to seize like an engine without oil. Everybody, at every level of IT, was manning the phones for close to a month. There were no patches. There were no deployments. There was no new equipment being installed or upgraded. Everyone basically got kicked to tech support and pulled long, long hours, with queue depths that would summon images of the Krakken when viewing them.
While this was a proprietary solution sold with the promise of higher automation, lower operating costs, and compliance with all applicable laws... when the tires met the pavement, those savings were dwarfed by the support costs, which continued to be high for the next six months post-launch. They anticipate replacing it in 7-10 years. But in those six months, all the potential savings for the rest of its expected service live, vaporized under the heat of support costs.
This is not an atypical situation; most IT projects fail in this fashion. Open source doesn't change this. Zero cost software would still only reduce the total cost of ownership by perhaps 7-10% in a best-case scenario. If you want to save costs in IT, worry less about the software and more about the strength of your project managers. Ultimately, your organizations ability to rapidly respond to changing user needs and have a broad IT skillset across your department's labor force, will do more to help your bottom line than any technology or software you will ever purchase.
#fuckbeta #iamslashdot #dicemustdie