Now Read This: Why the Munich Open Source Conversion won't be replicated in Australia.

Whichever side of the Open Source vs Proprietary Software debate you lie on, this article is a "must read". The headline take-away is: "Our goal was 'Freedom', to become independent."

How Munich rejected Steve Ballmer and kicked Microsoft out of the city, Steve Heath, 18th Nov, 2013.

• This piece proves it's possible for an organisation to leave the Microsoft World.

• They couldn't migrate everything.
• They prioritised what they'd migrate or replace and adopted different solutions suitable for each application.
• This was very similar to dealing with Y2K.
•  Solutions like VM's & Virtual Desktop Environments are needed.

•  As Microsoft says, Free Software isn't Zero Cost, but is cheaper.
• what nobody discusses is how much staying on the "Microsoft Forced Migration Path" costs. This is the real baseline for comparison.
• They'd have been up for the same, or higher, costs migrating from Windows XP to a Windows 7 or 8 (Vista, the least popular O/S ever, was never an option).

• Munich started planning and preparation in 2002/3, rolled out a major Application, Open Office, soon after and then in 2012 upgraded all desktops to LiMux over 12-18 months:
• Sorting out the "IT zoo" was expensive & necessary, even if they'd stayed with Microsoft.
• They brought the organisation into the modern era of the "Standard Operating Environment" - a single, secure build used on all Corporate Desktop machines.

• As more organisations embrace Open Source it, it's cheaper and easier, and suitable staff and services more widely available.

• Munich created their own "LiMux", based on Ubuntu.
• a team of 25 develop, roll out and support LiMux.
• fewer than are needed to support the Windows PC's.

Heath writes near the end that Organisations who've have failed in their Open Source projects were only doing it to save money, the implication is this as a sole motivator is a guaranteed "fail". Like any large disruptive change, top management support and active Change Management are necessary.

With the looming deadline, April 8th, 2014, for the last "patch Tuesday" security upgrade of Windows XP, a lot of older desktops will be forcibly orphaned or discarded. Upgrading these old PC's to Windows 7 or 8 is impossible or uneconomic.

Users who wish to keep their old PC hardware running must convert to some flavour of Linux.
Users who buy new hardware get NO advantage by sticking with Windows: Microsoft gain no benefit from being the existing Operating System. Converting to Apple is likely to be a much cheaper and easier option than going to Windows 8 for XP users.

Doing nothing is not an option:  there are enough "Zero Day exploits" on record, geek-speak for "security bugs with NO published fix", that it's guaranteed within 12 months all Windows XP machines connected to the Internet will be "owned". No sane owner would put themselves in this position.

I told an old friend in a Government Agency, a long time advocate for Open Source, that Security should be an overwhelming reason for the Public Service to aggressively pursue an Open Source strategy:

If you don't have the source to your Operating System, Tools and Applications, and the people to understand & fix the code, then why would you think you can ever be 'secure'?

• After Stuxnet and its two successors, we now know that "Air Gaps" are not nearly the impenetrable barriers for Secure Networks they once were.
• The Iranian centrifuge controllers attacked & compromised were on an isolated network, yet were taken over and without being detected.

• After Mandiant's APT-1 (Advanced Persistent Threat, #1) revelations, we now know that there are many Nation-states with the will, capability and motivation to run many military-grade, very long-term cyber-intelligence missions.

• If the USA, and possibly Israel, can access highly protected environments, then so can other actors, state or commercial/criminal. The code is out there in the wild and can be reverse engineered and retargeted for other uses.
• The number of Zero Day compromises available to both for-profit hackers and "Cyber-Commands" is unknown, but suspected to be high.

There are now two critical commercial risks for every Organisation or Individual that's tied itself to the Microsoft Ecosystem. Remember that Microsoft is under NO obligation to continue any service or product, or maintain current pricing & availability:

• Microsoft may ditch on short notice one or more products and services that are mission critical for the business.
• In this new world of 'cloud' licensing, the time from the announcement to your software not running, could be as short as one month. Even with a decade warning and preparation, Y2K turned into a mad scramble. This scenario will be many times worse.
• Microsoft have a history of suddenly dropping products and orphaning users without support or migration path. 

