I replaced five commercial applications with open source equivalents over about a year, partly to reduce subscription costs and partly to see how viable it actually was.

The results were more varied than either the enthusiasts or the sceptics would suggest.

Where the replacement was straightforward

Three of the five, and the pattern is consistent.

Mature categories where the problem is well understood and the software has had twenty years to converge. Office documents, image editing for ordinary purposes, and file synchronisation.

In each case the open alternative did everything I actually used, the interface was different enough to require a week of adjustment, and after that I stopped noticing.

The feature gap that people cite is real and concentrated in advanced functionality that most users do not touch. If you are in the minority who do, the gap matters entirely; if not, it is invisible.

Where it was worse

One replacement I reversed.

The category involved substantial integration with external services, and the commercial product had partnerships and maintained connectors that the open alternative could not match.

This is a structural rather than a technical disadvantage. Building and maintaining integrations with dozens of third-party services requires ongoing commercial relationships and paid engineering, and it is exactly what volunteer effort is worst suited to.

The lesson I took is that open alternatives are strongest where the software is self-contained and weakest where value comes from connections to other people's systems.

Where it was genuinely better

The unexpected one.

A tool I had used in a commercial version for years turned out to have an open equivalent with a fundamentally different design that suited my work better.

The commercial product had accumulated features to serve a broad market. The open one had stayed focused because nobody needed to expand its addressable market.

That is a real advantage of software written by people who use it rather than by a company selling it, and it shows up most in tools for technical work.

The costs that are not the licence fee

Being honest about what the switch actually cost.

Time. Learning new interfaces, migrating data, rebuilding workflows. Perhaps two working days across the five, which is real money.

Support. There is no support line. There are forums, documentation of variable quality, and issue trackers, and getting an answer requires being able to ask a well-formed question.

Compatibility friction. Exchanging documents with people using the commercial standard mostly works and occasionally produces formatting problems, which is a small recurring irritation.

And the maintenance burden of anything self-hosted, which is the largest cost by a distance and the one people most underestimate.

The sustainability question

The thing that genuinely worries me about the category.

A large amount of critical open source software is maintained by very small numbers of people, frequently unpaid, and the funding position is precarious.

This has produced well-documented incidents where widely used components were abandoned, or maintained by someone who became a target for social engineering, or simply stopped receiving security attention.

Which means using open source is not automatically the safe or ethical choice, and evaluating a project's maintenance health is part of the assessment.

What I look at: how many people have commit access, how recent the activity is, whether there is any funding, and how quickly security issues have been addressed historically.

The recommendation

Try the alternative before the renewal date, not after cancelling, so that the fallback exists.

Give it a fortnight of real use rather than an hour of evaluation, because the first hour of any unfamiliar interface is misleading.

Check the specific advanced features you actually use, rather than comparing feature lists.

Assess the project's health, not just its capability.

And contribute something if you end up depending on it, financially or otherwise, because the sustainability problem is real and it is the direct consequence of everybody assuming somebody else is funding it.

The licence question

Worth a paragraph for anybody using these in a business.

Open source licences differ substantially in what they require. Some impose obligations if you distribute modified versions or build products on top.

For internal use of a finished application, this is almost never an issue.

For anything incorporated into a product you distribute, it matters and is worth checking rather than assuming, since the consequences of getting it wrong are legal rather than technical.

What made the difference in adoption

A note on how to make a switch actually stick, since good intentions mostly do not.

Migrating the data first, completely, before attempting to work in the new tool. Half-migrated states send you back to the old application constantly.

Removing the old application once the trial period has passed, because leaving it installed means reverting at the first friction.

And picking a quiet period rather than switching under deadline pressure, which guarantees reversion.

The three switches that stuck all followed that pattern and the two that failed did not.