When Free Is Expensive: Four Stories and the Warning Signs

Wednesday, 17:40, at Redbrook Engineering. Sam is the IT department, with Jess three days a week. The two of them run a desk that handles everything from the drawing-office plotter to the badge readers on the yard gate. Their ticketing tool is open source, chosen by Sam four years ago because it was free. The budget that year was a sentence from the managing director that began "we can't". The tool has been a good one. Tonight Sam is reading a security advisory about it that was published in the spring. He had bookmarked it to deal with "after the audit". He is reading it again now because the company's insurer has just sent the results of an external scan. The portal's address is on the first page. The tool has still not cost Redbrook a penny. Sam has the distinct feeling that is about to change.

A free ticketing tool is expensive when the hours it needs cost more than the licence it saved. That happens in four recognisable situations rather than at random. It happens when the team has no time to run it, or when the project behind it stops being maintained. It happens when a security patch is published and nobody applies it. And it happens when the desk eventually has to leave it with no help from anyone. Each situation has early signs, and the signs are the useful part. This article is part of our Open Source vs Commercial Helpdesk Tools series. It is the companion to The Hidden Costs of Free, which lists the costs. This one is about when they come due.

It covers why free is a bill paid in hours you may not have, then the four situations in turn. We start with the small team with no time and the unmaintained project. Next come the security patch nobody applied and the migration two years later. We cover the arithmetic for a desk of two, with a table, then when free is genuinely cheap, which is often. We finish with a short war story, the warning signs list to copy, and what to do when you see three of them, in that order.

Free Is a Bill Paid in Hours You May Not Have

The cost of a free tool is paid in the hours of whoever runs it, and the bill is only affordable if those hours exist. A desk with a capable administrator who has half a day a week set aside for systems work can pay it comfortably, year after year. And the previous article's worksheet is simply that administrator's budget. A desk of two with a queue that fills every morning has no half-day. The hours still have to come from somewhere, so they come from evenings, from the queue, or from not being spent at all. The third option is the one that turns a free tool into an expensive one. Work on a ticketing system does not disappear when it is skipped. It accrues.

Expensive, here, has a precise meaning. Convert the hours the tool needs to money at the desk's loaded rate, as the trade-off table in the first article of this series does. Compare the result with the licence the free tool replaced. When the hours cost more than the licence would have, the tool is expensive in the plain sense. Sometimes the hours are not spent and the consequences arrive instead, as an outage, a breach or an unplanned migration. Then the tool is expensive in the sense that gets you a meeting with the managing director. Both are arithmetic. Only one of them is scheduled.

Situation One: The Small Team With No Time

The small team with no time is the commonest of the four situations and the only one that is visible on day one. The desk has one or two people, and the queue takes the whole day. And the tool was chosen because its licence fee was zero and its installer was friendly. Everything in the hidden-cost worksheet, the patches, the upgrades, the backup test, the runbook, is assigned to the same person. That person is also assigned to the queue. The queue wins every time because it has people in it asking "any update?" and the upgrade has nobody. This is not a failure of discipline. It is a timetable with more entries than hours.

The sign is the phrase "in a quiet week". A quiet week is a unit of time in which a small desk plans to do the systems work it cannot do in a normal week. Small desks do not have them, because the quiet in a quiet week is immediately filled by the work that was waiting for one. When Sam says the upgrade will happen in a quiet week, he is being sincere and describing a week that does not exist. Listen for it in your own desk. The number of tasks waiting for a quiet week is the size of the bill.

What makes this situation expensive is that the unspent hours do not vanish; they convert. Three skipped minor upgrades become one major one that takes a weekend. Two years without a restore test becomes a backup that has never been proved and a Monday morning when it matters. The runbook never written becomes the thirty hours of archaeology for whoever comes next. A desk with no time to run a free tool is borrowing from its future self at a rate nobody has written down. And the boundaries a solo administrator needs in order to protect that time are the subject of Boundaries for the Solo Admin. If the boundary cannot be held, the tool is in the wrong category.

Situation Two: The Unmaintained Project

An unmaintained project is an open-source tool whose maintainers have stopped working on it. And it is expensive because the work they stopped doing becomes yours. While a project is healthy, somebody else is fixing bugs and publishing security fixes. They are keeping the tool compatible with new versions of the database and the language it is written in. They are answering questions on the issue tracker. When they stop, every one of those jobs is still required and nobody is doing it. A free tool with an active project is free software with a volunteer department behind it. A free tool with a dead project is free software with nobody behind it. And the price difference between those two is the volunteer department.

