The Hidden Costs on Both Sides

The slide had one number on it, and the number was zero. "License cost," it said, and the room relaxed, because zero is a number nobody has to defend. Three slides later a rival proposal showed an invoice, and the room tensed. An invoice is a number everybody argues with. Neither number was the cost. I have watched that pair of slides decide the wrong thing more than once. Each side of the argument has a visible cost that works as a decoy.

A hidden cost is one paid in a form nobody tracks. Open source shows a license cost of zero, which invites everyone to stop counting. The real costs are integration hours and the features you end up writing. Commercial software shows an invoice, which invites everyone to count that and nothing else. The real costs are license growth, lock-in, and upgrades. This article, part of our Open Source vs Commercial series, puts both sets on one ledger with a method for filling it in fairly. That method counts an engineer's afternoon as honestly as a renewal invoice.

Two notes before the ledger. We sell commercial transfer software, so we have an obvious interest in how this comes out. We have tried to hold to a discipline: every commercial hidden cost gets the same rigor as every open source one. That way, the method would produce an answer we did not like as readily as one we did. And the adjacent question, your own scripts versus a dedicated tool, lives in the hidden costs of homegrown transfer. This article assumes you are choosing between tools other people wrote.

Why Costs Hide, and Why They Hide Differently on Each Side

On the open source side, the hiding place is hours inside salaried time. The engineer who spends an afternoon wiring the server's logs into the collector generates no invoice. The afternoon disappears into a week that was going to be paid for anyway. Multiply by every small integration, every release note, every account created by hand, and a real cost accumulates that appears on no report. Salaried hours are the perfect hiding place. Nobody audits an afternoon.

On the commercial side, the hiding place is the future. The first-year invoice is visible and negotiated. What is not visible at purchase is the renewal in year three and the extra licenses when the partner count doubles. Nor is the upgrade that turns into a two-week project, or the cost of leaving when the vendor's direction and yours diverge. These are paid in lumps, later, often by a different budget than the one that approved the purchase. That is a polite way of saying by somebody else.

The Open Source Side of the Ledger

These are the costs the "it's free" framing skips. A team that runs open source tooling well pays them knowingly. A team that runs it badly pays them anyway, in surprise.

• Integration labor. An open transfer server does its one job superbly and leaves the connections to you. Those include authentication against the business directory and logs into the collector security watches. They also include alerts into the on-call system and account creation tied to onboarding. Collectively they are an unbudgeted product someone builds one afternoon at a time.
• Upgrades and behavior changes. Routine patches arrive with the operating system and are cheap. What is not cheap is attention. A release that retires an old key algorithm or tightens a default can break a partner who has not updated in years. The only warning is a release note somebody had to read. The cost per event is small; the cost of the vigilance is steady.
• The features you end up building. Nobody sets out to write an account self-service page, a notification emailer, a per-partner quota checker, or an audit report generator. They get written anyway, one urgent request at a time, because the open tool does not have them. What dedicated tools add lists what typically lands here.
• Evidence assembly. The raw logs contain everything an auditor could want and none of it in the form they want. Turning log lines into "every file this partner uploaded last quarter and who retrieved it" is work, repeated every audit. The article on evidence auditors accept shows the target.
• Knowledge concentration. A text-file configuration is transparent to anyone who reads it and opaque to anyone who does not. Because the surface is larger than a product's option screens, the person who understands it is a bigger single point of failure.

None of this argues against open source. It argues against calling it free. The case stands with these costs counted; it just stands on the right number.

The Commercial Side of the Ledger, Counted Just as Hard

These are the costs a vendor's quote does not show, including ours. Each deserves the same scrutiny as the items above, and in my experience gets less. An invoice feels like the whole answer.

