Is Microsoft using the “anti-lock-in” argument from OSS’s playbook?

I’m finally getting a chance to read up on the Microsoft interop news today. It really sucked to see the headlines all day, but not have a chance to read them until now.

While the words “open source” are mentioned in the announcement and on Bill Hiff’s post, this is really about open APIs, not open standards or open source. (Maybe ‘not’ is too harsh; maybe I should say ‘and significantly less about’).

Obviously Microsoft is opening up their APIs because it makes business sense. Google, Facebook, Amazon, etc. have already made the business case for open APIs to closed software. If you ask me, the interop announcement virtually eliminates (on paper) the argument that Microsoft will lock you and your data up. Hmm…have we seen this playbook before? Maybe from OSS vendors? “Use our product and you won’t get locked in. You have the source code so you can always go elsewhere if you’re not satisfied with us.” Understandably, Microsoft’s position isn’t as eloquent. However, it does counter a potential barrier to remaining a Microsoft customer. Let me be clear, I do not think Microsoft’s interop announcement actually protects against lock-in. It seems like Cote would agree:

“Overall, the thrust of the press release is that Microsoft is going to make the documentation and access to its software better (easier? Doubtful. See Joel’s piece), that is, more interoperable.”

But, it doesn’t matter what I (Joel or Cote) think. What matters is how Microsoft can market the anti-lock-in angle and how customers will respond.

I have never thought that OSS would be the end of Microsoft or the commercial software market. The fact that Microsoft is borrowing (in their own unique way) from the OSS playbook should scare OSS “freetards” straight.

 

Write on .NET, deploy on Java

Having spent the better part of my career working with products that are based on JEE, I sometimes have to remind myself that .NET is still quite prevalent. You’ll find that there are customers who are “JEE shops” or “.NET shops”. But a fairly large portion of customers have both JEE & .NET in their IT environments. I saw a Gartner estimate of JEE only/.NET only/ JEE & .NET/Other architectures representing 25%/25%/35%/15% of all customers. Take that “data” with a grain of salt as it’s old and based on my fuzzy memory. The larger point is that a significant portion of enterprises have both .NET & JEE.

We could argue about the pros/cons of each architecture, but customers seem to have voted with their wallets and use each as appropriate to address business needs. This statement could equally be applied to the OSS & Traditional software discussion.

I had the opportunity to speak with Jenna Dobkin from Mainsoft last week. (Mainsoft is an IBM business partner). Mainsoft provides .NET to JEE interoperability by allowing .NET apps to be cross compiled to run natively on a JEE runtime. I was intrigued by the technical feat behind Mainsoft’s offering. It allows customers with .NET skills and assets to continue benefiting from their previous investments while being able to deploy to JEE platforms. Why JEE? Well, it could be because customers want the performance, reliability, availability, etc. benefits of JEE. Maybe they want to shift towards open standards-based applications. Maybe their end customers are “JEE only” shops. Maybe dropping the “2″ from J2EE did the trick!

Jenna put me in contact with two Mainsoft customers to understand why they didn’t *just* deploy to .NET or *just* write in JEE. Note the emphasis on my implied simplicity of the word “just”.

I spoke with Bart Sijnave, the CIO at UZ Gent, a university hospital in Belgium. I also spoke with Atul Mistry, VP of Technology at Urix, an ISV in the healthcare industry.

Both Bart & Atul indicated that their organizations had .NET skills and re-training their developers (teams of less than 20 in both cases) for JEE was not a viable business option. Bart suggested:

“If I had a larger team, I would add JEE-specific development skills. But I could not meet my customer’s time-sensitive demands if portions of my team were out getting re-trained”.

UZ Gent uses RHEL and other OSS products and looks for opportunities to expand OSS use as appropriate.

Atul said:

“Business is the key decision criteria for us. If you have to reinvent the wheel because of a religious technical belief then you are not doing the right thing for your business.”

Urix has customers whose IT environments are largely Unix based. Faced with not addressing these customers or adding new staff to port the application and continue development on Unix, Urix made the business decision to use Mainsoft. Urix also uses OSS technology such as log4net and other OSS technologies aimed at Microsoft developers.

Both organizations are believers and users of open source products. But, for these two companies, business results trump beliefs. I suspect this is the case for the majority of customers. This is why I believe that OSS will never truly “take over” the software world, nor will OSS fade away. Pragmatic customers wouldn’t allow either to occur.

Customers have to be pragmatic because their business depends on it.