The signs arrive in order. Releases slow, then stop. Issues go unanswered, then the tracker is closed to new issues. The documentation describes a version two behind the one you run. Then the dependencies move on. The operating system you run drops the version of the language runtime the tool needs. Or the database engine's supported versions no longer include the one the tool was written for. Now you are holding back the whole server's patching to keep one application alive. That last sign is the expensive one. It is the moment a free ticketing tool starts costing you the security of everything else on the machine.

Sometimes a fork appears, a copy of the project taken up by new maintainers under a new name, and sometimes it is excellent. Moving to it is still a migration, with a test, a backup, a cutover and a plugin that does not come along. Sometimes nothing appears, and the desk is left to patch a tool it did not write. That means patching in a language nobody on the desk reads, against advisories nobody on the project will ever answer. Check the project's pulse once a quarter, as the previous article suggests, and write the date of the last release on the warning-signs list. A project that has not shipped in a year is not necessarily dead. It is, however, not necessarily alive, and your desk is not the right place to find out which.

Situation Three: The Security Patch Nobody Applied

A security patch not applied is the situation in which a free tool becomes most expensive fastest, because the cost does not arrive as hours at all. A security advisory is a published notice that the tool has a flaw someone could exploit, usually with a fixed version attached. From the day it is published everyone who reads advisories knows the flaw exists. That includes people whose interest in your ticketing portal is not raising tickets. A help desk portal that faces the internet so that staff can raise tickets from home holds every colleague's name and e-mail address. It holds every conversation about an account that was locked out. It also holds every screenshot a requester pasted in without looking at what else was on the screen. It is not a glamorous target, and it does not need to be.

The patch itself is usually quick. What is expensive is the gap between the advisory and the patch. On a small desk running a free tool that gap is made of three things. Nobody is subscribed to the project's security announcements, because that was never anyone's job. The person who does see the advisory bookmarks it for a quiet week. The patch, when it is finally attempted, turns out to require the upgrade that was also waiting for a quiet week. So a ten-minute fix becomes a weekend. Sam's bookmark had been there since the spring. The insurer's scan took about four minutes.

Treat a security patch as an emergency change, a change made outside the normal schedule because waiting is the greater risk. Use the short record and the quick review that Emergency Changes describes. And give the reading of advisories a name and a calendar entry rather than hoping. Moving to a commercial tool shifts the first part of this work to the vendor, who reads, judges and publishes the fix. With a self-hosted tool such as QuerySolv the fix is still applied to your own Windows server by you. So the hours shrink but the calendar entry stays. With a cloud tool the vendor applies it too. What no category removes is the operating system and the database underneath, which publish their own advisories and wait for nobody's quiet week.

Situation Four: The Migration Two Years Later

Every desk eventually leaves its ticketing tool, and leaving a free one you chose in a hurry is expensive in a particular way: nobody is obliged to help. A commercial vendor has an export, a support line and at least a commercial interest in you leaving quietly. An open-source project, especially one that has gone quiet, has a database and whatever you can get out of it. Consider the tickets, the notes, the attachments stored in a folder structure only the tool understands, and the four years of history that the auditors now want. All of it is reachable, because the server is yours. None of it comes out in a form the next tool reads without somebody writing the thing that makes it do so.

The cost is hours again, and they are the most expensive hours in this article. They are spent under pressure, by the person least able to spare them, on a system nobody wants to touch any longer than necessary. A migration from a well-run free tool, with a documented database and a runbook, is a project like any other. A migration from a free tool run on borrowed evenings, with undocumented customisations and a plugin that held the returns data in its own tables, is a dig. And the reasons such digs go wrong, nearly all of them to do with what was never written down, are set out in Why Migrations Go Wrong. The free tool did not cause the dig. The two years of no time did.

The protective habit is cheap: once a year, export everything the tool will give you to a plain format. Open it and check that a ticket from last March is in it with its notes and that an attachment can be found. If the export needs a script, write the script now, while the project is alive and the person who understands the tables still works here. An hour a year buys the one thing a dead project cannot sell you later, which is a way out. Tools you can leave are the only tools worth staying in.

The Arithmetic of a Desk of Two

Put the two sides on one page in the same unit and the four situations stop being stories and become a sum. The table below is a worked example for Redbrook's desk of one and a half people. It sets the hours the free tool needs against the hours a modest commercial licence would represent at the desk's loaded rate. The hours are the ranges from the hidden-cost worksheet. The licence equivalent is invented for the example and should be replaced by a quote divided by your own rate. The point of the table is the last column, not the totals.

Read the table as a question rather than an answer. If Redbrook's desk can genuinely spend sixty to a hundred hours a year on the tool, the free option costs less than the example licence. In that case, the hours buy control the licence does not. If the desk can spend twenty, the free tool is being run at the bottom of its range by skipping things. In that case, the right-hand column is a list of the invoices on their way. The commercial licence in the example is not cheap. It is a hundred and forty hours of someone's time, which is why a desk that has the hours should think hard before paying it. The question the table asks is only ever "do the hours exist". And a desk of two should answer it honestly, because the tool will.

