"Wait, My Custom Software Isn't All Custom?"
A client called me last year, a little rattled. He had just read an invoice from a previous developer that listed a library he didn't recognize, and a quick search told him it was "open source." His first question was blunt: "Did I pay full price for something you got for free?"
It's a fair question, and I get some version of it often. Here's the honest answer: yes, most custom software is built partly from free, community-made pieces. And no, that's not a bad thing. It's actually how almost all modern software gets built, including software from companies far bigger than mine. The real issue isn't whether those pieces are free. It's whether anyone is paying attention to them after your app ships.
What "Open Source" Actually Means
Think of building software like building a house. A developer doesn't forge their own nails or mill their own lumber. They buy standard parts from suppliers and focus their time on the parts that make your house yours: the layout, the custom cabinets, the details only you asked for.
Open source components are those standard parts. They're pre-built pieces of code, written by individual programmers or small teams, and shared publicly so anyone can use them for free. A login screen, a way to process a credit card, a calendar picker, a function that resizes an image: someone has already written good code for that, and it makes no sense to write it from scratch every time.
This isn't a fringe practice. Independent industry research that scans thousands of real commercial codebases found that open source code makes up roughly three-quarters of the average application, and a typical app contains several hundred separate open source components. Your "custom" software almost certainly has dozens, maybe hundreds, of these free parts inside it. That's normal. What matters is what happens next.
The License Is the Fine Print That Actually Matters
Every open source component comes with a license, a short legal document that says what you're allowed to do with the code. Two of the most common are worth knowing in plain terms.
MIT-style licenses are the easygoing ones. They basically say: use this however you want, sell products built on it, keep it private, just leave a small credit note in there somewhere. Most business software leans on these because they create no obligations that affect your product.
GPL-style licenses work differently. They say: if you build on this code and hand your product to others, you may have to release your own source code under the same open terms. For a company selling proprietary software, that can be a serious problem. Imagine spending two years and real money building a product, only to learn a piece of it legally requires you to give your competitors the blueprint.
This is why the license a component ships under matters as much as what the component does. A developer who picks components without checking the license is making a legal decision on your behalf, whether they realize it or not.
The Real Risk: Nobody's Home
Here's the part most business owners never hear about. A lot of open source code is maintained by volunteers, sometimes just one person, working in their spare time, for free. Most of the time that works out fine. Sometimes it doesn't.
In 2021, a widely used free logging tool called Log4j turned out to have a flaw serious enough that it put a huge share of the internet's servers at risk almost overnight, because that one small free component was quietly buried inside thousands of larger applications. In 2024, security researchers discovered that a critical compression tool, maintained for years by a single burned-out volunteer, had been deliberately sabotaged by an attacker who spent roughly two years patiently earning that maintainer's trust before slipping in a backdoor.
Neither of these tools was badly written. Both were free, useful, and trusted by nearly everyone. The failure was that almost nobody was watching who maintained them or whether they were still being patched. That's the actual risk with open source: not the code itself, but components that go unmaintained, unpatched, or unreviewed once they're buried inside your app.
How a Responsible Developer Handles This For You
A good developer doesn't avoid open source. That would mean reinventing thousands of already-solved problems and charging you for the privilege. Instead, they manage it the way a good contractor manages materials: they choose suppliers with a track record, they check the paperwork, and they keep an eye on what they've already installed.
In practice, that means picking components that are actively maintained and widely used, checking the license before it goes anywhere near your product, and running tools that flag known security issues in those components so patches happen before they become your emergency. This is separate from who legally owns the custom code you commissioned — that's about your rights to the code your developer wrote for you. It's also different from being dependent on a single software vendor, which is about one company controlling your whole platform. This is about the dozens of small, free ingredients mixed into the recipe, and whether someone is still checking the pantry.
Free Isn't the Problem. Ignored Is.
Back to my client: once I walked him through it, he wasn't upset anymore. He understood that open source components had kept his project affordable and let us focus his budget on the features that actually make his business different from competitors. What he wanted after that wasn't less open source. He wanted to know someone was keeping watch on it, which, honestly, is a reasonable thing for any business owner to want.
If you're not sure what's inside the software running your business, or whether anyone is watching it, that's a conversation worth having before it becomes a problem instead of a question.