The Hidden Costs of Free Help Desk Software

Thursday, 08:50, at Tollgate Foods. Priya leads a desk of three, and the first message of the day is from the warehouse: "The IT portal says the connection isn't private, is it safe?" It is not unsafe, exactly. The certificate that proves the portal is the portal expired at midnight. Nobody on the desk knew there was a certificate, because Owen set it up, Owen renewed it every spring, and Owen left in March. The ticketing tool itself is open source and has never cost Tollgate a penny. By 09:30 Priya has learned that it runs on a server she had never logged into. She has learned that the renewal is a script in Owen's old home folder, and that the script needs a password only Owen knew. "But it's free," says Rob from finance, when she mentions it at the coffee machine, "so what's the problem?" The problem is that it is free the way a puppy is free.

The total cost of ownership of a tool is everything the organisation spends to run it over its life, money and hours together. A hidden cost is a part of that total which was real on the day you chose the tool and visible only later. Open-source ticketing tools have no licence fee, and the sentence usually stops there. The costs this article is about are the ones after the full stop: the server, the upgrades, the patches, the person, the plugins and the project itself. This article is part of our Open Source vs Commercial Helpdesk Tools series, and it is about counting them before they count you.

It covers why free means no invoice rather than no cost, then hosting, which is the server underneath the tool. Next come upgrades, each of which is a small project, and security patches and the clock you cannot see. Then it covers the one person who knows how it works, plugins and customisations that break, and the project that goes quiet. Counting it honestly, with a table of ranges, comes next, followed by when these costs are worth paying anyway. A short war story and the hidden-cost worksheet to copy finish the article.

Free Means No Invoice, Not No Cost

An open-source tool removes one line from the budget and leaves every other line in place. The licence row reads zero, and that zero is real and worth having. But the tool still needs a machine to run on, someone to install it, someone to keep it current, someone to notice when it breaks and someone to know why. Every one of those is a cost the organisation pays in hours, and hours are the one thing a three-person desk cannot buy more of at renewal time. The invoice for a free tool is paid in the currency the desk is shortest of.

The costs hide because they are spread out and nobody adds them up. Forty minutes reading release notes in one week, two hours applying an update in another, a Saturday morning when the update went wrong, a lunchtime spent on a forum: none of these appears on any report. Each one is small enough that the person doing it does not mention it. Add them for a year and you have a figure that would have caused a meeting if it had arrived as a quote. The person who does the adding is usually the one who inherits the system, which is why the sum is always discovered by the wrong person at the wrong time.

None of this is an argument against open source, and it is worth saying so plainly at the start. It is an argument for putting the hours on the same page as the zero, which is what the trade-off table in the first article of this series does. A desk that knows it is spending four working weeks a year on its ticketing tool, and has decided that is a fair exchange for the control it gets, has made a decision. A desk that is spending four weeks and believes it is spending none has made a discovery it has not had yet.

Hosting: The Server Underneath the Tool

A self-hosted tool needs a server, and the server is a job in itself. It may be a physical box in a cupboard or a virtual machine on a host you already run. Either way it has an operating system that needs patching, a disk that fills, and a database engine with its own updates. It has a web server in front of the application, and a certificate that proves the portal is genuine and expires on a schedule nobody wrote down. Each of those is a thing that works silently until it does not. Owen's certificate worked silently for three years.

Backups are the hosting cost most often skipped and most expensive to skip. The tool's database holds every ticket your organisation has raised, every reply, every internal note and, for many tools, every attachment. A backup that has never been restored is a hope rather than a backup. Budget the hours to take it, the hours to test a restore once or twice a year, and the storage to keep it somewhere other than the server it protects. If the tool also keeps attachments on disk rather than in the database, the backup has two parts, and the second one is the part people forget. Ask, on the day you install it, where the attachments go. The answer is rarely where you assumed.

