Open source should be the default

Unless proprietary software fills 95% of your business needs, I think open source should be the default starting point.

I’ve seen the same proprietary software playbook run over and over. Big sales teams promise the world. Then you get into the nitty-gritty: a big bill, an expensive implementation, and changes that cost an arm and a leg. By the time you understand the limitations, you’re committed.

Nobody gets blamed for choosing Microsoft or Salesforce. They’re the safe choice. But what does that safety actually cost, both now and five years down the track? How much are you spending to make the platform fit your business? How much are you changing your business to fit the platform? And what happens when you want to leave?

That dependence on one vendor is exactly why I think open source deserves to be considered first. Having access to the code and the right to modify it gives you options when your supplier can’t deliver what you need. You can bring in another team and keep building. That’s the freedom I’m talking about.

Implementation matters, of course. But I think plenty of businesses could get what they actually need more cheaply, quickly, and efficiently with open source. Especially when their requirements start drifting away from what the proprietary platform was designed to do.

There’s substantial economic value in building on shared foundations. A 2024 study by researchers at Harvard Business School and the University of Toronto estimated that replacing widely used open-source software within the firms using it would cost $8.8 trillion. That isn’t a prediction of what your particular project will save. It shows how much work businesses already avoid repeating because open source exists.

With AI and agentic development, I think the case for customising those foundations is getting stronger. Teams can build tools and workflows much more closely suited to the way a business operates. You have access to the code and the rights to modify and extend it. You can choose who does that work and when it happens. Development still costs money, but you don’t need the platform owner’s permission to get started.

That still takes a capable team. DORA’s 2025 research found that AI magnifies an organisation’s existing strengths and weaknesses. The tools work best when the underlying development practices are sound. For me, that reinforces the value of combining open-source foundations with people who know how to build and maintain software properly.

The security argument deserves scrutiny too. I don’t buy the idea that proprietary software is safer simply because nobody can see under the hood. Keeping source code private doesn’t make vulnerabilities disappear. Anthropic’s research on Mythos Preview describes finding vulnerabilities in open-source software and developing exploits through reverse engineering of closed-source software. My takeaway is that secrecy alone offers very little reassurance, especially as AI gets better at this work.

What I value about a well-run open-source project is the honesty of its security process. Take the Drupal Security Team. There’s a documented process for assessing reports, coordinating fixes with maintainers, and telling users what action to take. Issues are initially handled confidentially while a fix is prepared. If a covered module’s maintainer fails to address a problem within the deadline, the team can publish an advisory recommending that users disable it and mark the project unsupported.

That’s useful information, even when it’s uncomfortable. Public code still needs people to inspect it, and a dedicated security team can’t guarantee that every problem will be fixed promptly. But I can see how the process works. I can bring in someone independent to inspect the code and challenge its assumptions. That’s a more honest basis for trust than a brand name alone.

Then there’s the cost of leaving.

I’ve seen clients cop tens of thousands, sometimes hundreds of thousands, in migration costs because their existing vendor wouldn’t let them do what they needed. The business wanted to change direction, and the platform became the obstacle. Getting out became a major project in itself.

Leaving can also mean walking away from years of investment. You’ve paid for custom functionality, integrations, and workflows, but they’re tied to that platform. You can’t simply take the whole thing somewhere else and rehost it. Even getting your data out in a usable form can be difficult. You end up paying again to recreate things your business already had.

In a 2026 survey of open-source users, more than half named avoiding vendor lock-in as one of their reasons for choosing it.

This is where open source makes a real difference. With access to the code, your data, and a properly documented setup, another team can take over and keep building. You still need to establish ownership of custom work and make sensible choices about hosting and dependencies. But changing suppliers doesn’t have to mean starting again. You can preserve the investment you’ve already made.

A good open-source partner is worth their weight in gold here. Their judgement and experience can save you money, steer you away from unnecessary complexity, and help your business over the long run. Implementation, maintenance, security, and support are all worth paying for.

A partner who understands the wider project community can help too. The Linux Foundation’s 2026 research into open-source contribution examines the benefits of contributing improvements back, alongside the ongoing cost of maintaining separate versions and internal workarounds. Having the freedom to change the code is valuable. Knowing how to make those changes sustainable is part of the expertise you’re paying for.

You want someone who understands what you’re trying to achieve and gives you sound recommendations. And you should have the freedom to change that partner if the relationship stops working. Your provider should keep earning your business through the value they bring.

My 95% rule is a practical starting point. If a proprietary product already does almost everything your business needs, there may be a strong case for it. But if you’re buying into a platform knowing you’ll have to fight it, customise around its limitations, and depend on one vendor to move forward, I think you should start with open source.

Before you commit, ask what happens when you want to leave. Your software should come with an exit.