• License growth. Commercial licensing is measured by something (servers, users, connections, sites), and the something usually grows with your success. Per-server licensing discourages the one-server-per-partner isolation security would prefer. Per-user licensing turns every new partner into a purchasing conversation. Edition ceilings add a ratchet: the feature you need next is in the tier above. The licensing article explains the models. The ledger prices your growth against the metric you are offered.
• Lock-in. Job definitions in a proprietary format, configuration in a proprietary store, history in a proprietary log, partner documents that describe product features rather than protocols. None of it costs anything until you leave, at which point all of it does. The honest way to price lock-in is to estimate the exit project on the day you buy.
• Vendor risk. Vendors get acquired, discontinue products, move perpetual licenses to subscriptions, let support slide, or turn toward a market you are not in. Each event lands on you as an unplanned project. Ongoing vendor monitoring reduces the surprise; it does not remove the cost.
• Upgrade projects. A major upgrade of a commercial transfer server is a project. It needs a test environment, partner regression tests, a change window, a rollback plan, sometimes a re-license. When the old version leaves support, the project becomes mandatory on the vendor's schedule rather than yours. The mechanics are in platform migration mechanics; the ledger needs the hours.
• The glue you still write. No product anticipates every flow. Pre-send validation, odd renaming rules, and the hand-off to the downstream application remain scripts you own. So "we bought it, we're done building" is always partly false.
• Procurement and governance overhead. Purchase approval, legal review, and the security questionnaire (see security questions for vendors) all consume hours. So do renewal handling and license true-ups. These are hours from people who never touch the server.

Two of these are routinely underestimated even by careful buyers. One is the upgrade project, because the version first installed feels permanent. The other is license growth, because the estate at purchase time is the smallest it will ever be.

Northgate Retail met the second one on a renewal notice. They had bought a partner-facing server licensed per account, with sixty partner accounts. The quote looked reasonable next to the hours the server saved. Three good trading years later there were two hundred and forty accounts. The renewal arrived at roughly four times the original. The finance director called it "a surprise" and the administrator called it something not suitable for a business case. Nobody had modeled growth. The product had done its job the whole time. The ledger had been filled in for an estate that no longer existed.

The Two-Column Ledger

The table below is the ledger itself: each cost category, and where it hides on each side. Some cells will be near zero for you; the point is that every row gets asked on both sides.

A Fair Accounting Method: Hours and Invoices on the Same Page

The ledger is only as fair as the rules used to fill it. These are the rules; each closes a specific way the comparison gets rigged.

1. Pick one horizon and use it for both columns. Three years is typical: long enough to include a renewal cycle, an upgrade, and the growth you actually expect. Total every cost on both sides over that horizon; do not annualize in a way that hides lumps.
2. Convert hours using your organization's loaded cost per hour, the number finance uses for a fully burdened engineer. Then hours and invoices become one unit. Do not use a bare salary figure; it undercounts the open source side.
3. Count only costs that differ. Negotiating formats with partners, cleaning bad source data, and owning the flow in audits happen under either option. Including them inflates whichever side you already favor.
4. Observe hours; do not recall them. If you already run an open source setup, log the hours for one quarter using the categories above. The homegrown ledger has the daily-logging rules. For a setup you do not have yet, ask a peer who runs one for their observed figure rather than guessing.
5. Model growth explicitly. Write down the estate you expect at the end of the horizon (partners, servers, users). Price both columns at that size, not today's. This is the rule that surfaces license growth.
6. Include one exit. Assume you leave at the end of the horizon and add the exit cost to both sides. This is the rule that surfaces lock-in, and it is the one buyers most often skip.
7. Include one adverse event per side. Open source: a behavior change that breaks a partner plus the expert leaving. Commercial: a forced upgrade plus a license model change at renewal. Estimate the hours for each; do not pretend either side is immune.
8. Tag learning hours. Hours that built durable skill in the team count, but mark them, so the ledger can be read with and without them.
9. Do not double-count support. If a support contract is bundled in the commercial invoice, the hours it saves come off the commercial hours column. They do not go on top of it. If the open source setup has a paid distribution subscription, that invoice goes in its invoice column.

The worksheet below applies the rules. Fill in every row for both options; a row you cannot estimate is a finding, not a blank. If you have never logged transfer hours, see costing failed jobs and manual work. It shows how to get a defensible number from your own tickets and logs.

TRANSFER TOOL COST LEDGER — one horizon, both options, same unit
Horizon: ___ years     Loaded cost per engineer-hour: ___ (from finance)
Estate at end of horizon: partners ___  servers ___  users ___

                          OPEN SOURCE            COMMERCIAL
                          hours   invoices       hours   invoices