This line does not disappear when a licence appears. A self-hosted commercial tool sits on a server too. If you run QuerySolv, the Windows server underneath it is yours to patch, back up and keep room on exactly as it would be under an open-source tool. So the hosting line stays on the sheet and simply stops being the only line. The one category that removes hosting entirely is the cloud help desk, and it removes it by charging you for it every month. There is no fourth option in which the server looks after itself.

Upgrades: Every Release Is a Small Project

Each new version of the tool is a small project with the same five steps. Read what changed, take a backup, test the upgrade somewhere that is not production, apply it, and fix whatever it broke. For a minor release the five steps take an hour or two. For a major release, the kind that changes the database layout or the look of every screen, they take a day or a weekend. They take it from the person on the desk most able to do them, who is also the person most needed on the queue. The upgrade never arrives in a quiet week. There are no quiet weeks; there are only weeks in which the quiet has not been interrupted yet.

Skipping upgrades does not save the time; it borrows it at interest. A tool two versions behind can usually be brought current in one step. A tool six versions behind often cannot, because the upgrade path assumes you passed through the versions in between. Each of those had its own database change and its own list of things that stopped working. The three-version jump that Kieran faced in the first article of this series is the normal shape of a deferred upgrade. A small job postponed four times becomes a large job that cannot be postponed at all. Treat each upgrade as a change with a date, a backup and a rollback. That is the same lightweight discipline the desk applies to any other change to a shared system. Do them while they are still small.

Count the upgrade hours by the year, not by the release. A healthy project ships several minor releases and roughly one major one a year. The honest range for a small desk, including the testing and the fixing afterwards, is somewhere between a long day and a working week annually. Write down which end of that range you are at after the first year. It is nearly always the far end.

Security Patches: The Clock You Cannot See

A security advisory is a published notice that a piece of software has a flaw someone could exploit, usually with a fix attached. From the moment the advisory is published a clock starts that you cannot see. People who attack systems read advisories too, and a ticketing portal that faces the internet so that staff can raise tickets from home is exactly the kind of thing they look for. The portal holds every colleague's name and e-mail address, every conversation about a locked account, and every screenshot a requester attached without thinking about what else was on their screen. It is not a glamorous target. It does not need to be.

The hidden cost here is attention rather than hours. Somebody has to be subscribed to the project's security announcements, read them when they arrive, judge whether they apply, and schedule the patch within days rather than at the next planned upgrade. With a commercial tool the vendor does the first two steps and often the third. With an open-source tool all of them are yours, and the one that gets dropped is the first. Subscribing to an announcement list is the sort of task that is nobody's job on a three-person desk. The patch itself is usually quick. The advisory nobody read is the expensive part, and its cost arrives as an incident rather than an invoice.

The tool is not the only thing that needs patching, either. The operating system, the database engine, the web server and the language runtime the tool is written in each publish their own advisories, each on their own schedule. Each is a line on the worksheet. A desk that patches the ticketing tool faithfully and never touches the database engine beneath it has locked the front door and left the window open. That is the kind of security the review afterwards describes as "partial".

The One Person Who Knows How It Works

Every self-hosted tool accumulates knowledge that lives in one head, and on a small desk that head belongs to whoever installed it. They know which folder the configuration is in, why the mail connector needs that odd setting, what the cron job at 02:00 does, and which of the three admin accounts is the real one. None of this is written down, because writing it down was never urgent, and the person who knows it never needed to read it. The industry calls this the bus factor: the number of people who would have to be hit by a bus before nobody could run the system. On most small desks running an open-source tool, the number is one, and the bus is usually a better job offer.

The cost appears when that person leaves, and it appears all at once. The successor has to learn, from the system itself, how the system was built, which is archaeology rather than administration. It means reading configuration files to work out what they do, finding scripts in home folders, and guessing at passwords. It means discovering a backup job that has not run since the leaver's account was disabled because it ran under that account. The thirty, sixty or ninety hours this takes are the deferred cost of every hour the installer did not spend documenting. They are paid by someone who has a queue to run at the same time. The licence was free. The knowledge was not, and nobody had bought it.

