Open Source Options - yet again

(I have gone through this discussion tens of times with IT folk. It has been written down by others so often it seems silly for me to even do it again. But sometimes ya feel compelled.)

Recently I was asked a question in an interview that went something like, "Have you had experience deploying commercial software? Something that you had to design your processes around?"

Well, of course I have used proprietary software. It was an easy question and I could have answered it in a second and put it behind me. However, hidden in the question was an assumption that bugged me. It took me a minute to understand that she believed that IT professionals that use open source software in their work must be doing so primarily so that they can tailor the software to their exact needs. But in my experience, the bulk of open source software is deployed and used "as is". There have been more than one client that has asked me if I would "mind" using proprietary software instead of, or in conjunction with, open source software - a sort of philosophical litmus test that is thrown down to see if I am some sort of zealot that couldn't work with piece of software because I couldn't modify it to my heart's content.

In truth, I am usually stuck in the position of conceding to the limitations of the software and wishing that it did what I wanted rather than trying to get it to do my bidding. Most of us are. Who tweaks the linux kernel? Who modifies the Apache web server or the MySQL database servers? More often than not we use tools for what they do without any modification.

I needed to inform the interviewer that while the freedom to modify the code comes with the licensing of open source software, it is probably a rare group that could tailor all aspects of an existing piece of software to meet their exact needs and that it may very well be more cost effective to redesign a process, provide additional training and to support for an existing piece of software than to maintain a locally modified set of changes over time.

The question was really a red herring. It is probably rare that any software will exactly meet all needs of any group. As users of software, we can be very passive in the way we consume it or active in a user community that vets new feature requests and bug fixes. If your chosen vendor isn't supplying the community of users with the features and support it demands you may want to rethink your choice of solution providers.

The vendors of proprietary software may have the opportunity to string along the user community a little more, because (in the short term) they hold all of the cards. You've hitched a ride on their star and they can make a short term bet that you aren't going to leap off any time soon. They provide the software, the support and (in some cases) even hold your data hostage. With open source software you typically have more options, in both the short and long term. You can make local changes to your code to get a high priority feature/fix implemented locally, contribute that fix back to the community and shepherd its incorporation into the next release. You can also shop around for a different (more responsive) support provider.

We, the consumers of IT products and services, have been acclimated to a "like it or lump it" approach to software for a very long time. Most IT shops are very concerned about picking the right product from the start because of the high costs of switching products down the road. Migrating data and retraining staff are very costly endeavors. So high, in fact, that vendors really have quite the upper hand on the consumer. The pain point would need to be very high to make them switch and incur that cost.

The decoupling of the software and the services around it allow for a game changing mindset. What if we could keep our current system but buy better support and the option to directly address our specific pain points in the software? What if we could get those enhancements included as part of the next release of the software? Wouldn't that be less expensive than the cost of switching (migration and retraining)? Wouldn't the users of our systems be more satisfied with a slow and steady stream of improvements to an existing system than with the calamity of swapping of systems? Which is a better way to manage change in your organization?  

I don't think I'll get that contract, for other reasons, but I enjoyed the conversation.