Acquisition               _____   _____          _____   _____
Integration               _____   _____          _____   _____
Administration (routine)  _____   _____          _____   _____
Patching + upgrades       _____   _____          _____   _____
Features built anyway     _____   _____          _____   _____
Evidence + audit          _____   _____          _____   _____
Knowledge + staffing      _____   _____          _____   _____
Growth (priced at end
  of horizon)             _____   _____          _____   _____
Exit (assume you leave)   _____   _____          _____   _____
One adverse event         _____   _____          _____   _____
                          -----   -----          -----   -----
Subtotals                 _____   _____          _____   _____
Hours x loaded cost       _____                  _____
TOTAL (one unit)          ===========            ===========
Tagged learning hours     _____                  _____
Rows left blank (list — each is an unknown, not a zero):

Fill it in with a skeptic from the other camp in the room. The open source advocate keeps the commercial exit and growth rows honest. The product advocate keeps the open source integration and features rows honest. A ledger filled in alone is a brief, not an accounting. I have filled one in alone, with a confident zero in the exit row, and I was not being dishonest. I was being optimistic, which on a ledger is the same thing.

Reading the Result

Three patterns cover most outcomes.

Open source hours are small and flat; commercial invoices grow. This is the common result for a Linux estate, SFTP-only partners, and a fluent team. The integration and features rows are small because the team already has the pieces. The growth row punishes any per-server or per-user metric. Open source wins on cost, and probably on the other axes too.

Open source hours are large in the features and administration rows; commercial invoices are flat. This happens when the open tool would need a notification system, an audit report, a help-desk-friendly account screen, and a web upload page built around it. In this scenario, the commercial product includes all four under a metric that does not grow with your plans. The commercial example we know best, Sysax Multi Server, illustrates the shape of the trade rather than the answer. Logging to a file or database and per-account settings in a console are exactly the items that otherwise appear as hours in the open source column. Whether that saves more than the invoice costs is what the ledger exists to find out.

The totals are close. Then cost is not your deciding axis. The four questions in the opening article (control, skills, support, and fit) decide instead. One tie-breaker holds on cost grounds alone: prefer the option with the smaller exit row. A wrong choice with a cheap exit is a lesson. A wrong choice with an expensive exit is a multi-year commitment.

Reducing the Hidden Costs on Whichever Side You Choose

The ledger also tells you where to work once the decision is made. Most hidden costs shrink when someone sets out to shrink them.

On the open source side: automate account provisioning with the configuration-management tool you already use, so administration hours fall toward zero. Ship logs to the central collector from day one, so evidence assembly is a query, not a project. Document the configuration next to itself, and make sure two people can explain it. Scheduled flows on the Windows side of a mixed estate are a common gap. A Windows automation client (Sysax FTP Automation, in our case) covers folder monitoring, notifications, and OpenPGP handling that would otherwise be several scripts. That is an item for the features row rather than an assumption.

On the commercial side: negotiate the license metric to match the way you expect to grow. Get the growth price in writing before you sign. Insist on documented export of accounts, jobs, and history, and test the export during the trial. That is your exit row. Keep partner-facing documentation protocol-based rather than product-based so partners never notice a platform change. Keep the glue you write in your own repository, not inside the product's scripting store. Put the renewal date and a vendor health check on the calendar.

What the Ledger Is For

The purpose of counting hidden costs is not to prove that one side is secretly expensive. It is to make the decision on the real number rather than the decoy. Over a fixed horizon, at a loaded hourly rate, with growth and exit and one bad year on each side, the two become comparable. The comparison often comes out differently for different flows in the same organization, which is why so many estates mix the two deliberately.

When the ledger has to persuade someone who signs for money, do not send them the ledger. The one-page business case presents its totals as a cost shape (a bump, a flat, and named spikes). It puts the open source and commercial options in the same columns. The next articles take the two largest cells apart. The article on support realities covers the hours support actually saves. The article on licensing basics covers the metrics behind the growth row. Mixing open source and commercial tools then shows how to keep both sets of hidden costs small at once. And the next time a slide says zero, ask what the zero is hiding.

Frequently Asked Questions