A comment by Christoph Ott
CEO of LEAN-CODERS
Those who know me, know: I am the biggest Open Source fan in the house. Still, I will try to dissuade you for eight rounds. Not because I have changed my mind, but because I know every single objection that companies raise against Open Source and understand how little of it holds up to closer scrutiny. Let's go.
When it crashes, no one is responsible – who are we supposed to sue?
You probably didn't read the fine print in the license agreement if you think you can succeed with a lawsuit against your software vendor. The reality looks quite different. Almost every EULA tells you on the first pages that the vendor is liable for almost nothing. Unfortunately, many are often unaware of this and at first glance buy a service and peace of mind.
With Open Source, you don't buy into this fairy tale at all. Instead, you get transparency. You can purchase the support you need, choose reliable partners, or intervene yourself. Responsibility from the vendor does not arise from a license agreement, but from competence and a sense of responsibility.
Open Source security does not exist – anyone can look at the code after all.
Absolutely. Anyone can look in. Even the good guys.
The counter-model is called 'Security through Obscurity': hoping that no one notices what is happening in the basement. This works about as well as hiding a house key under the doormat and believing no one will think to look there.
Open code does not automatically mean secure software. But it allows for independent reviews, audits, and quick fixes. Security arises from transparency, not from secrecy. If secrecy were the guarantee of security, there would also be no security gaps in established applications – and we all know that this is not the case.
One log4j and half the internet is on fire – the dependency risk is unbearable.
That's exactly why everyone knows the name log4j today.
The security vulnerability was made public, analyzed within hours, and then – as is usual with critical vulnerabilities – tightened in several steps until it was truly secure. Not perfect, but understandable for anyone who wanted to take a look.
Now the counter-question: How many critical closed-source components are running in your company today that you don't even know exist – let alone whether and when they were ever patched?
The real risk was never Open Source. The risk was a lack of dependency management. This affects all software – you usually only see it with proprietary software when the vendor eventually (maybe) releases an update.
This is just hobby software from amateur developers.
Yes. Linux is a hobby project. Kubernetes probably is too. PostgreSQL, Chromium, OpenSSL, Python, Redis ... all nice weekend projects.
A large part of the digital world runs on Open Source. And not despite the community, but because of it. Many Open Source projects today are backed by companies with thousands of developers and billions in investments. Not bad for a hobby.
There is no support. Who do we call at 3 AM?
Of course there is support.
Red Hat lives off it. Canonical lives off it. SUSE lives off it. Countless service providers live off it.
The difference is: You can choose who supports you. Or you do it yourself. With proprietary software, you have to hope that the vendor prioritizes your ticket at some point or that you or your company is big and important enough for your problem to be addressed quickly. Open Source gives you options instead of waiting lines.
'Free' doesn't exist – the hidden costs will eat you up.
I even agree with that.
Open Source is not free. Good software costs time, know-how, and operation.
The exciting question is: What are you paying for? For innovation or for licenses? Forfurther development or for vendor lock-in?? For freedom of choice or for the next mandatory version jump?
Licenses are a legal minefield.
Have you ever read an enterprise contract with 180 pages? Then you know how creatively license terms can be formulated.
Open Source licenses are public, standardized, and have been tested millions of times. Of course, you need to understand them, but they rarely surprise you with clauses like 'From version 12, this will now cost three times as much.'
We depend on the grace of unpaid volunteers – what if the project dies?
Good question.
Then you can take over the code. Create a fork. Hire another service provider. Or continue together with the community.
Now the same question for proprietary software: What do you do when your vendor discontinues the product? Exactly.
Did you know that you already trust them?
If you've read this far: Thank you for your patience with my defense of the evil.
One more thing before you decide whether Open Source is right for your company. Take a quick look at your own tech stack. Is there Linux running somewhere? Docker? Kubernetes? Nginx? An operating system, a database driver, a JavaScript library that no one in the house has ever read?
Congratulations. You are already using Open Source. Probably for years, probably at a critical point, and probably without ever asking yourself any of these eight questions.
So the real question was never whether there is such a thing as real Open Source security. It was: Did you know that you already trust it?
If you thought until now that Open Source is not for your company: Think again, and get in touch with us. Not to sell you something. But to honestly look together at whether there is a risk lurking exactly where you least expect it.
No sales pitch, just an honest outside perspective.