When Free Is Genuinely Cheap

Fairness requires saying that none of the four situations is inevitable, and that for many desks free is exactly what it says. A desk with an administrator who runs other servers already, enjoys it, and has the hours ring-fenced is in none of the four situations. A healthy project with regular releases, several maintainers and a published security policy is not situation two and, if the desk reads its announcements, not situation three either. A desk that exports once a year and keeps a runbook has defused situation four before it can arise. For such a desk the hours in the table are a budget, the control is real, and the licence money is genuinely saved. The honest-opinion answer is that the desk should choose the free tool and stop reading articles like this one.

The difference between that desk and Redbrook's is not the tool. It is the same tool. The difference is whether the hours exist, whether anyone is watching the project, whether advisories have a reader, and whether the exit has been tried. And those four things can be checked in an afternoon before the decision is made. Free is cheap for the desk that can afford it. That sentence sounds like a joke, and I would prefer it were not the most accurate one in the article.

A Short War Story: The Advisory at Redbrook Engineering

The advisory Sam had bookmarked in the spring described a flaw in the version of the ticketing tool Redbrook was running. The fix was in a release three versions ahead of it. He had deferred both the patch and the upgrade until after the annual audit, which ran long. Then he deferred them until a quiet week, which did not come. In the autumn the company's insurer ran a routine external scan as a condition of renewing the policy. It identified the portal's version from its login page. The insurer gave Redbrook fourteen days to show the flaw was fixed and that nothing had been taken, or to accept a change in terms. Sam spent a weekend bringing the tool forward three versions. During that weekend, the yard-gate plugin stopped working and had to be replaced with a shared mailbox. The managing director paid an outside consultant for two days to confirm that the portal had not been compromised. As far as anyone could tell, it had not. The free tool had cost Redbrook about forty hours of Sam's time, two days of a consultant's, and a conversation with the insurer that nobody enjoyed. All of that was in one fortnight, for a patch that had been available for five months and would have taken an hour. The lesson Sam wrote on the whiteboard was short: an advisory is not read until it is on somebody's calendar, and a quiet week is not a date.

The Warning Signs List

Run this list once a quarter, honestly, in ten minutes. Each line is a yes or a no. The lines are grouped by the situation they belong to. The rule is at the bottom: three or more ticks, from any groups, means the free tool is in its expensive phase. The desk should then act, whether that means fixing the signs or changing the tool.

• At least one systems task for the tool has been waiting for "a quiet week" for more than a month.
• Nobody on the desk has a recurring calendar entry for upgrades, patches or backup checks.
• The person who installed the tool has left, or is the only person who could upgrade it.
• The tool is more than two releases behind the current one.
• The project has not shipped a release in the last year.
• Questions on the project's issue tracker are going unanswered for months.
• The operating system or database engine under the tool is being held back to keep the tool working.
• Nobody on the desk is subscribed to the project's security announcements.
• A published security advisory applies to the version you run and has not been patched.
• The portal is reachable from the internet and its login page shows the version number.
• The backup has never been restored to prove it works.
• There is no runbook for the tool, or it describes a version you no longer run.
• At least one plugin or customisation exists that nobody can explain or test.
• No full export has been taken and opened in the last year.
• Nobody knows how long it would take to move the tickets to another tool.

Three or more is the threshold, and the count matters more than which three. One sign is a task. Two is a pattern. Three is a tool that is costing more than it saves. The arithmetic in the table above is how to show that to whoever controls the budget without raising your voice.

What to Do When You See Three

First, decide whether the signs can be fixed in the category you are in. If the desk can find the hours, ring-fence them, and the project is alive, then fix the signs. In that case, schedule the upgrade, subscribe to the announcements, test the restore, write the runbook, and take the export. That is the cheapest outcome, and it is available to any desk that genuinely has the time. Write down how many hours it took. That number is the honest cost of the free tool, and it goes on next year's worksheet.

If the hours cannot be found, or the project is quiet, the signs are not a to-do list. They are then a decision about category. The decision frame for a small team, including the exit plan either way, is in Deciding for a Small Team. Before anything else, take the export and patch what is patchable, because a migration is a project measured in months and the advisory is measured in days. Then plan the move with the time it deserves, rather than in the fortnight an insurer gives you. Redbrook moved the following spring, calmly, from a tool that had been fixed to one that fitted. The weekend in the autumn was the price of learning the difference. And it was, by some distance, the most expensive thing the free tool ever cost them.

Frequently Asked Questions