• A Microsoft under New Leadership will attempt to redefine itself and will shed "non-strategic" assets and products.
• This may take the form of selling all, or part, of the Business and Services divisions to End of Life Consolidators, like Computer Associates and Fujitsu.
• Anyone with a mainframe who's been trapped this way will tell you its not a happy experience, nor cheap.
• Consolidators pay a premium to acquire End of Life products, then exploit the dependence of customers to create very handsome profits for themselves. 
• Maintenance and upgrades are minimal, if they happen at all.

There's a few simple questions that Senior Management, especially in the Public Service, need to be asking about these risks to their business from Microsoft changing it product lineup and charges. If you thought Y2K was expensive and disruptive, you haven't seen anything yet:

• How much more dependent is your business, especially routine front-office operations, on computers and I.T. compared to Y2K, 15 years ago?

• Have you contingency plans written, let alone tested, for any of your Microsoft products being suddenly withdrawn?

• What level of dependancy do you have on the Microsoft Ecosystem?
• Could your business even operate one day in "manual mode"?
• How quickly could you cobble together replacements if every other major Corporate customer in Australia was competing for the same resources and services?
• Such as during Y2K and GST projects in 1999/2000.
• If you contingency plan is "get Microsoft to help us", that will fail because they won't be able to cope with demand, even if they offer help and support.

CEO's, CFO's and CIO's who haven't already answered all of these questions today are likely to have a very rude awakening, the least of which will be losing their jobs.

We know from the collapse of IBM's business in 1992 and 1993, still the largest corporate losses survived by a US company, that problems do arise for "too big fail" I.T. vendors and can take the market and customers completely by surprise.

IBM is far from the only leading I.T. vendor to fail: Unisys, the 1986 merger of numbers #2 and #3 (Sperry Univac and Burroughs), led to a dysfunctional, unfocussed, strife ridden company that imploded and was abandoned by 90% of their customers in only a few years.

The major lesson from IBM is the frightening speed with which these reversals occur: within 6 months of the first warning signs, the business was uncontrollably bleeding red-ink. The causes of sudden collapse mean there is no easy way back to profitability. IBM embraced Open Source, added Services and PC's as its major product lines and reorganised its mainframe business, radically reducing prices and taking a massive, though temporary, hit to their bottom line.

Microsoft has only two profitable software products, and they go back 20-30 years:

Operating Systems and Office Applications.

What's salutary for both investors and customers, is that, unlike IBM before it, Microsoft has never created another substantial line of business, despite repeated attempts and tens of billions of dollars wasted. They owned the mobile and smartphone business from 1995-2005, yet were slammed by the iPhone and became irrelevant in the marketplace within 24 months. They invented "Tablets" but have yet to release a competitive product.

Microsoft have attempted to enter every market, business and consumer, that Google, Apple, Amazon and VMware have shown are profitable and in high-demand. Without fail, Microsoft has failed to create another significant line of business for itself. The X-box has been a marketing triumph and financial failure. It only returned its first profits in the last few years and in terms of total profit, is a footnote at best to the business.

These problems were apparent in 2005 when Microsoft announced they'd abandoned around 25,000 man-years of effort in 2004, with the "Longhorn Reset". Their corporate Project Management and Software Engineering skills, core competencies for I.T. vendors, were so throughly compromised, they were unable to achieve the basics: bring a product to market.

Windows XP, in 2002, was the last successful and widely welcomed Operating System developed by Microsoft. Since Vista, Microsoft Operating Systems have only been grudgingly taken up by users, especially by Corporate users. The 8th April 2014 "End of Life" for XP may prove to be a turning point in the fortunes of Microsoft, as they discontinue their most popular and reliable O/S product.

Microsoft failed to master what ever other successful hardware company does: yearly system updates.
Since Windows NT 1.0, around 1993, they have failed at this basic & essential task.
Look at every other large commercial Operating System vendor: as a matter of course, they have a yearly release cycle, sometimes with major releases every 2-3 years.

Well run Operating Systems groups are able to roll out tested, robust "production ready" releases every year and reduce security issues with every release.

Microsoft has shown for twenty years that they cannot meet this minimum, necessary standard of Software Engineering for Operating Systems. This is not just a failure of technical and project management staff, but of management to the highest levels.