That is the take from analyst The 451 Group following Thursday night’s “it looks really big but its actually not” announcement from Microsoft that was positioned by the software giant as if it had come over all fluffy and liberal about sharing its APIs and not stomping all over open source competitors.
The analyst had a lot to say on the announcement but this specifically for chief information officers and other top-of-the-food-chain IT pros:
Open house at Redmond? Well, no but the departure of Bill Gates means some of the holy cows are finally being slaughtered. The rationale, as ever, is to dominate.
MSFT controls the desktop and has no intention of ceding that to anyone, open source or otherwise. By opening up the APIs it is attempting to at least manage (control, preferably) the direction of the open source movement.
For some CIO’s, the initial reaction to MSFT’s new found openness will be a cycnical belly laugh. Equally, many who are wary of using open source in anger at the enterprise level and the consequent risk to brand – real or perceived – will be more likely to take Redmond’s route to open.
MSFT is taking a number of calculated risks. For one, it has validated the concept and legitimized any number of competitors, all of which have open source pedigrees, unlike Microsoft.
MSFT’s business model is not based on openness. It will be fascinating to see how it goes open and maintains its number one position. This could be it’s long awaited entrée into the enterprise (where it has always denied any ambitions) but anything that offers CIO’s more choices – be it supplier management, costs or technologies - has to be applauded.
What is clear is that the software landscape has undergone a fundamental change today. The effects won’t be immediate but vendors and users are now operating in a very different climate, At the very least this is disruptive and in the long term, probably seismic.
• WINE - if you know all the Windows APIs, you should be able to get any Windows Application running on Linux quite nicely
• Vendors wanting to get their client software interoperable with Exchange
• SAMBA - proper interoperability with Windows File and Print services without having to guess the APIs. (Note: Samba struck a paid interoperability with Microsoft at the start of this year).
• Exchange alternatives - Zimbra etc. Enables them to develop proper interoperability with Exchange servers and the ability to act as a replacement for Exchange
• Calendar and Workflow clients - they will be able to build proper hooks into Exchange.
• Vendors and end-uses looking to implement web services and software-as-a service architectures, who require deeper and more consistent access than has sometimes been available from Microsoft.
• Any company attempting to sell hub workflow servers that competes directly with Exchange & SharePoint. They might end up having to implement Microsoft protocols. On the other hand, they can still offer interoperability.
• Any companies whose secret sauce involved reverse engineering MS APIs.
• Google – as an open platform advocate – and Linux-focused vendors such as Red Hat and Novell may find themselves less able to play the “proprietary” card against Microsoft in the future.