What a free service still costs

When I consider turning software into a business, I keep returning to a question: what would someone actually be paying me to do?

If a small tool is easy to run and inexpensive to host, my inclination is to release it openly. I would like someone to use it without inheriting a subscription simply because I wrote it. That preference becomes harder to apply when other people depend on the tool being available tomorrow.

A copy of the code has no continuing obligation to its user. A service does. Someone must handle upgrades, recover lost data, investigate failures and decide what happens when the original maintainer loses interest. A small server bill can conceal a substantial promise.

Where the continuing work lives

Consider a utility that transforms a local file. Once the program has been written, another person can run a copy with little involvement from its author. Writing and maintaining it still takes effort. Paid support, sponsorship or a commercial licence could be reasonable ways to fund that work. My own preference for an open release would be a choice about how to share it, rather than proof that the labour had no value.

Now consider an index built from unreliable public sources. The collection script is only the beginning. Someone has to revisit failed requests, reconcile contradictory records, track changes and keep enough provenance to explain an entry. The old dataset may remain downloadable long after that work stops. Its availability would then outlast its reliability.

A subscriber might be paying for that continuing attention. Open ingestion code would give them the means to build a collection; a maintained service would spare them the work of operating it. Substantial computation can provide a similar reason to pay when repeating it on every user’s machine would be impractical.

These are the services I find easiest to justify: their value can be explained as work the user would otherwise have to do, or could not reasonably do alone.

Self-hosting is an option, with responsibilities

A low hosting bill does not make operation effortless. Installation, upgrades, backups and recovery consume time. Someone who could self-host may reasonably prefer to pay another person to take responsibility for those tasks.

That is compatible with open software. A hosted version can sell dependable operation while a self-hosted version preserves independence. Different users can make different choices about where they want the responsibility to sit.

The same responsibility exists in a free service. Once someone relies on it, an outage is their interruption and an abandoned upgrade is their problem. “Free forever” says nothing about how their records will be restored. Before making that promise, I would want an answer to who will do the work.

The price should survive a useful exit

Open source, free access and self-hosting describe different properties. A service can cost nothing while offering neither source code nor usable exports. An open-source application can need expensive infrastructure. A self-hosted tool can still rely on a proprietary external service.

For me, the important question is whether a user has a practical choice. Leaving requires interpretable exports, documented formats and a realistic way to run the necessary parts. A download button that returns files useful only to the original service offers little independence.

I would want a paid service to remain worth paying for after that exit works. Maintained data, expensive computation, reliable operation and competent support can make the case. When users can leave and still prefer to stay, the service has a much clearer account of what it contributes.