What do people actually mean when they say 'open-source'?
In practice, three different things get used interchangeably. Sometimes someone means a fully open-source package like Odoo or ERPNext. Sometimes they mean a system built on open-source components: a Python backend, PostgreSQL as the database, and React on the front end. And sometimes they simply mean: not paying for an expensive license. These three are fundamentally different. An open-source package comes with a community, documentation, and a roadmap, but also with limitations on customization and a dependency on that community when something breaks. Building on open-source components is something else entirely: you build it yourself, using proven building blocks, and the end result is fully yours. The second approach is what we almost always take. Not out of open-source ideology, but because it is good tooling.
Where does a commercial suite go wrong?
The promise of a suite is understandable: everything is included, it has been tested, there is support. What you only discover later is that 'everything is included' means the system was built for the average company in your sector, not for your company. The deviations from that average, and there are always deviations, get resolved with customization on top of the suite. That customization becomes more expensive as the suite grows more complex, because you are working against the package's own structure. On top of that, your license costs scale with your usage, you are tied to the vendor's release calendar, and if that vendor changes strategic direction or gets acquired, that becomes your problem. We see this pattern regularly with companies that, after five or eight years, want to move away from their suite and then discover how much process knowledge is buried in the package's configuration, documented nowhere else.
What is the real advantage of building on open-source building blocks?
When you build on open-source components, you pay no per-user or per-module license fee. But that is the least significant advantage. The greater advantage is that the system does exactly what your operation requires, not what the vendor imagined you should want. You choose your own data structure, your own integrations, your own deployment environment. And if the party that built it stops tomorrow, you still have the code, the documentation, and the freedom to hand it over to another party. That is ownership in the true sense of the word. The catch is that you can only achieve this if the party doing the building genuinely understands what they are building. Open-source building blocks in the hands of a team without domain knowledge will not produce a better system than a poorly configured suite.
When is a commercial suite actually the better choice?
There are situations where an off-the-shelf package is simply faster and cheaper. If your processes are generic, if the sector already has good packages that fit, or if your organization does not yet have the maturity to take ownership of a custom system, then a suite is a reasonable choice. The mistake is not choosing a suite. The mistake is making that choice without honestly examining the total cost over five years: licenses, customization, upgrades, vendor dependency, and the cost of not being able to deviate from the standard process. We sometimes advise straightforwardly: use Odoo, it fits what you need right now. But we also advise: make sure you know what you are giving up.
What does this mean for day-to-day operations on the floor?
The people who work in the system every day feel this distinction most acutely. A system built around the logic of your operation feels different from a system that has forced your people to adapt the way they work. That sounds abstract until you see how many workarounds live in spreadsheets alongside an ERP that was supposed to 'handle everything'. Those spreadsheets are the signal that the system and the operation are not aligned. Whether you resolve that by further configuring the suite, building an AI layer around it, or rebuilding the system from scratch depends on how far the mismatch has gone. But the first step is always the same: honestly identify what the system currently does and does not do, before deciding what comes next.