The download costs nothing. The license is permissive. The GitHub README makes it look almost trivially easy to get running. And then you spend three months maintaining it, two engineers patching it, and one incident commander debugging a production failure that traces back to an undocumented behavior in a dependency you didn’t know you had.
Open source software is free the way a puppy is free. The acquisition price is zero. Everything after that is negotiable.
This is not an argument against open source. It is an argument for honest accounting, and the gap between how companies budget for open source and what it actually costs them is wide enough to explain a surprising number of engineering org dysfunction stories.
The hidden labor bill
When a company adopts an open source project, it implicitly agrees to take on some fraction of the work that a commercial vendor would otherwise absorb. Security patches need evaluating. Breaking changes in new versions need someone to read the changelog and decide whether to upgrade or hold. Configuration decisions that a managed service would make invisibly become engineering decisions with real time costs.
The Linux Foundation has studied this problem in aggregate. Its research found that the average software application relies on hundreds of open source dependencies, and that most organizations have no accurate inventory of what they’re running or who is responsible for keeping it current. The cost of ignorance tends to show up as emergency work: a critical CVE drops, and suddenly three engineers are working a weekend they weren’t planning to work.
This is a cost. It just doesn’t appear on any invoice.
Integration debt is real debt
Commercial software comes with integration support, whether good or bad. Open source software comes with documentation, whether complete or not, and a community forum where someone may have answered your exact question three years ago in a thread that’s now partially stale.
The labor required to make an open source tool work inside a specific organization, with its specific infrastructure, its specific data formats, its specific security requirements, is often larger than the labor required to maintain it afterward. Companies routinely underestimate this. They see a zero in the licensing column and book a project as cheap before anyone has scoped the integration.
The result is a pattern where open source adoption looks like a win in Q1 and becomes a quiet drag on velocity for the following two years. The software you never sunset becomes your biggest bill is a problem that disproportionately affects open source adoptions, because the absence of renewal pressure means there’s no forcing function to revisit whether the tool still makes sense.
Maintainers are not your support contract
The open source maintainer relationship is perhaps the most misunderstood economic arrangement in software. Companies with millions of dollars in annual revenue routinely depend on projects maintained by one or two people working nights and weekends, with no obligation to respond to issues, no SLA, and no particular incentive to prioritize the use cases that matter to any specific enterprise user.
This is not a criticism of maintainers. It is a description of a structural imbalance that has caused real problems. The Log4Shell vulnerability in late 2021 affected an enormous portion of global software infrastructure. The project had a tiny number of active contributors. The mismatch between criticality and maintainer resources is not an edge case in open source; as explored in Open Source Runs the World and Nobody Pays for It, it is closer to the norm.
When companies treat open source as a cost-free resource and contribute nothing back, whether code, funding, or even detailed bug reports, they are free-riding on a system that has limited capacity to absorb free-riders before it starts to fail.
The counterargument
The obvious rebuttal is that the alternative, commercial software licensing, is also expensive and comes with its own problems. Vendor lock-in, opaque pricing, and the risk that a product gets discontinued or acquired and gutted are all real. Comparing open source total cost of ownership to some idealized commercial alternative is a bad comparison.
This is fair. Commercial software is not the right benchmark. The right benchmark is honest internal accounting. The question is not whether open source is more or less expensive than a vendor. The question is whether the teams adopting open source are making realistic estimates of what they are taking on.
Most are not. The zero-dollar license fee functions as an anchoring bias that distorts every subsequent cost estimate downward.
What honest accounting looks like
Organizations that use open source well treat it like any other infrastructure investment. They maintain an inventory. They assign ownership. They budget engineering time for maintenance, not just feature work. They contribute upstream when they have the capacity, because they understand that the health of the projects they depend on is their problem too.
This is not especially complicated. It is just rare, because it requires resisting the intuition that free means cheap.
The puppy is a joy to have. It is also, over the course of its life, a significant commitment of time, money, and attention. The people who figure that out before they bring it home tend to end up happier with the arrangement than the ones who only noticed the zero on the adoption fee.
