A few days ago, a client of mine asked me to install an open-source software (which I won’t name for now). The software has only one official installation method: Docker. This is because, as they themselves admit, it has a huge number of dependencies - some quite outdated - that need to be carefully managed and forced into place; otherwise, nothing works.
I tried replicating the same setup on FreeBSD but didn’t succeed, as some dependencies either aren’t compatible or simply refuse to run. I could try finding workarounds, but I can already picture the chaos every time an update is needed.
So, I decided to build it via Docker to get a better sense of what we’re dealing with. The sheer number of dependencies that Node pulls in is impressive, but even more staggering is the number of warnings and errors it spits out: deprecated and unsupported packages, security vulnerabilities, generic warnings- you name it, and there’s plenty of it.
Since my client needs to launch this service but is subject to audits, they want to be fully compliant and ensure security. Given their substantial budget, they offered financial support to the developers (a company, not just a group of hobbyists) to help improve the project either by making it FreeBSD - compatible or, at the very least, by reducing dependencies with critical vulnerabilities. The client was willing to pay a significant sum, and since the improvements would be open-source, everyone would benefit.
The response from the team? A flat-out refusal. They claimed they couldn’t accept any amount of money because many of these dependencies are "necessary and irreplaceable, as parts of the code relying on them were written by people who no longer work on the project, and we can’t rewrite the core of the software.” Then came the part that really got under my skin: they stated they would rather deal directly “with my client, not with me, because in the end, my concerns are just useless and irrational paranoia.”
Translation? Just pay, and you’ll pass compliance checks - never mind the fact that underneath, it’s a tangled mess of outdated and insecure components. And don’t make a fuss about it.
While I can understand some of the challenges the team faces, I might have accepted this response if it had come from a group of volunteers or hobbyists. But if you’re a company whose sole business revolves around a single software product (with no real competition at the moment), this approach is not just short-sighted - it’s outright dangerous for your users’ security and for your own survival as a business.
The result? They lost a paying client who was ready to invest a significant budget into their software. That budget will now go elsewhere. My client is considering hiring developers to build a similar project with better security (they have both the time and the money for it). I’ll do my best to convince them to release it as open-source - at which point, a new “competitor” will emerge in the market.
