A startup I know decided to self-host their entire data stack using open source tooling. Kafka for messaging, Elasticsearch for search, Postgres for primary storage, Redis for caching. Every tool had a compelling GitHub page, a thriving community, and a license that cost exactly zero dollars. Eighteen months later, they had a senior engineer whose primary job was keeping those systems alive. Not improving them. Not building features on top of them. Just keeping them running.
The joke in the title is old enough that people groan when they hear it, but it survives because it keeps being true. Nobody budgets for puppy food when they’re staring at the cute one in the shelter window. And nobody budgets for operational burden when they’re staring at a clean open source README.
The Costs That Don’t Appear on the License
The license is not where the money goes. The money goes into the work that happens after the git clone.
There is the integration cost: reading enough of the codebase to understand not just how the tool works but why it works that way, which tells you where it will break. There is the configuration cost: most serious open source infrastructure software has configuration surfaces that rival small operating systems. There is the upgrade cost: major versions of tools like Kubernetes or Elasticsearch frequently require migration work, sometimes substantial migration work, and the changelog is optimistic about how long that takes.
And then there is the incident cost. When a managed service has an outage, you file a support ticket and wait. When your self-hosted open source system has an outage at 2 a.m., someone on your team gets paged. That someone is expensive. That 2 a.m. is expensive in ways that don’t show up until your best engineers start quietly updating their LinkedIn profiles.
None of this is an argument against open source software. It is an argument against the fantasy that free licensing means free adoption.
The Expertise Problem Is Real and Gets Worse
Open source software at the infrastructure level rewards specialization heavily. The people who are genuinely good at operating Kafka, or tuning Postgres at scale, or managing a production Kubernetes cluster are not abundant. They command real salaries because the knowledge is hard to acquire and harder to keep current.
This creates a specific trap for growing companies. You adopt an open source tool because you can afford the license, meaning the license is free. You run it reasonably well for a while because the initial setup is well-documented. Then the system gets more load, or you hit an edge case, or a CVE drops, and you discover that your team’s understanding of the tool goes about three layers deep in a tool that is twelve layers deep. You now have three options: hire someone who knows it, pay a consultant who knows it, or migrate to a managed service that abstracts the layers you can’t staff.
All three options cost money. Often more money than a managed service would have cost from the start.
This is related to a broader truth about technical hiring: the cheap engineer costs more than the expensive one when you account for the downstream work they create. The same logic applies to tooling decisions. Choosing the zero-dollar tool to save budget is not the same as choosing the low-cost tool when you account for total cost of ownership.
Security Is Where the Bill Comes Due Suddenly
Open source software’s relationship with security is genuinely complicated. The transparency of the source is a real advantage: researchers can find and report vulnerabilities. But it is also an advantage for attackers, who can read the same code.
The Log4Shell vulnerability in late 2021 is the canonical recent example. Log4j was embedded in an enormous number of Java applications, many of which had been running without meaningful maintenance for years. The companies that got hit hardest were not the ones who made a bad technical decision. They made a reasonable technical decision and then failed to account for the ongoing cost of tracking and responding to vulnerabilities in their dependencies.
That ongoing cost is not optional. You cannot decide that security patching is a future problem. You can only decide whether you are paying for it explicitly, through headcount or tooling, or implicitly, through incidents. The implicit version is always more expensive.
For smaller teams, this is where managed services often win even when they feel more expensive on paper. The managed service vendor is watching CVEs, patching their fleet, and handling the 2 a.m. call. You are paying for that service in your subscription fee. When you self-host, you are providing that service yourself, whether you have budgeted for it or not.
When Open Source Actually Makes Sense
None of this means you should avoid open source software. That would be an absurd overcorrection. Linux, PostgreSQL, Python, React, and hundreds of other open source projects are load-bearing infrastructure for essentially the entire industry. The question is not whether to use open source but whether you are making the decision with clear eyes about what it actually costs.
Open source makes strong sense when the tool is well within your team’s existing expertise. If you have three strong Postgres engineers, self-hosting Postgres is probably fine. You have the depth to handle surprises.
It makes sense when the managed alternatives are genuinely bad or genuinely unavailable. There are niches where the only serious option is the open source project, and managed wrappers around it are thin or unreliable.
It makes sense when you need capabilities the managed services don’t expose. SaaS products make tradeoffs. Sometimes those tradeoffs cut against what you actually need.
And it makes sense when you have genuinely accounted for the full cost: the integration work, the operational burden, the security overhead, and the expertise required. Not as an afterthought. As part of the actual decision.
What Good Decision-Making Looks Like
The teams I’ve seen handle this well do something simple: they treat open source adoption as a build-versus-buy decision, not as a free option. They ask what the managed equivalent costs per month, then ask what the engineering time to run it themselves costs per month, then add a realistic buffer for incidents and upgrades.
Often the numbers still favor self-hosting. Sometimes they don’t. Either way, the decision is made with an honest accounting of what’s on the table.
The teams that get hurt are the ones who see the zero on the license and stop calculating. They’re not being reckless. They’re being human. But the bill arrives anyway, just on a different schedule and in a less legible form. You end up with an engineer who can’t ship features because they’re keeping the lights on, or a security incident that traces back to an unpatched dependency nobody was watching, or a migration project that takes a quarter because the original tool accumulated more load-bearing assumptions than anyone realized.
The puppy was free. The vet bills, the food, the dog walker when you travel, the replacement furniture were not. Knowing that going in doesn’t make the puppy the wrong choice. It just means you’re making the actual choice, not an imaginary one.