The fix is cheap and dull: a runbook for the tool, written by the person who knows it, while they still work there. One page says where it runs, how it starts and stops, and where the configuration and the data live. It says how the backup works and how to prove it, how upgrades are done, and what the mail connector needs. It says where the passwords are kept, which must not be the runbook. The shape of such a document is in Writing the Runbook, and the argument that documentation is a second person on a small desk is in Documentation as Your Second Person. Budget the hours to write it and the hours each quarter to keep it true. They are the cheapest hours on the worksheet.

Plugins and Customisations That Break

A plugin is a piece of software, usually written by someone other than the tool's maintainers, that adds a feature the core tool does not have. That might be a custom report, a connection to your directory, a different form for one department, a timer that does something clever. Open-source tools often have a rich supply of them, and that supply is one of the genuine attractions of the category, because the feature you need is frequently one download away. The hidden cost is that every plugin has its own maintainer, its own release schedule and its own idea of which versions of the core tool it works with. None of those things is under your control.

Each upgrade of the core tool is therefore also a test of every plugin, and each plugin is a chance for the upgrade to fail. A plugin whose maintainer has moved on will work until the first core release that changes what it depended on. Then it will stop. Your choices are to find a replacement, fix it yourself, or hold the core tool back on an old version to keep it alive. That last choice is how the deferred-upgrade spiral in the previous section begins. The returns form at Meridian Parts in the first article of this series was a plugin. Plugins are the easiest part of a free tool to acquire and the hardest to give back.

Customisations are plugins you wrote yourself, and they cost the same with one difference: nobody else will ever fix them. Examples include a tweak to a template or a field added by editing a file rather than through the settings. Another is a script that reads the database directly to produce the Monday report. Each works until an upgrade moves the thing it touched, and each is undocumented unless somebody made it a habit to document it. Keep a list. Every customisation on the list is a line on the upgrade test plan, and every one not on the list is a surprise with a date you do not know yet.

The Project That Goes Quiet

An open-source project is maintained by people, and people stop. The signs are gradual: releases become less frequent, then stop. Questions on the issue tracker go unanswered for weeks, then months. The documentation starts to describe a version you are no longer on. A security advisory is published by someone outside the project and no fix follows. There is rarely an announcement. A project does not close the way a company does; it goes quiet, and the quiet is only obvious in hindsight, which is when it is also most expensive.

The cost of a quiet project is that every other line on this worksheet gets larger at once. Upgrades stop arriving, so the dependencies underneath the tool age out with no path forward. Security patches stop, so each new advisory against the runtime or the database is a problem you solve alone. The community thins, so the forum that answered your question last year is now a list of unanswered ones. And the plugins, whose maintainers were often the first to leave, break with no replacement. Sometimes a fork appears, which is a copy of the project continued by new maintainers under a new name, and sometimes it is a good one. Moving to it is a migration with all the costs of any other.

Watch the project's health the way you watch a supplier's: a few minutes each quarter, with a note on the worksheet. When did the last release ship? Are issues being answered? How many people are committing changes? Is there a published way to report a security problem and does anyone respond to it? None of these is a verdict, and a project can be quiet for a season and come back. But a project that has failed all four checks for a year is telling you something, and the something is that the migration you are not planning has already started. What that looks like from the inside, and when to act on it, is the subject of When Free Is Expensive.

Counting It Honestly

Put each hidden cost on its own line in hours per year, with a low and a high, and resist the urge to pick a single flattering number. The table below is a worked example for a fictional three-person desk running a healthy open-source tool with a couple of plugins. The ranges are deliberately wide because the honest answer depends on how good the project is, how many plugins you have, and how often things go wrong. Your first year will tell you which end you live at. Write that down too.

Then convert. Multiply the total by the desk's loaded hourly rate, which finance can give you. You have the yearly cost of the free tool in the same money a commercial quote arrives in. Or leave it in hours and convert the quotes the other way, which is what the picture in the first article of this series does. Either direction works. What does not work is comparing a zero on one side with a number on the other, which is the comparison most desks make. It has the useful property of always coming out the same way. The method for valuing a technician's hour without flattering yourself is in The Time Saved by Technicians, and it applies here unchanged.

