Chan’s post of a few days ago got me thinking again about the topic of “free software”. I’ve been meaning to write on this for quite some time, but my recent employment gig put that on ice (given the “for free” orientation of said employer). Now that I’m solo again, I’m able to write up my thoughts on this.

First up, one of the things I remember from my management of IT training at University back in the day is that the upfront software and hardware acquisition cost of a business solution is generally around 20% of the lifecycle cost of any solution (that’s general knowledge, right?). So if we do the math on that (and remember, there’s three types of people in the world: those that can count, and those that can’t), then 80% of the cost of the solution is post-acquisition. It includes future maintenance payments, hardware upgrades, data backup and recovery, training, and more. So if you adopt a “free” software package on the Internet, you are saving a portion of that 20%, and potentially some of the 80%. But there’s still a big chunk that will be spent by you into the future on non-software acquisition costs.

Secondly, even if you can rationalize your other lifecycle costs (“well, I’ll have to buy new computers anyway, and there’s no software maintenance costs going forward because it’s free“), you still have to deal with the issue of solution lock-in. Once you’ve adopted a “free” solution on the Internet, and let’s say in the best case that your people embrace it perfectly and make it a part of their daily work and collaboration rhythm, you are in-practice and in-habit locked to that provider. If what you adopted on day one fits your requirements, but then starts to diverge in intent over time as the vendor matures as a vendor and as a provider of services, then you increasingly have a problem. You have a situation where the offering you embraced to solve a task-related issue on day one is now no longer a good fit to the current requirements of your task, but you have such an embedness of data and embedness of habit that you can’t easily or freely shift away. And if it’s a “free” solution on the Internet, the services provider isn’t going to be happy about maintaining multiple instances to serve “legacy” customers.

On reflection, the same argument can definitely be made in terms of commercial software products. For those organizations that have embraced Notes and Domino in days gone by, or Microsoft Office for that matter, the biggest challenge they now face is the corpus of data across multiple repositories that are tied to that commercial software. It’s difficult to move away if you and your people embed the usage of that software into daily work rhythms. As soon as you move away from clean and pure open document formats and database structures, you start to become dependent on vendors. So … in conclusion … that’s true of any vendor … just make sure that you choose wisely when deciding which vendors to become dependent on. Don’t unnecessarily ransom your future for the small price of “free” today.

Problem three with “free” software is personage lock in. When one person in IT finds a “free” solution and becomes the in-house expert, the organization becomes locked-to and dependent on that person. That person has deep internal knowledge about how the system is configured, and is very likely not to have documented it for others. This person in IT can then hold the business to ransom for the knowledge they have internalized. If the population of geeks who can handle that “free” package is limited, then the organization is between a rock and a hard place. I would much rather see organizational leaders intentionally direct IT to embrace commercially available tools that cost real dollars, but for which a large population of possible employees, outside vendors and consultants is available, rather than being held ransom to one person. If you get stuck with a non-performing IT person who is costing you $80-$100K a year and you can’t easily get rid of them because of their knowledge of a “free” software package, that’s quite a steep cost.

I think this discussion leaves us with two rules of software acquisition, or at least two factors that you absolutely need to ensure you figure out before acquiring a free or for-fee product. This analysis should become standard practice of every software business case, and no acquisition or implementation should get the go-ahead until it’s signed off and approved by senior management.

1. What’s the Exit Cost, and What Factors Increase Exit Cost? … What is the dollar financial figure that is involved in extricating yourself from the said “free” or “for fee” product or service you are looking at? This should include data extraction, data migration, re-training of administrators and staff, re-integration with other business tools, new software acquisition and implementation, and more. An extension to this initial analysis is an examination of what factors increase or decrease exit costs. In the Notes and Domino case (and going forward, for SharePoint too), for example, the development of inhouse, customized applications increases exit cost. If your IT people can’t answer this question, don’t proceed.
2. What’s the Population Count of Trained Professionals Available to Help? … How many people–either as potential employees with said skills, external vendors or independent consultants–are available to help with the product you are looking at putting in? Are the skills widely and generally available in your localities, or do only a few on the fringe “get it”? In general, the higher the population count, the less risk there is to the business. One way to check out the potential size of the population is to look through online job listings in your specific geography; if lots of organizations are seeking the type of people you are seeking, that’s a good sign that there’s lots of people around. Another way is to speak with recruitment agencies, and ask how many people with said skills they’ve placed into full-time positions in recent months. For vendors and external consultants, look into the range of business partners available for the vendors you are considering. The higher the number the better. The vendor will also have different levels of business partners to help organizations ascertain quality levels, but you’ll have to investigate that yourself too. Eg, a business partner may have the highest partner rating but only send along junior staff. Not good.

Michael’s Recommendation
By all means try out free software … for the purposes of building conceptual understanding, and for floating various paradigms and ideas with people in your organization. And by all means if the exit cost is manageable and you have ways of mitigating the risk around people availability, roll it out more widely. But don’t for a moment even think that it’s free. That’s utterly … wrong..

Chan has a similar conclusion:

In reality you would look at how much it would cost to a typical IT department to support one of these *free* applications? I always laugh when someone mentions *free*. Software quite simply is NOT free. You can shoot me yourself or hire a hit man. If you happen to make *free* software and want to change my opinion let me know. I’ll buy you a *free* coffee.

I’ll take that *free* coffee when I’m in Wellington next Chan … but in the meantime, anyone else got a view on this? Any horror stories?