Slashdot Mirror


The Woes of Munich's Linux Migration

mikrorechner writes "The H Online has a writeup of the problems encountered by LiMux (Wikipedia entry), one of the most prominent Linux migration projects in the world, trying to introduce free software into the highly heterogenous IT infrastructure of the City of Munich. Quoting: 'Florian Schiessl, deputy head of Munich's LiMux project for migrating the city's public administration to Linux, has, for the first time, explained why migrating the city's computing landscape to open source software has taken longer than originally planned.'" Here is Shiessl's blog, in which he details some of the transition problems.

4 of 314 comments (clear)

  1. Because every project is late by 0racle · · Score: 5, Insightful

    Everyone always underestimates how long anything non-trivial is going to take. In this case it seems like not only were they trying to migrate to a new platform, but also trying to undo every past mistake, oversight and quickly implemented solutions that appeared on the surface to work just fine. That's going to take just a little while to get done.

    --
    "I use a Mac because I'm just better than you are."
    1. Re:Because every project is late by Locutus · · Score: 5, Insightful

      but it sounds like most of the problems were due to underestimating how many non-standard development tools and products were used and the trouble getting those over to GNU/Linux. Many of them required either the original vendor to port to an open standard or replacing the existing product with one which was based on open standards. The first option meant that most likely a Microsoft Partner Program member would have to be hired to provide the same product for the GNU/Linux clients. This might normally be an easier option except being a _Microsoft Partner_ often times means you are not allowed to work on other platforms. So the 2nd option is most likely their only choice and that is more expensive in that it would require all users to change the underlying software they currently use for the task.

      All in all, this sounds like confirmation that Microsoft's strategy of proprietary API's and patented IP was successful in making it costly to leave their platform. It also shows that it is not impossible and in the long run, it will probably be shown that getting off the Microsoft treadmill might be expensive up front but over time, become very cost effective. Rip and Replace most often ends up resulting in a better, faster, cheaper solution when managed well.

      LoB

      --
      "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
  2. Bad title is bad. by Statecraftsman · · Score: 5, Insightful

    I recommend to read the blog as it's more informative and it's also rather optimistic. Not just woes as the title would lead you to believe. Of course making the switch to free software takes work, but it's a great opportunity for constant improvement and as Mr. Shiessl points out, there is much digital waste to be cleaned up on exit from the proprietary.

  3. Perspective by Locke2005 · · Score: 5, Insightful

    How does this compare to the problems experienced by people migrating 15,000 clients running various Windows releases to Windows 7? Is migrating to Linux more or less costly than migrating to the latest release out of Redmond?

    --
    I've abandoned my search for truth; now I'm just looking for some useful delusions.