When These Costs Are Worth Paying

There are desks for which every line above is a fair price, and the honest version of this article says so. A desk with an administrator who already runs servers, enjoys it, and has hours in the week set aside for the tool is paying in a currency it has. An organisation that needs the data on its own premises for regulatory reasons and has no budget for a licence has few other choices. A desk that needs to change how the tool works, not just configure it, can only do that with the source code in hand. And a team that treats the ticketing tool as one more system it runs, with a runbook, a patch schedule and a backup test, will find the hours in the table are real but predictable. Predictable hours are a budget rather than a hidden cost.

The costs are hidden only when nobody is looking for them. A desk that fills in the worksheet below in the first month, keeps it current, and decides each year with the numbers in front of it has made open source a choice rather than an accident. The desks that get hurt are the ones where the tool was installed by someone who has since left, is run by nobody in particular, and is believed to be free because no invoice has ever arrived. The invoice is in the worksheet. It always was.

A Short War Story: The Expired Certificate at Tollgate Foods

Owen had installed Tollgate Foods' open-source ticketing tool on a spare virtual machine and kept it current for three years. He renewed its certificate every spring from a script in his own home folder. When he left in March nobody thought to ask about any of it. The tool had never appeared on a budget and so had never appeared on a handover list either. The certificate expired in June, and the portal began warning every visitor that it was not private. Within a fortnight the warehouse had stopped using it and was e-mailing Priya directly, which doubled her inbox and halved the number of tickets anyone could see. Priya spent roughly thirty hours over the following month learning how the system was built, mostly by reading files and guessing. She discovered in the process that the nightly backup had run under Owen's account. It had therefore not run since the day his account was disabled. The desk had ten weeks of tickets that existed in exactly one place. Nothing was lost in the end. The certificate was renewed, the backup was moved to a service account, and Priya wrote the runbook Owen never had time for. The tool had cost Tollgate nothing for three years. Then it had cost thirty hours, ten weeks of unprotected history and a fortnight of the warehouse's trust, all in one month. That was because the only thing anyone had ever been asked about it was its price.

The Hidden-Cost Worksheet

Fill this in during the first month, keep it in the same place as the tool's runbook, and read it once a quarter. Every line has a name, because a cost with no name attached is a cost nobody is paying until it is paid all at once. Where the answer to "who" is the same name on every line, that is the finding; write it in the last box.

THE HIDDEN-COST WORKSHEET — ONE FREE TOOL, ONE PAGE
Tool: ______________   Runs on: ______________   Filled in: ________  by: ________
Loaded hourly rate used: ______

Line                      Who          Hours/yr   Last done   Next due   If nobody does it
Server OS patches         __________   ______     ________    ________   ______________
Database engine updates   __________   ______     ________    ________   ______________
Certificate renewal       __________   ______     ________    ________   ______________
Disk space and growth     __________   ______     ________    ________   ______________
Backup runs and checks    __________   ______     ________    ________   ______________
Restore test              __________   ______     ________    ________   ______________
Minor upgrades            __________   ______     ________    ________   ______________
Major upgrade             __________   ______     ________    ________   ______________
Security advisories read  __________   ______     ________    ________   ______________
Plugin re-tests           __________   ______     ________    ________   ______________
Customisation list kept   __________   ______     ________    ________   ______________
Runbook kept true         __________   ______     ________    ________   ______________
Project health check      __________   ______     ________    ________   ______________

Total hours per year      ______      Converted at the rate above: ______

Plugins in use:           ______________________________________________
Customisations in use:    ______________________________________________
Passwords are kept in:    ______________  (not on this sheet)

Names appearing on more than three lines: ______________
What happens to those lines if that person leaves: ______________________
Next review of this sheet: ________

Priya's version of this sheet had Owen's name on eleven of thirteen lines, written in after the fact. The last box said "we find out the hard way", which was true and had already happened. The second version, a quarter later, had three names and a service account. The licence row still said zero. For the first time, it was the only row that did.

Frequently Asked Questions