Today, I saw a post on Craigslist with the statement
“We believe they should investigate vendor developed and or vendor supported open source accounting/ERP software to avoid lockin and associated cascading fee. ”
That got me thinking and writing this post. I am familiar with the technology and functionality used by a few open source softwares. And ofcourse, I am also familiar with the commercial ones.
The above statement on the craigslist post mentions “to avoid lockin”. Now, what exactly is concerned as a lockin to be concerned about?
Let’s see. Any enterprise application, be it open source or closed source, requires a few key components. And they are, the operating system, the database, the middle-tier server and finally the language to write the application. Those familiar with the LAMP (or WAMP) knows I am referring to for example, Linux, Apache, MySQL and Perl/PHP/Python combination. Ofcourse, it could very well be Tomcat for Middletier or Ruby for programming language. But the point is, that these 4 are the key components to build an enterprise class application.
Some of the open source products I have evaluated stick to a single programming language. Few of them offer database independence, but at the cost of not being able to make use of some database specific optimizations. But let’s ignore that for a moment. Now, what would a company evaluating for a enterprise software consider a lockin? Is it if all of the above key components are not interchangeable? Is it if only some of them not interchangeable?
Now, let’s look at each of the component.
Programming Language: Most open source applications are developed in a single language. And it’s not possible to start using one of those open source applications and all of a sudden, just because your internal IT staff is familiar with a different language, expect it to be available in that too. Ofcourse, chances are the IT department wouldn’t have picked an open source application whose language is not familiar to them, the same way as a CIO wouldn’t pick a commercial enterprise vendor unless he is familiar with that vendor in the past life or has a buddy working at the vendor offering all kinds of incentives however little they may be. But, what happens when the original IT staff moves out, downsized or moves into management roles? Who are going to handle your already existing open source application written in a language that is either alien or frowned-upon by the current IT staff?
Application Server: Most open source applications go with a java server or an apache module/cgi. This means, you are already committed to using one of them. It’s just that by starting to use one of them, your decision making has been made easy in the form a pre-requisite. I mean, would you question if your favorite open source CRM application says that it needs Apache to run it, “why can’t it work with my existing tomcat installations?”
Database: There are a few database independent drivers that enable applications to be written such that it’s database independent. However, remember that the open source application vendors don’t have the resources to test it with all possible combinations. While they can claim to be independent of any of the database, their testing and main-stream support is limited to only one of them. The one that most people just follow without questioning, yet thinking they have the choice to do whatever they want.
Operating System: Apache and Java server already make the operating system transparent in most cases. Most of the commercial vendors offer equally good support for multiple operating systems as their open source counterparts. Ofcourse, Microsoft is the only exception.
So, next time some one tries to tell you that by moving to open source you won’t be lockedin, think carefully what that really means to your organization. Infact, what really matters is to standardize these 4 key components within your IT infrastructure such that you get scales of economy.
currently costs less than $100 and integrates well with 
poeticcode 